PHP2Shell explained: what broke in PHP and how to check your servers.

PHP is the programming language behind a large share of websites, including WordPress, Drupal and Joomla. On 20 October 2026 the PHP security team announced a critical release for the next day. The details then leaked. watchTowr, a security firm, says it was the first to confirm the leak was genuine, and The Hacker News reports that a researcher also posted a video of a working proof of concept by mistake. PHP moved its release forward, and the fixed versions went out on 21 October.

The UK's National Cyber Security Centre (NCSC) says the two flaws "could" let an attacker run commands on any web server running PHP, and urges organizations to update. Singapore's Cyber Security Agency makes the same call in plainer words: "Patch immediately."

The Hacker News credits Wiz Research, Calif and OpenAI's Codex Security team with reporting the flaws and working with the PHP security team on the fix. It also reports that a PHP core developer first saw signs of one of the bugs during a 2024 audit, with no clear route to code execution at the time.

1. 20 October 2026The leak spreads. PHP posts an advance notice of a critical release, without CVE numbers.
2. 21 October 2026, earlyCloudflare switches on firewall rules by default, before the patch exists, according to The Hacker News.
3. 21 October 2026, 14:00 UTCScheduled release time for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
4. 21 October 2026, afternoonwatchTowr reports "active exploitation attempts" against both flaws.

Both flaws are about what PHP does when a request goes wrong. They are different bugs with the same ending.

• CVE-2026-109618 is an out-of-memory flaw. If memory runs out while PHP is setting up a request, internal data can be left half-built, and PHP's cleanup code then treats that broken data as valid. That can corrupt memory.
• CVE-2026-109619 is a stale-state flaw. Data that belongs to one request can outlive the memory it points to, and the next request handled by the same PHP worker may use it. In technical terms this is a use-after-free.

Neither needs an account. PHP's advisory says the highest demonstrated risk is on Apache with mod_php, where an attack can run before your application code even starts. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected, though the sources disagree on how easy each is to exploit. For PHP-FPM, The Hacker News reports that one flaw is considered susceptible but no complete exploit has been shown, and the other has shown code execution only when the application does something particular.

One enabled-by-default feature, session upload progress, is a confirmed path for CVE-2026-109619. The advisory says it is not the only path. Researchers also warn that memory an attacker can read from a worker may hold passwords, tokens and keys. That is a possibility, and no source we read says it has happened.

Almost all of them. The Hacker News and watchTowr say nearly every version back to PHP 5.4, released in 2012, is affected. The list below shows the official fixes.

• PHP 8.5: fixed in 8.5.12
• PHP 8.4: fixed in 8.4.27
• PHP 8.3: fixed in 8.3.36
• PHP 8.2: fixed in 8.2.35. This branch reaches end of life on 31 December 2026.
• PHP 7.4, 8.0, 8.1: no official release. The PHP security team published minimal source backports, and some vendors offer long-term-support builds.
• PHP 7.3 and older: no fix. Upgrade to a supported branch.

Qualys, a security vendor, analyzed data from about 12,000 of its customers and found around 167 million PHP installations. By its count, roughly 71% run end-of-life branches that will probably never be patched, and another 28% run supported branches that did not yet have the fix. Its conclusion: "Nearly all PHP installations are either vulnerable or running unsupported versions." That is vendor telemetry from its own customers, not a census of the web, but it shows how many servers are stuck on old PHP.

Reports are mixed, and some contradict each other, so here is how we read them.

• Confirmed by several sources: the two CVE numbers, the 9.2 score, the fixed versions, and that attack attempts are happening. Cloudflare says it saw attack traffic against its customers and attackers changing their requests to get around its rules. watchTowr says its honeypots saw exploitation attempts on 21 October.
• Not confirmed: a successful break-in. The Hacker News reports that no source had confirmed one, and that neither flaw was in the US Known Exploited Vulnerabilities catalog at the time of writing.
• Disputed: severity. PHP rates both flaws 9.2. Some leaked reports said 10.0, which was not PHP's rating. The SANS Internet Storm Center cites an expected 9.4, which is its handler's own estimate.
• Disputed: how good the public exploit code is. SANS describes the published proof of concept as unreliable and incomplete, while another report says the flaws have been turned into working attacks on common platforms. Both can be true at once.

