Cybersecurity & Resilience

Two critical PHP flaws fixed in an emergency release

Layer 3 IT9 min read

  • PHP
  • Patching
  • Web Hosting
  • Proactive IT
Graphic headed "Two critical PHP flaws fixed in an emergency release", with a timeline from the leak on 20 October, two days early, to the fixes published on 21 October, the patched versions, and a reminder to install the PHP update.

The PHP project fixed two critical flaws on 21 October 2026 that could let an attacker run code without logging in. Unpatched websites should update now.

Two critical flaws in PHP, the language behind WordPress and a large share of the web, were fixed in an emergency security release on Wednesday 21 October 2026.

The PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to close vulnerabilities that could let an attacker run their own code on a web server without logging in. A coordinated release had been planned for 22 October. Details leaked on 20 October, two days early, so the fixes were published on 21 October. This report reflects information available on 23 October 2026, including the PHP Foundation's account of the release.

Key points

  • Two critical PHP flaws were fixed on 21 October 2026. They are CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell, and both are rated 9.2 out of 10 for severity.
  • An attacker needs no login. The flaws allow remote code execution, meaning commands run on the web server.
  • The fix is in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older releases are affected, including PHP 8.1 and earlier, which the PHP project no longer supports.
  • Details leaked two days early. The first posts carried the wrong release time and a score of 10.0. The rating is 9.2. Proofs of concept spread after that.
  • Updating a plugin or theme does not fix it. The flaw is in PHP itself. Site owners need a patched PHP version.
  • Interim steps are not a fix. The measures below reduce risk, but they do not make a site safe.

What was announced, and when

The PHP project had planned a coordinated release for 14:00 UTC on 22 October. The PHP Foundation says that plan held until 20 October. Times below are UTC. The release was brought forward to 14:00 UTC on 21 October, which was 1:00 am on Thursday 22 October in Sydney.

  • 20 Oct, about 15:00. CVE numbers begin circulating with the wrong release time and a score of 10.0. No technical details are included.
  • 20 Oct, 19:30. PHP publishes an advance notice and moves the release to 21 October at 14:00.
  • 20 Oct, about 20:00. Calif posts a proof-of-concept video by mistake, then deletes it. Copies circulate, and proofs of concept develop faster.
  • 21 Oct, 07:41. Distributor Chainguard publishes images that already contain the fix, more than six hours before the release.
  • 21 Oct, 14:00. PHP publishes its security advisories and releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

How the vulnerabilities were found

Both flaws sit in how PHP handles memory while it processes a web request.

  • CVE-2026-109618. If a request hits PHP's memory limit at the wrong moment, PHP can leave half-built internal data behind and later treat it as valid. The PHP Foundation says a full attack was demonstrated on Apache with mod_php, using default settings, before any application code runs. It also says code execution was confirmed on PHP-FPM through the application.
  • CVE-2026-109619. A fatal error at the wrong point can leave a later request, on the same worker, using memory from an earlier one. A crash was confirmed, and the reporter demonstrated code execution against a real application on Apache with mod_php.

The PHP Foundation says the memory problem behind CVE-2026-109618 was first noticed in 2024, after an external audit, but no reliable way to run code was known then. On 11 August 2026, Calif researcher Ryan A reported a working attack with that same cause. OpenAI reported the same cause independently. Wiz reported further ways in on 24 August, and OpenAI reported more on 18 September. From the August report, producing a fix was the priority.

Huntress reports that Calif's work sat inside OpenAI's Patch the Planet program, and that Wiz then showed attacks working without a login against WordPress, Drupal and Joomla in its tests. The Foundation says the security team had not identified a working exploit at the moment the fixes were published.

What sites were exposed to

Until patched, an affected website was open to an attacker with nothing more than the ability to send it a web request.

  • Remote code execution without a login. An attacker could run commands on the server as the web server's account, before any website code runs.
  • Leaked server memory. CVE-2026-109619 can also expose memory contents. The researchers say that may include passwords, tokens, API keys and certificates.
  • Almost every PHP setup. PHP says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates Apache with mod_php as the highest risk.
  • Every PHP application. The flaw is in PHP itself, not in WordPress, Drupal, Joomla, Magento or Laravel. Updating a plugin or theme does not fix it, and WordPress.org has confirmed no WordPress update is needed.

How serious is it? PHP rates both flaws 9.2 out of 10 (CVSS v4.0), and the US National Vulnerability Database scored them 9.8 (CVSS v3.1).

