What to do right now
PHP released the fixes on 21 October 2026 at 14:00 UTC, a day ahead of the planned embargo. Update to the patched version on whichever branch you run:
| Branch | Patched version | Notes |
|---|
| PHP 8.5 | 8.5.12 | Current stable |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | End of life 31 December 2026 |
| PHP 8.1 and older | No binary release | Minimal source backports published for 7.4, 8.0 and 8.1 |
Linux distributions and LTS vendors received the patches early, so a vendor package may already be waiting in your repository. Check there before building from source.
What the two flaws actually are
Both carry a CVSS v4.0 score of 9.2 and both end in unauthenticated remote code execution running with the privileges of the web worker.
CVE-2026-109618 - RCE via out-of-memory corruption
PHP can be interrupted by its own out-of-memory handling while internal request data is only partially initialised. Request cleanup then treats that half-built data as valid. That is the path to code execution.
CVE-2026-109619 - RCE via stale global state
Request-owned internal state can outlive the memory backing it. A later request landing on the same worker may touch that stale state before it gets reset, producing a heap use-after-free, memory disclosure, or code execution.
The second one matters more than it reads on paper. It means the attack does not have to succeed on the request that sets it up. One request poisons a worker, a different request later collects.
Why mod_php is called out specifically
Every SAPI that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP singles out mod_php as the highest risk, and the reason is specific rather than general.
PHP says it validated complete remote code execution over plain HTTP against mod_php using default input and memory limits and an ordinary prefork configuration. No unusual settings, no hardened-config exception. An unauthenticated request triggers the flaw before any application code executes, so your routing, your authentication middleware and your framework are all downstream of the thing being exploited.
That is also why a WAF rule is a weak answer here. There is no application-layer request signature to match on in the way there would be for an SQL injection or a path traversal.
The mitigations, and why PHP says they are not enough
This is the part most coverage is flattening into "apply the mitigations". PHP published them and then stated directly that they reduce exposure but do not make an installation safe, and that updating is the only complete fix.
The published measures:
- Set
memory_limit=-1, applied with php_admin_value so applications cannot override it
- Lower
post_max_size
- Set
session.upload_progress.enabled=0 in php.ini or the server configuration
- Set
fatal_error_backtraces=0 on PHP 8.5
And one explicit instruction about what not to do:
- Do not use
RLIMIT_AS or RLIMIT_DATA
The first item is the one that will catch people out, because it inverts the normal advice. Hardening guides have told administrators for years to cap memory_limit. Here you remove the cap, because the first vulnerability lives in the out-of-memory path itself. Starving PHP of memory is not a defence against this bug, it is how you reach it. The same logic is why the address-space and data-segment resource limits are called out as counterproductive rather than merely useless.
If you apply the mitigations and leave the update for the weekend, you have a server that is harder to exploit and still exploitable.
Two traps in the version numbers
PHP 8.6.0 RC4 contains the fix and is still not for production
PHP 8.6.0 RC4 was published the same day and does include both fixes. It is a release candidate. RC5 is planned for 5 November 2026. The highest version number on the downloads page is not the one to deploy.
PHP 8.1 and older get source backports only
There are no upstream binary releases for 7.4, 8.0 or 8.1. The security team published minimal source backports for people who build from source or who have no LTS vendor behind them. On shared hosting that is nobody, which makes this the sharpest edge of the whole incident: a site sitting on PHP 8.0 at a budget host has no patch coming, and no mitigation that closes the hole.
If that describes a server you run, the realistic options are to move it to a supported branch, take it offline, or put it behind a VPN until you can do one of those. PHP 8.2 reaching end of life on 31 December 2026 means the same question arrives again in ten weeks for anyone patching to 8.2.35 and stopping there.
How it leaked
The embargo was supposed to lift on Thursday at 11am ET.
- 20 October, morning: a Hacker News post claimed the two flaws were headed for disclosure. It was taken down, but screenshots had already spread
- 20 October: watchTowr confirmed the leak was real
- 20 October: PHP published an advance notice and moved the release forward to Wednesday 21 October at 14:00 UTC
- 21 October, around 9:30am ET: the patched versions went out
A short exploitation video was posted and then removed. A public proof-of-concept repository now exists. We are not linking it, and its existence is the only part of this that should change your timeline: the window between disclosure and commodity scanning is the shortest it has been for a PHP core flaw in years.
Is it being exploited yet
Huntress reported no in-the-wild exploitation across its partner base as of 21 October, 10am ET. Other researchers reported attacks beginning to emerge around the same time. PHP states an exploit exists for mod_php.
Treat "not yet widely exploited" as a description of Wednesday morning, not of the week ahead. With a public PoC and a flaw that triggers pre-authentication, mass scanning is the expected next step rather than a possibility.
What exploitation looks like on a box
Because the flaw executes with the web worker's privileges, the visible signature is the PHP process doing something a web server has no business doing. Watch for the php-fpm, httpd or php-cgi process spawning:
- a shell - sh, bash, dash
- an interpreter - python, perl, ruby
- a download tool - curl, wget
Florian Roth's process-watcher can run in observe mode to alert on exactly this pattern. If you cannot patch within the hour, getting that alerting in place is a better use of the next twenty minutes than editing php.ini.
Frequently asked questions
Which PHP versions are affected?
All PHP installations serving web requests. Reports point to PHP 5, 6, 7 and 8, with fixes published for the supported 8.x branches and minimal source backports for 7.4, 8.0 and 8.1.
Does a WAF protect me?
Not reliably. The flaw triggers before application code runs, so there is no application-layer payload pattern to filter on in the usual way. A WAF is a stopgap for an end-of-life server you cannot patch, not a substitute for patching one you can.
I use PHP-FPM, not mod_php. Am I safe?
No. PHP-FPM is affected. mod_php is flagged as highest risk because PHP demonstrated full RCE against it with default settings, not because the other SAPIs are unaffected.
Do I need to reboot or just restart PHP?
Restart the PHP service after updating - php-fpm, or the web server for mod_php. The second vulnerability depends on state persisting inside a worker process, so a worker still running old code is still a worker running old code.
Is PHP 8.2.35 a safe place to stop?
It is safe for this flaw. PHP 8.2 reaches end of life on 31 December 2026, so it is a patch, not a plan.
What if my host controls the PHP version?
Ask them today which patched build they are on and when it rolls out. Managed and shared hosts received vendor patches early. A host that cannot answer that question on the day of a CVSS 9.2 pre-auth RCE has told you something useful.