PHP security update: Layer 3 hosted sites already patched

A critical flaw in PHP, the language behind WordPress and a large share of the web, was fixed in an emergency security release on Wednesday 21 October 2026. Every Layer 3 hosted website is already patched, so our clients do not need to do anything.

The PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to close two critical vulnerabilities that could let an attacker run their own code on a web server without logging in. PHP 8.2.35 was already applied to every Layer 3 hosted site as soon as it was released. We then moved every client to PHP 8.4.27 as a precaution. We have checked, and none of our clients' sites were compromised.

This article covers what happened, how the flaws came to light, what sites were exposed to, and what to do if you run PHP somewhere we do not manage. It reflects information available on 22 October 2026.

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 a day early. Proofs of concept are now circulating, so attempts to exploit unpatched sites are likely.
• All Layer 3 hosted sites are patched. PHP 8.2.35 was already on every site as soon as it was released. Every client has since been moved to PHP 8.4.27 as a precaution. We have checked, and none were compromised.
• Running PHP elsewhere? Update first. The interim steps below reduce risk but do not make a site safe.

What was announced, and when

The PHP project had planned a coordinated release for 22 October, but details of the flaws leaked on 20 October. It brought the release forward and published the fixes on Wednesday 21 October 2026 (UTC). Times below are UTC. The release landed at about 12:30 am on Thursday 22 October in Sydney.

• 20 Oct. Claims of two critical PHP flaws appear online, and the CVE numbers begin circulating with incorrect details.
• 20 Oct, later. PHP posts an advance notice of a security release, scheduled for 21 October.
• 21 Oct, about 13:30. PHP publishes its security advisories and releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• 21 Oct, afternoon. The researchers publish technical write-ups. CERT-EU and CISA urge immediate patching.

How the vulnerabilities were found

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

• CVE-2026-109618. If PHP runs out of memory while it is unpacking an incoming request, such as a file upload, the request data can be left half-built. PHP's clean-up then treats that data as valid, which opens a path to running code.
• CVE-2026-109619. Some request data can stay in use after its memory has been freed. A later request handled by the same worker can pick it up before it is reset.

Reports credit researchers from Wiz Research, OpenAI's Codex Security team and Calif with finding or reporting the flaws, and credit four PHP developers with the fix. Security firm Huntress reports that Calif revisited earlier research on PHP memory limits through OpenAI's Patch the Planet initiative, and found several points where a request could be interrupted and a reliable route to code execution. Wiz then showed attacks working without a login against WordPress, Drupal and Joomla in its tests.

The published sources do not describe exactly how each flaw was first spotted. What they do show is that the disclosure did not go to plan: details leaked a day before the coordinated release, so the PHP project released the fixes early.

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. PHP's security team said it had not identified functional exploits at release. 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.

What Layer 3 has done

Every Layer 3 hosted website was patched on release. PHP 8.2.35 was already applied to every client site as soon as the fix came out. We then moved every client to PHP 8.4.27 as a precaution. That release is current, fully supported, and includes the same fix.

We have checked, and none of our clients' sites were compromised. Clients do not need to update anything, change any settings or contact us. This is the reason we manage PHP on your behalf: a critical fix like this one is handled as part of the normal service, not as an emergency for you.

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

If your site fails to update: what to do

This section is for anyone running PHP somewhere we do not manage. 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 your current branch (8.2.35 or 8.3.36) while you fix the compatibility problem. 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 you genuinely cannot update 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 your 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 your 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.

FAQ

Is my Layer 3 hosted website affected?

No. PHP 8.2.35 was already applied to every Layer 3 hosted site as soon as it was released, and every site has since been moved to PHP 8.4.27 as a precaution. We have checked that none were compromised, and you do not need to take any action.

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.

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.

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 my site safe?

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

Need help?

If your website or server runs PHP and is not hosted by Layer 3, we can check its PHP version, test an upgrade on a staging copy and apply the fix. Contact Layer 3 for help, or read how our managed IT services keep systems patched and our cybersecurity approach for Australian businesses.

Sources

Information checked on 22 October 2026.

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Huntress: Rapid Response, php2shell
• Help Net Security: PHP2Shell, critical PHP vulnerabilities patched
• Rescana: Two critical PHP vulnerabilities fixed
• Codeable: PHP security release, what WordPress site owners need to do