Are attacks happening? Reporting differs. The PHP Foundation says the security team had not identified a working exploit when the fixes were published. Cloudflare reported attack traffic against its customers, and CERT-EU says proofs of concept are circulating and exploitation is likely. At the time of writing, CISA had not listed either flaw as exploited. Sites that have not been patched should be treated as urgent.

If an update is difficult

Updating PHP is the only complete fix. Sometimes an update breaks a site, usually because an old plugin, theme or custom code relies on features that newer PHP versions removed.

Getting the update to work

  • Test on a staging copy first. Never trial a PHP change on the live site.
  • Read the error log. It normally names the plugin, theme or file that failed.
  • Update plugins, themes and extensions first. Then retry the PHP update.
  • Take the smallest safe step. If a jump to 8.4 breaks the site, move to the patched release on the current branch (8.2.35 or 8.3.36) while the compatibility problem is fixed. Note that PHP 8.2 reaches end of life on 31 December 2026.
  • Restart everything afterwards. Restart Apache, PHP-FPM and any other long-running PHP workers. Updating the files alone does not fix a running server.

Interim mitigations

If an update is not possible yet, these steps reduce exposure. PHP and CERT-EU are clear that they do not make a server safe, so treat them as a bridge to patching and not a replacement for it.

Mitigation 1: Limit the size and complexity of requests. Reduce post_max_size and max_input_vars in php.ini to limit large, complex malicious payloads. PHP's guidance for these flaws suggests roughly 8M for post_max_size on sites without uploads and 32M on sites with uploads, with upload_max_filesize kept below it. Enforce request size limits at the web server or proxy too. The max_input_vars limit is sensible general hardening, but it is not part of PHP's published guidance for these flaws.

Mitigation 2: Put a Web Application Firewall (WAF) in front of the site. Deploy strict WAF filtering at the network edge, such as Cloudflare or AWS WAF, to block unusual POST request structures. Cloudflare has switched on protection for known exploit patterns on all plans. On paid plans, check that managed rules are set to block, not just log. A WAF is only a partial defence, because an attacker who can reach the server directly can skip it. Restrict the server to accept web traffic only from the WAF.

Mitigation 3: Restrict access with IP allow-listing. If the PHP server runs an internal or administrative tool, only allow connections from known IP addresses or a VPN.

Mitigation 4: Turn off upload progress tracking. Set session.upload_progress.enabled = 0 in php.ini and restart all PHP workers. PHP recommends this for CVE-2026-109619, and most sites, including WordPress, do not use the feature. On PHP 8.5, also set fatal_error_backtraces = 0.

If none of this is possible, the US CISA, NSA and UK NCSC advise taking the unpatched system offline until it can be fixed.

After patching: check for signs of compromise

  • PHP processes starting shells, scripting tools or download tools.
  • New or unexpected files in the web root, new scheduled tasks, or new user accounts.
  • Very large PHPSESSID cookies in requests.
  • Large file-upload requests followed by memory errors or HTTP 500 responses.

A clean result does not prove a site was not hit, and credentials that sat in server memory may need to be rotated. If you are unsure, talk to your IT provider.

Hosted with Layer 3

Sites and applications hosted with Layer 3 were already on PHP 8.2.35 when that release came out, so the fix was in place immediately. Every hosted site has since been moved to PHP 8.4.27 as a precaution. That release is current, fully supported, and includes the same fix. Checks found no compromised sites. Clients do not need to change any settings or get in touch.

The move to 8.4 also puts those sites on a version with years of support left. PHP 8.2 reaches end of life on 31 December 2026, so the step was due anyway.

FAQ

Which PHP versions are affected?

PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36 and 8.2 before 8.2.35. PHP 8.1 and older are also affected, and the PHP project no longer supports them.

Do I need to update WordPress or my plugins?

Not because of this issue. The flaw is in PHP itself, and WordPress.org has confirmed no WordPress update is needed. Keep plugins and themes updated as normal.

My site runs PHP 8.1 or older. What should I do?

Upgrade to a supported release. There is no official fix for these versions, although some hosting providers and Linux vendors ship their own backported patches, so ask yours. Test the upgrade on a staging copy first.

Do the manual mitigations make a site safe?

No. They reduce exposure while the update is arranged, but updating PHP is the only complete fix.

Are sites hosted with Layer 3 already patched?

Yes. PHP 8.2.35 was applied as soon as it was released, and every hosted site has since been moved to PHP 8.4.27 as a precaution. Checks found no compromised sites, and no action is needed.

Need help?

If a website or server runs PHP and you want the version checked, an upgrade tested on a staging copy, and the fix applied, contact Layer 3. Managed IT services cover this kind of patching, and the cybersecurity work sits alongside it.

Sources

Information checked on 23 October 2026.

← Back to all articles