logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·29.10.26
← Back to news

Today's PHP security release, and how we're strengthening security

Original article
thephp.foundation|236 points|119 comments|by ejohnso49|Oct 21, 2026

Update on PHP Security: Recent Releases and Systemic Improvements

PHP Foundation

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.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 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 IDRoot CauseImpactVector
CVE-2026-109618 / GHSA-w8hw-w9fx-j79wOOM CorruptionRemote Code ExecutionApache (mod_php) →\rightarrow→ Pre-app code; PHP-FPM →\rightarrow→ App-level paths
CVE-2026-109619 / GHSA-6wmf-4rv5-p3rpStale StateRemote Code ExecutionApache (mod_php) →\rightarrow→ Use-after-free via fatal error

Technical Nuances

  1. The OOM Issue: If a request hits the memory_limit at 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: Request→OOM EventPartial State→Memory Corruption→RCE\text{Request} \xrightarrow{\text{OOM Event}} \text{Partial State} \rightarrow \text{Memory Corruption} \rightarrow \text{RCE}RequestOOM Event​Partial State→Memory Corruption→RCE
  2. 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) and Daybreak 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.