Some organizations took services offline as a precaution. The Hacker News reports that this included Dutch government websites, and that the Dutch national cyber security centre said it had not seen the flaw abused. Offline "just in case" is a legitimate choice when you cannot patch quickly: the UK NCSC lists it as an option.

Cloudflare's chief technology officer, Dane Knecht, said, as quoted by The Hacker News, "We are seeing early attacks emerging and are updating mitigations as new vectors show up". He described its firewall rules as a stopgap. A PHP core developer, Gina Peter Banyard, wrote before the release that the only mitigation is patching or upgrading PHP, again as quoted by The Hacker News. Johannes Ullrich of the SANS Internet Storm Center agrees: patching is "the only real fix".

This follows the PHP advisory, the NCSC alert and the Qualys and watchTowr guidance. It is written for people who run a website but not a security team.

• Find every place PHP runsWeb servers, containers, staging sites, old marketing sites, and products from vendors that bundle PHP. Start with anything reachable from the internet.
• Check the PHP that serves the web, not the one on your command lineRunning php -v shows the command-line PHP, which may be a different install. Check the version through the web server, for example with a phpinfo() page you remove straight afterwards, or ask your host.
• Update the runtime, not just the appUpdate the PHP package, host plan or container image to a fixed version. On managed hosting, ask the provider which fixed version they have deployed and when.
• Restart every PHP workerRunning processes keep the old, vulnerable code in memory until they restart. Qualys stresses restarting every service that loads PHP, then confirming the workers run the patched version.
• Review limits after patchingThe fix adds a hard memory limit, so check that your memory and upload settings still suit your application. If you set temporary limits, put them back in line once the patch is verified.
• Look for signs of troubleResearchers suggest watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 errors, unexplained PHP worker restarts, new files in the web folder, unexpected scheduled jobs and unfamiliar outbound connections. Keep logs before you change anything.
• Do not expose admin toolsTake admin panels off the open internet and put them behind a VPN or an allowlist. It limits the damage whenever the next PHP flaw arrives.

Plenty of businesses run PHP they do not control. Three common cases:

• Shared or managed hosting: your provider owns the runtime. Ask for the fixed version and the date it was applied, and keep a copy of the reply. If it has not been done, ask what the plan is.
• PHP 8.1 or older: look for a vendor or distribution package with the fix, apply the official source backport if you build PHP yourself, or plan an upgrade to a supported branch. PHP 8.2 reaches end of life on 31 December 2026, so choose 8.3 or newer for the move.
• Anything you truly cannot patch today: reduce exposure and consider taking the system offline. The NCSC says to apply PHP's temporary measures, take the system offline if those are not possible, and check for signs of compromise if neither can be done.

On a cloud platform? AWS says its own services are not affected, but PHP you run on them is yours to patch. In its bulletin, AWS says Elastic Beanstalk has updated PHP platform versions, which you must apply unless managed updates are on. Amazon Lightsail instances cannot be updated in place, so you create new ones from the updated blueprints and migrate. Containers and self-managed servers need a patched PHP in the image, then a redeploy. AWS also notes that, so far, it has established no spread between customers, and that an attacker would be limited to the affected worker and the permissions your application gives it. That is a good reason to run each site with only the access it needs.

PHP's temporary measures are real but incomplete. They include setting session.upload_progress.enabled=0, keeping request sizes low, and on PHP 8.5 setting fatal_error_backtraces=0, followed by restarting every worker. PHP says these block only the confirmed attack paths, and watchTowr calls changes to .ini files ineffective. A web application firewall can add a layer too, and Cloudflare has deployed rules, but it too describes them as a stopgap. Use any of these to buy time, and keep patching on your list.