The PHP Foundation said the critical vulnerability it patched last night had already shown warning signs in 2024, but the fix stalled for nearly two years because developers could not identify a concrete exploitation path and could not settle on a repair strategy without serious trade-offs.
In a post-incident write-up, the foundation described the delay as a "structural failure" tied to its security decision process and limited resources. At the same time, it said the 2024 finding reflected only a theoretical possibility of exploitation. The team had not confirmed a practical path at that stage, which it distinguished from knowingly leaving a remotely exploitable bug unpatched.
Early signs surfaced while fixing a different issue
According to the foundation, the first signs appeared when a core developer was working on another issue reported in a Quarkslab audit. The memory bug at the center of the current incident was not listed as an item in that audit report. Security firm Calif gave the same account: the issue was not fixed at the time because exploitability had not been confirmed.
When the audit results were published in April 2025, the foundation said publicly that the PHP development team had addressed all discovered issues. This memory problem was not part of the audit findings, and it was not disclosed separately at that time.
The flaw involved OOM handling and corrupted internal state
The foundation said PHP’s memory_limit, which caps the amount of memory available to a single request, sits at the center of the problem. If a request hits that limit at the wrong moment and runs into OOM, or out-of-memory, PHP can leave behind partially initialized internal data structures. Those structures may later be treated as valid, leading to memory corruption.
The hard part was where the bug lived. Memory management and error handling sit deep in code paths that nearly every request passes through. The foundation said proposed fixes came with difficult costs: some would break backward compatibility, some could introduce new denial-of-service risk, and some would force a large number of third-party extensions to change as well.
According to the GitHub security advisory, the final patch removed the old behavior that aborted a request immediately on memory exhaustion and replaced it with a stop at the next safe point. In practice, that rewrote how PHP handles OOM conditions. The foundation also said only a small number of core developers understand the engine at that depth, and many of them split time across multiple responsibilities, which contributed to repeated stops and restarts in the patching effort.
The issue became top priority in the summer of 2026
The turning point came in the summer of 2026. The foundation brought PHP into OpenAI’s Patch the Planet program, and Calif began its audit on July 30.
On Aug. 11, Calif researcher Ryan Austin reported a remote code execution bug that required no special conditions and shared the same root cause as the memory issue seen in 2024. OpenAI independently reported the same root cause on the same day. Wiz then added an attack path on Aug. 24, and OpenAI followed with another on Sept. 18, giving the foundation a clearer picture of the full impact.
From that point, the foundation said, the bug became the top priority for its security staff. Multiple people worked on it full-time, and the patch was released more than two months later.
Calif listed 11 applications exposed without login
Calif said 11 applications could be compromised without authentication, including WordPress, Drupal, and Joomla. It also said the earliest affected code path could be traced back to PHP 5.4.0, released in 2012.
Austin wrote that he did not rely on a special framework or on models unavailable to the public. Instead, he used his familiarity with the target’s vulnerability history and steered AI in that direction. As he put it, "LLMs default to looking from the newest, most visible vulnerabilities into nearby older code, and they are less likely to start on their own from obscure exploitation techniques from 20 years ago."
The foundation says it has changed its internal process
Looking ahead, the foundation said it has started allowing decisions to move forward by majority vote and is encouraging compromise when fixes involve difficult trade-offs. Severe vulnerabilities that get stuck in those trade-offs will be escalated to leadership earlier.
It also said an ecosystem security team was formed in May and that new staff have joined. Since July 1, the team has published 15 CVEs and handled another 106 reports that were invalid, duplicates, or could not be reproduced.
The foundation also called on companies, cloud providers, and governments to provide funding. It said PHP underpins government services, online stores, and banks, while security work still depends on a small number of funded developers and limited volunteer support.
What site operators should do now
The guidance for website administrators was direct: upgrade to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. The affected scope covers all PHP deployments that handle web requests, including PHP-FPM, mod_php, FrankenPHP, and LiteSpeed.
Official support has already ended for versions below PHP 8.1. For PHP 7.4, 8.0, and 8.1, the security team has provided minimal source patches for users who compile from source.
Temporary mitigations include setting memory_limit to -1 or lowering post_max_size, but the foundation said those measures are incomplete. Upgrading is the only complete fix.