The PHP security team has announced an emergency security release for today, 21 October 2026, at 14:00 UTC. It fixes two critical vulnerabilities, both rated 9.2 under CVSS 4.0. Some of the details started circulating publicly before the fix was available, so any organisation running a website or application on PHP should prepare now and apply the update as soon as it ships.
What happened
PHP is the programming language behind a large share of web applications, from content management systems and online shops to internal tools. This update therefore does not concern a single appliance at the network edge, but the runtime on your web servers.
According to the announcement on php.net of 20 October 2026, the security team gave advance notice precisely so that administrators could prepare. It also reserved the option to release earlier if details became public or if evidence of exploitation appeared. The technical description of the flaws and the list of affected and fixed versions will be published with the release itself.
The identifiers CVE-2026-109618 and CVE-2026-109619, and the claim that these are unauthenticated remote code execution flaws, do not come from the PHP announcement. They come from a leak that started on 20 October and from the analyses that followed. CERT-EU published advisory 2026-018, stating that no technical details are available and that the 9.2 score of both flaws indicates the potential for unauthenticated remote code execution. The same advisory says the flaws could affect all PHP versions from PHP 5 onwards, although nobody has officially confirmed that range yet.
One point deserves to be stated plainly: nobody has confirmed exploitation in the wild. Neither flaw is listed in the CISA Known Exploited Vulnerabilities catalogue, and neither the PHP security team nor a national CERT has confirmed attacks. watchTowr, which described the leak as accurate, says it has not seen exploitation in the wild.
What makes the situation worse is that information about the flaws is public before the fix. On top of that, any patch can be read backwards to work out what exactly was repaired. For a runtime present on this many servers, attempts at exploitation can therefore be expected shortly after the patch lands. Sansec, a firm focused on online shop security, expects mass attacks soon after the release.
Does this affect you?
Assume it does if PHP runs anywhere in your organisation, even where you do not develop the application yourself. According to W3Techs figures from October 2026, PHP is used by 69.3 % of websites whose server-side language can be determined. That is a share of the detectable ones, not of every website on the internet. In practice this means WordPress, Drupal, Magento, Shopware, WooCommerce and in-house applications alike.
You can check the version with php -v on the server or in your hosting control panel. The supported branches, per php.net, are 8.2, 8.3, 8.4 and 8.5. If you run PHP 8.1 or older, you will not receive an official fix: you will need a backported fix from your distribution or hosting provider, or an upgrade to a supported version.
Equally important is who actually controls PHP in your organisation. The fix cannot be applied by changing the application, because the PHP binaries themselves change. On a self-managed server that is your own team, on managed hosting it is the provider, and with containers it is whoever builds the base image and triggers a new deployment.
What to do now
- List every place where PHP runs: web servers, containers, internal applications, and old websites nobody remembers. What is not on the list will not get fixed today.
- For each of them, establish the version and who updates it. If that is your hosting provider, ask today when they plan to apply the fix.
- Reserve a maintenance window for this afternoon and evening and watch php.net. Once the fix is out, apply it according to the versions the vendor names.
- For containers, plan an image rebuild onto the fixed tags and a new deployment. Restarting the old container changes nothing.
- Where the fix cannot be applied straight away, consider the CERT-EU recommendation and isolate internet-facing applications from public networks until it can. In practice that means restricting access to known addresses or taking the application offline for a while.
- For PHP 8.1 and older, contact your distribution or hosting provider today and find out whether they will backport the fix. If not, you are facing a version upgrade, and it is better to know that today than next week.
- Check that web server logs are shipped off the server as well. Without them you cannot look back and tell whether anyone tried anything.
What is not known yet
So that you do not base decisions on it: there is still no published technical description of the flaws, no precise list of affected versions, no fixed version numbers and no temporary mitigation at the level of PHP configuration. Records in the NVD database and on cve.org are missing for both identifiers as well. One unconfirmed report links the flaws to the session upload progress feature, but there is no official confirmation and you should not build mitigations on it. Once PHP ships the fix, we will add the fixed version numbers to this article.
Not enough time to track this?
Most organisations do not have the people to keep track of what every application runs on and what is being fixed in it. We help with that in two ways: a security assessment shows what you have exposed to the internet and where you stand on vulnerabilities, and as your external security manager we keep track of priorities and remediation over time. The first consultation is free of charge, get in touch. If you are handling an incident right now, reach us on our incident response page.
Sources: php.net, notice of the upcoming critical PHP security release · CERT-EU, advisory 2026-018 on critical vulnerabilities in PHP · CISA, Known Exploited Vulnerabilities catalogue · watchTowr, FAQ on CVE-2026-109618 and CVE-2026-109619 · Sansec, php2shell analysis and what to expect after the release · W3Techs, PHP usage statistics · BleepingComputer, summary of the PHP notice and the leak