What happened
In a statement published on Wednesday, the PHP Foundation described the history of two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which were being discussed together as PHP2Shell. The Foundation said the history of CVE-2026-109618 reaches back to 2024, when PHP underwent its first external security audit in several years. Officials took no action at that point. The organization’s account says the later renewed review made the full impact clearer and prompted a new response.
The Foundation said both flaws sit in parts of PHP that nearly every request touches. That central role made the vulnerabilities serious, but also made a fix difficult: maintainers were weighing backward-compatibility breaks, possible denial-of-service risks, and changes that could affect many third-party extensions. The Foundation said the PHP security team operates by consensus and struggled to choose among those trade-offs. It also cited a small group of core developers with deep engine expertise and many responsibilities. Work on a fix stalled and restarted repeatedly over months, partly because there was no known route to remote code execution at the time.
The issue returned to priority in 2026 as code-review services from Anthropic and OpenAI were used to scan PHP platforms. A researcher at cybersecurity firm Calif reported the bugs on August 11; the Foundation said reports from Calif, OpenAI, Wiz and Trail of Bits made the full impact clear. From August 11 onward, fixing the vulnerabilities became the Foundation security team’s top priority. The Record reports that Calif also credited another researcher with initially finding the vulnerability and developing an exploit.
The Foundation said its coordinated disclosure process was running smoothly until rumors began circulating on social media two days before the statement. It moved disclosure up by a day, but said it could not release immediately because the fix was still being packaged. The Foundation said a Calif proof-of-concept video, later deleted, showed the code working against targets and revealed additional details; it said circulation of the video accelerated proof-of-concept development. It reported monitoring PoCs that circulated Tuesday evening without identifying functional exploits.
The sharpest disagreement concerns Chainguard’s early publication of images containing the fix on Wednesday. The Foundation said Chainguard had received the patch in advance so its users could update at disclosure, but argued that publishing the fix early let attackers study it while other PHP users were still waiting. Chainguard CEO Dan Lorenc told The Record he had seen exploitation attempts the previous night and made a judgment call to release. He also said the maintainers had done a good job and that the industry needs to handle such incidents faster and with better coordination. The Foundation said it had listed dozens of internal changes intended to ensure serious vulnerabilities facing difficult trade-offs reach its leadership sooner.
What the archive adds
This is a new development in a known PHP security thread, not simply a repeat of the vulnerability alert. Our October 24 Field Note on the CERT-EU PHP advisory covered a third PHP RCE vulnerability disclosed on October 23 and noted that no out-of-band patch was planned. The current account adds the Foundation’s history of the two PHP2Shell flaws, the role of AI-assisted reviews and a disagreement about embargo timing.
Trend signal
No supplied SITE_PATTERNS thesis directly fits this dispute. It concerns vulnerability discovery, patch packaging and coordinated disclosure in a widely used runtime; the available patterns focus on agent systems, protocols, security boundaries and related product architecture rather than the governance of a software project’s security response. The story should therefore be treated as a concrete incident and process account, not evidence for a broader pattern.
Why now
The Foundation says online rumors emerged shortly before disclosure and that it moved the announcement forward by one day. It also says the fix was still being packaged, while Chainguard’s CEO told The Record that he had seen exploitation attempts the preceding night. Those competing accounts explain the immediate timing, but the supplied material does not independently establish when the attempts began or what they targeted.
Connections to other events
The Foundation’s account connects the current disclosure to an earlier point in the PHP security story: the 2024 external audit that identified an issue but led to no action. It also connects to the separate PHP vulnerability covered in our CERT-EU advisory note, while distinguishing that third vulnerability from the two flaws discussed here. These links show a cluster of security attention around PHP, not proof that the vulnerabilities share a cause or exploit path.
Why it matters
For teams that maintain software with large extension ecosystems, the account highlights a real coordination problem: a security fix can be technically ready before it is safely distributable, and changing a central code path may carry compatibility and performance consequences. Consensus can help a project account for downstream effects, but the Foundation’s description shows how it can also leave ownership unclear when trade-offs are hard and specialist maintainers are stretched thin.
AI-assisted review matters here as a discovery aid, not as proof that automated scanning independently resolves security work. The reports helped make the issues’ impact clear, according to the Foundation, but people still had to assess severity, settle on a fix, package releases and coordinate disclosure. For downstream teams, the practical lesson is to know which PHP versions receive updates, track project security announcements, and plan for prompt patch evaluation rather than assuming a headline count of internet-facing systems equals confirmed exposure.
Limits and uncertainty
The source is The Record’s report of the PHP Foundation’s statement and Chainguard CEO Dan Lorenc’s response; it is not a full independent technical analysis of either vulnerability. The supplied material does not provide the complete patch diff, reproduce the proof of concept, establish the number of systems that were vulnerable, or confirm successful exploitation. Its reported IP-address figures describe PHP’s internet-facing footprint, not verified vulnerable targets. It also does not resolve the disagreement over whether Chainguard’s early publication reduced risk by responding to attempted exploitation or increased risk by exposing fix details before all users could update. The Foundation’s list of planned internal changes is not detailed here.
Skill to build now
This week, verify which PHP versions your services actually run and whether each is still supported by the PHP Project. The report says patches apply to versions back to PHP 8.2, while older versions no longer receive project updates. Record who owns the upgrade decision for each service, then make sure your team has a way to review emergency runtime patches alongside extension compatibility and deployment constraints.
Reader takeaway
AI-assisted code review helped bring long-standing PHP flaws back into focus, but discovery was only the start. The hard part was resolving compatibility trade-offs, preparing a fix for a central runtime, and agreeing when to publish it. Treat the competing accounts as evidence of a coordination failure mode, not as a settled verdict on who made the right call.