On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, four updates that fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. According to the PHP Foundation, the flaws sit in memory management and error handling, parts of PHP that nearly every request touches, and under the right conditions let an unauthenticated attacker execute code on servers running PHP. According to php.net, "There are no complete mitigations, updating is the only safe choice."
The background you need
PHP is a programming language that runs on web servers and builds pages before sending them to your browser. Wiz describes it as the language powering WordPress, Drupal and MediaWiki, the software behind Wikipedia, and says it runs a large share of the web.
A CVE is a public identifier for a specific security flaw. A CVSS score rates how severe a flaw is on a scale from 0 to 10; php.net rates both of these at 9.2, which falls in the critical band. Remote code execution (RCE) means an attacker can make the server run their own code. Unauthenticated means they do not need a login, a valid session, or any account first. Put together, an unauthenticated RCE is close to the worst case: a stranger on the internet can take over the machine.
The bugs are memory-safety issues. PHP serves many requests using long-lived worker processes that handle one request after another. According to Wiz, these flaws come from how PHP handles fatal errors mid-request, especially out-of-memory (OOM) errors, which can leave a corrupted internal state behind. A later request on the same worker can reuse that stale state, leading to memory disclosure or corruption. Think of it like a shared desk: if one person leaves mid-task and the next sits down before the desk is cleared, they can read or tamper with leftover notes. The analogy breaks because here an attacker can shape those leftovers on purpose to hijack control.
The flaws are in PHP itself, not in your application code. Wiz says even a simple Hello World app on an affected version can be vulnerable. The php.net advisory says it considers the risk highest for mod_php, the setup where PHP runs inside the Apache web server, with a demonstrated exploit that triggers before any application code runs.
One more term: coordinated disclosure. Researchers and the project agree to keep details secret until a patch is ready, and distributors get the fix early so users can update the moment it goes public. That secret period is the embargo.
What actually changed
The code did not just become dangerous. According to Wiz, the vulnerable code had been present for more than a decade, with every PHP version released in the last ten years affected by at least one of these issues, going back to version 5.4. The PHP Foundation says a potential version of the OOM problem was theorised during a 2024 external audit, but no concrete attack vectors were found at the time, and work on a fix stalled over hard trade-offs around backward compatibility and third-party extensions.
What changed is that the exploit became practical. Wiz says turning these flaws into working exploits required chaining multiple bugs and adapting to each target's memory layout, work that sat at the edge of what human researchers could practically achieve. Wiz credits frontier AI models with substantially lowering that barrier, saying a single researcher completed in a week what previously would have taken a world-class team months. According to the PHP Foundation, Calif researcher Ryan A reported an unconditional remote code execution with the same root cause on 11 August 2026, and OpenAI reported the same root cause the same day; from then on, fixing it became the top priority.
The disclosure also did not go fully to plan. The PHP Foundation says that on 20 October the two CVE IDs leaked on forums and social media with a wrong release time and a wrong CVSS score of 10.0, though no technical details leaked, and the project moved the release forward by one day in response. It also says Chainguard published built images containing the fix more than six hours before the coordinated release, letting anyone study the fix in binary form while others waited.
What it means for curious technical readers
The single fact that decides your next move: php.net says there is no complete mitigation, so updating is the only safe choice. If you run PHP anywhere that serves web requests, update to the patched release for your branch now.
Concrete consequences. Because the flaw is in PHP, patching your CMS or framework does not help; you need the PHP update itself. The php.net advisory lists mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed as at risk, and flags mod_php as highest risk. Separate from code execution, Wiz says attackers could read sensitive process memory such as passwords, tokens, API keys and certificates belonging to other requests, so treat secrets on an exposed server as potentially compromised.
If you run PHP 8.2, note that php.net says it reaches end of life on 31 December 2026 and will get no further security fixes after that, so plan an upgrade to a supported version.
What to watch next: the broader pattern. Both Wiz and the PHP Foundation frame AI-assisted research as lowering the cost of finding and exploiting old, complex bugs. Expect more reports of long-dormant flaws becoming practical. The PHP Foundation says it is changing its processes so complex fixes reach leadership sooner, and asks organisations that depend on PHP to fund that work.
What we don't know yet
Wiz says there are other tracked, and likely untracked, variants of this issue in the PHP codebase, though it states the released patch fixes the issue at its core and eliminates all variants in the patched release. The PHP Foundation says its security team monitored proof-of-concept code circulating after the leak but did not identify any functional exploits at the time of release; whether working exploits exist now is not settled in these sources. The sources also do not quantify how many servers were actually attacked before the patch, and the characterisation of AI as the thing that changed the risk is the researchers' own framing, not a measured fact.
php.net says there is no complete mitigation. The stopgaps in its advisory reduce exposure to specific attack paths but do not make an installation safe. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then rotate secrets that lived on an internet-facing PHP server.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)