# PHP patched two 9.2 flaws in its core. A fully updated WordPress is still exposed.

PHP shipped four security releases on 21 October 2026 — 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — fixing the two vulnerabilities now known as PHP2Shell, both rated CVSS v4.0 9.2 by the PHP security team. They are tracked as CVE-2026-109618 and CVE-2026-109619. An attacker needs no account and no application bug. One request can execute code on the server, or read passwords, tokens and API keys out of PHP worker memory.

What matters is where the flaw lives. It is in the PHP runtime, not in your application. PHP handles the request before any application code runs, so a WordPress, Drupal, Joomla or Laravel install updated to the latest version with every plugin current is still exposed if the PHP underneath it has not been replaced. [PHP's advisory](https://www.php.net/archive/2026.php) puts every web-facing deployment on the list: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php rated highest risk and a demonstrated exploit where an unauthenticated request triggers the attack before application code executes. Cloudflare is blunter about the consequence: because the flaws sit in the runtime, [updating website code or a plugin does not fix them](https://blog.cloudflare.com/php-vulnerabilities-waf-protection). This is not a theoretical window either. Cloudflare says it observed attack traffic against customers before the official release date.

#### Four versions carry the fix, and PHP 8.1 and older get no release

The only complete remediation is the version bump. The mapping is 8.5 to 8.5.12, 8.4 to 8.4.27, 8.3 to 8.3.36, and 8.2 to 8.2.35. The 8.5.12 release note leaves no room: there are no complete mitigations, and updating is the only safe choice.

![PHP2Shell patched versions: 8.5 to 8.5.12, 8.4 to 8.4.27, 8.3 to 8.3.36, 8.2 to 8.2.35; 8.1 and older get no official release and 5.4 to 7.3 get no patch](https://s4.tenten.co/learning/content/images/2026/10/english-infographic-2-4.png)

PHP 8.1 and older no longer receive updates from the project. The security team published minimal source backports for 7.4, 8.0 and 8.1 on branches named like `PHP-7.4-CVE-2026-109618-109619`, with no binary releases. Versions 5.4 through 7.3 get nothing. For most readers the practical move is the distribution package, because Linux distributions and LTS vendors received patches ahead of public release, and [AlmaLinux pushed packages to production repositories on 21 October](https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/). PHP adds one warning for anyone relying on the volunteer-maintained `rpms.remirepo.net`: that repository had no updates on release day, so switch to distribution packages or build from source.

Two checks are easy to skip. First, `php -v` reports the command-line binary, which can be a different build from the one serving requests, so confirm the web SAPI as well with `php-fpm -v` or the Apache module. Second, a higher version number is not a patched one: PHP 8.6.0 was still at RC3 on 8 October and php.net labels it not for production. These four releases are the fix. While you are in there, note that 8.2 reaches end of life on 31 December 2026.

#### Cloudflare's rules went live about eleven hours ahead of the patch

The sequence is worth reading closely. PHP gave advance notice on 20 October of a release scheduled for 21 October at 14:00 UTC, reserving the right to go earlier if details became public or evidence of active exploitation appeared. Cloudflare's protection went live at 03:02 UTC on 21 October, roughly eleven hours before that release, and Cloudflare reports attackers mutating payloads to get past it.

![PHP2Shell timeline: Aug 11 Calif reports to PHP, Aug 19 Wiz finds it, Aug 24 Wiz reports to PHP, Oct 20 CVE IDs circulate, Oct 21 03:02 UTC Cloudflare rules live, Oct 21 14:00 UTC PHP ships the fix, the last two steps eleven hours apart](https://s4.tenten.co/learning/content/images/2026/10/english-infographic-1-5.png)

So attacks were running while the fix had not yet shipped. How much damage followed is still unsettled in public reporting. watchTowr says it reproduced both vulnerabilities and is observing exploitation attempts against both. Patchstack's telemetry shortly after release showed probing rather than confirmed breaches. Huntress reports no confirmed compromise, and Cloudflare makes no claim either way about whether any customer was breached. The PHP Foundation said the team identified no functional exploits at the time of public disclosure. Attack traffic and probing are confirmed; a confirmed compromise is not.

The leak is narrower than some coverage suggests. By the PHP Foundation's account, coordinated disclosure held until roughly 15:00 UTC on 20 October, when the two CVE identifiers began circulating on forums and social media with a wrong release time and an incorrect CVSS of 10.0, while no technical details leaked. The real score is 9.2. The release had been scheduled for 22 October and moved up a day once the identifiers were out.

#### PHP's own mitigations carry two traps

If the upgrade genuinely cannot happen yet, PHP published partial mitigations while stating that only an update is a complete solution.

For CVE-2026-109618:

```ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 2M
```

Set `memory_limit` through `php_admin_value` in the FPM pool or Apache configuration. Raise `post_max_size` to `32M` only if file uploads are required, and keep `upload_max_filesize` below it.

For CVE-2026-109619:

```ini
session.upload_progress.enabled = 0
fatal_error_backtraces = 0
```

The second directive applies to PHP 8.5 only. Both require restarting every worker to take effect.

Now the traps. PHP states explicitly that you should not substitute `RLIMIT_AS` or `RLIMIT_DATA`, because those can cause the very allocation failure the attack depends on; container or cgroup limits belong there as an availability boundary instead. Do not rely on `ini_set()` or an FPM `.user.ini` for any of this. And one line worth copying into your runbook: hiding diagnostics with `error_reporting`, `display_errors` or `@` does not help. Cloudflare positions its WAF rules as one layer of defence in depth and tells customers to patch PHP even with those rules active.

For the gap before patching, Wiz published signals worth watching: unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed `PHPSESSID` response cookies, and unexplained PHP worker churn. Because these faults occur below the application layer, application logs often carry little context.

#### That 70% figure means something narrower than it sounds

Nearly every writeup says the flaws affect 70% of the world's websites, and the Wiz post says it too. The number traces to W3Techs, whose actual sentence carries a decisive condition: [PHP is used by 69.3% of all the websites whose server-side programming language we know](https://w3techs.com/technologies/details/pl-php), as of 22 October 2026. Sites whose server-side language cannot be determined are not in the denominator. PHP's dominance among identifiable sites is not in dispute, but "70% of the internet" and "69.3% of sites whose language is known" describe differently sized sets, and the first drops the condition that makes the figure measurable.

Credit got flattened the same way. Cloudflare's advisory names four disclosing parties: Calif.io, Wiz, OpenAI and Quarkslab. Multiple outlets report that Calif found several paths on 1 August and reported the first bug to PHP on 11 August, starting coordinated disclosure 13 days before Wiz's 24 August report, with Calif's work running under OpenAI's Patch the Planet initiative. That ordering comes from press coverage rather than an official timeline. Wiz's post opens by saying its own research team uncovered the vulnerabilities and thanks the PHP team, Calif and OpenAI for their help, without noting that someone else reported first.

My read is that the AI signal here is the repetition, not any single vendor's demonstration. Two unconnected teams, running different primary models, hit the same decade-old code within three weeks of each other. OpenAI and Calif used GPT-5.6 Sol; Wiz used Gemini 4 Argon alongside GPT-5.6 Sol and its own Wiz Atlas. One discovery can be luck. Two independent hits inside the same short window look more like the cost of finding this class of bug actually falling.

What nobody has quantified is how much is left. Wiz says the post covers four exploitable bugs following one pattern, that other tracked and likely untracked variants exist in the PHP codebase, and that the team's patch addresses the root cause and eliminates all variants in the patched release. PHP has not said how many variants remain on its list.

#### Sources

- [PHP news and security advisory archive for 2026, including the 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release notes](https://www.php.net/archive/2026.php)
- [Cloudflare deploys protections against php2shell](https://blog.cloudflare.com/php-vulnerabilities-waf-protection)
- [Wiz Research, PHP2Shell](https://www.wiz.io/blog/php2shell-php-rce)
- [Tenable, php2shell (CVE-2026-109618, CVE-2026-109619) frequently asked questions](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote)
- [W3Techs usage statistics for PHP](https://w3techs.com/technologies/details/pl-php)
- [AlmaLinux, patched PHP packages released](https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/)