Today's PHP security release, and how we're strengthening security
Update on PHP Security: Recent Releases and Systemic Improvements
Published: October 21, 2026
Source: The PHP Foundation | News & Security
Earlier today, the PHP project deployed critical updates across several supported branches to address severe security flaws. The updated versions are:
PHP 8.5.12PHP 8.4.27PHP 8.3.36PHP 8.2.35
These patches resolve two critical vulnerabilities that could potentially allow an unauthenticated actor to achieve remote code execution (RCE) on a server. While technical specifics and update guides are available on php.net, this article focuses on the "how" and "why"—the discovery process, the evolution of PHP's security posture over the last two years, and the necessity of organizational support.
🛡️ Analysis of the Critical Vulnerabilities
Both vulnerabilities reside in the most fundamental layers of the engine: memory management and error handling. Because these systems are touched by nearly every single request, fixing them without degrading performance or breaking third-party extensions was an immense challenge.
Vulnerability Summary
| CVE / GHSA ID | Root Cause | Impact | Vector |
|---|---|---|---|
CVE-2026-109618 / GHSA-w8hw-w9fx-j79w | OOM Corruption | Remote Code Execution | Apache (mod_php) Pre-app code; PHP-FPM App-level paths |
CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp | Stale State | Remote Code Execution | Apache (mod_php) Use-after-free via fatal error |
Technical Nuances
- The OOM Issue: If a request hits the
memory_limitat a precise moment, PHP might leave internal data partially initialized. The engine then treats this "garbage" as valid data, leading to memory corruption. Mathematically, we can view the state transition as: - The Stale State Issue: A fatal error occurring at a critical juncture can leave the internal state pointing to memory that belonged to a previous request. A subsequent request handled by that same worker can then access that freed memory (a classic use-after-free scenario).
🔍 The Road to Discovery and the "Structural Failure"
The journey to these fixes began in 2024 during PHP's first external security audit in years. This was funded by the Sovereign Tech Agency, coordinated via OSTIF, and executed by Quarkslab.
During the remediation of a Quarkslab report, a Foundation-contracted core developer spotted the first indicators of the OOM problem. However, the path to a fix was not linear:
- 2024: An exploit was theorized, but no concrete attack vector was proven. Other high-impact issues took priority.
- The Dilemma: The security team faced several competing fix strategies. Each had a downside:
- Breaking backward compatibility.
- Introducing new Denial-of-Service (DoS) vectors.
- Requiring impossible-to-coordinate changes across the extension ecosystem.
"We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources."
The team relied on consensus, which led to paralysis. Combined with a small pool of developers possessing the deep engine knowledge required, the project stalled and restarted for months.
🚀 Strengthening the Security Infrastructure
To prevent a recurrence, the PHP Foundation has fundamentally restructured how security is handled.
👥 Organizational Growth
The Foundation has moved toward a professionalized security organization:
- May 2026: Established the Ecosystem Security Team for better triage and hardening.
- Volker Dusch: Serving as AI Security Engineer in Residence to bridge the gap between the Foundation and the security team.
- Alexandre Daubois (July): Joined to accelerate the triage and fixing of reports.
- Daniel Scherzer (September): Joined specifically to focus on hardening.
🛠️ Tooling and Audits
The toolkit for validating vulnerabilities has expanded significantly:
- AI-Driven Scanning: Utilized
Claude Mythos(via Alpha-Omega) andDaybreak Red(via OpenAI). - Environment Parity: Implementation of sanitizer builds and reproduction environments that mirror CI across all supported platforms.
- Patch the Planet: This program brought in the firm Calif for an audit starting July 30, 2026.
Timeline of the OOM Resolution
📈 Moving Forward
The surge in AI-assisted research means the volume of reports is increasing. To manage this, the team is shifting its operational philosophy:
- Move from consensus-based to majority-based decision making.
- Encourage pragmatic compromises to avoid stagnation.
- Secure full-time funding for dedicated security engineers.
- Continue expanding the "Patch the Planet" initiatives.
Without the Foundation's financial backing, the round-the-clock, weekend-spanning effort required to coordinate with Calif, OpenAI, and Wiz to kill the OOM vulnerability would have been impossible.
For more details on how reports are managed, see Alexandre Daubois's recent piece: How the PHP Security Team Handles Your Reports.