PHP's critical flaws expose deeper rifts over disclosure and open-source maintenance

Several websites went dark on Wednesday as operators shut down services to apply fixes for two critical flaws in PHP, the scripting language powering roughly 70% of the web. The precautionary moves did not indicate active breaches, but the vulnerabilities themselves posed serious risks. What may prove more consequential than the bugs themselves is how the embargo on the patches unraveled.

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619. PHP project maintainers released fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12; users running older branches must either upgrade to a supported version or apply a backport from their distributor. WordPress notified site owners to update PHP, though the vulnerabilities do not require a WordPress patch.

The incident, dubbed PHP2Shell, revealed more than dangerous code in a ubiquitous language. It triggered a clash over coordinated disclosure practices and highlighted mounting pressure on open-source maintainers as AI-powered security research accelerates the pace of vulnerability discovery and exploitation.

The path to this emergency began with OpenAI's Patch the Planet initiative. Security firm Calif, working in that program, used GPT-5.6 Sol to identify a route to remote code execution and reported findings to PHP on August 11. OpenAI independently disclosed the same underlying issue that same day; Wiz shared its findings on August 24. PHP's maintainers led the remediation effort. They had detected signs of the underlying out-of-memory condition during a 2024 audit, but its full severity became apparent only in August.

This is about as broad as a critical vulnerability gets.

Moshe Siman Tov Bustan, OX Security

Moshe Siman Tov Bustan of OX Security continued: "If you have a publicly accessible PHP instance and haven't patched it, start from the assumption that you're exposed. If you find evidence of exploitation, assume compromise, not just exposure." OX Security CEO Neatsun Ziv added: "This is what an internet-scale vulnerability looks like. When a flaw hits technology this ubiquitous, the blast radius isn't one product or one industry. It's the web itself."

The incident has sparked debate among open-source leaders about how the industry should respond when discovery accelerates beyond remediation capacity. The New Stack has previously covered the surge of AI-generated vulnerability reports overwhelming maintainers; the PHP case adds a fresh dispute over whether an embargo truly protected users once information began leaking.

Details of PHP2Shell began circulating before patches were available. The PHP Foundation reported that two CVE identifiers spread on October 20, followed by an unintentionally published proof-of-concept video. Chainguard CEO and co-founder Dan Lorenc then released patched container images more than six hours ahead of the October 21 coordinated release, citing evidence of active exploitation as justification for breaking the embargo.

The speed of real-world attacks is documented. After WordPress released version 7.1.2 on September 22 to address CVE-2026-87902, Patchstack detected probes against WordPress installations that same day and file-write attempts the following day. However, the WordPress case does not establish whether attackers successfully exploited these PHP flaws when Chainguard published its images.

Why Lorenc broke the embargo

In correspondence with The New Stack, later echoed in a LinkedIn post, Lorenc explained that Chainguard had independently discovered the same issue using its own testing infrastructure and a frontier AI model tasked with "find bad vulnerabilities in PHP." Chainguard learned of an incoming PHP issue on Friday, October 16, found the vulnerability that night, received a complete briefing on Saturday, October 17, and participated in fix testing.

Leaks began Monday, October 19, and intensified Tuesday night when multiple vendors reported what they believed were active exploits. After a call with other researchers, Lorenc decided to ship the fixes and immediately informed the disclosure group. He contended that coordinated disclosure guidelines permitted early release upon evidence of exploitation in the wild.

Three factors shaped the decision, according to Lorenc: how readily Chainguard had independently discovered the vulnerability and created an exploit, how much information was already circulating about the flaws and fixes, and the evidence shared regarding active exploitation. Chainguard made its patched images publicly available rather than restricting access to customers. Lorenc acknowledged that the PHP Foundation disagreed with his action.

The PHP Foundation's response was direct: "Chainguard unilaterally broke the embargo and published built images containing the fix." The foundation noted that Chainguard had received the patch early specifically so customers could update at the agreed disclosure time. In the foundation's assessment, releasing built images allowed attackers to study the fix while other PHP users still lacked patches.

We're not always going to get it right, and not everyone is going to agree with our decisions.

Dan Lorenc, Chainguard

Lorenc wrote that he regretted the stress his decision imposed on PHP's maintainers, adding that Chainguard's objective was to protect the broadest population possible.

Defining active exploitation

The core disagreement centered on what constitutes evidence of active exploitation. Lorenc stated that other vendors had observed exploits in the wild. The PHP Foundation countered that its security team had not identified a functional exploit among the circulating proofs of concept at the time of release.

Amazon Threat Intelligence later reported an apparent exploit attempt against one of its honeypots on October 17 and additional attempts early on October 21. The company noted, however, that it remained unclear whether those attempts would have succeeded against production systems.

The competing risks are evident. An embargo allows distributors to prepare updates in concert. An early release may protect users who can obtain the fix. Yet it also provides attackers with clues while other PHP users remain unpatched.

The deeper structural problem

The PHP Foundation also acknowledged a separate failure in its response. Developers observed signs of the out-of-memory issue during a 2024 audit but did not identify a concrete path to remote code execution. The foundation said competing fixes presented difficult compatibility and security trade-offs, and progress repeatedly stalled. It labeled the delay "a structural failure" stemming from its decision-making process and insufficient resources.

The New Stack has previously examined connections between paid maintenance and security outcomes. The foundation is now seeking greater support from companies, hosting providers and governments that rely on PHP.

Canonical, parent company of Ubuntu Linux, offers a less critical view of the overall response. Luci Stanescu, Canonical's security engineering manager, stated in an email: "Canonical supports and recommends coordinated vulnerability disclosure according to best practices. The early embargo leak by a third-party was unfortunate, but we believe the disclosure process worked well." This assessment differs in tone from the PHP Foundation's criticism: a leak can damage part of the process without necessarily undermining the broader coordination.

For Peter Nelson, chief technology officer at CIQ and founding sponsor of Rocky Linux, the PHP incident fits a broader shift already occurring in Linux security. "We have seen AI used in exploiting vulnerabilities in the kernel space for the past six months," Nelson says. "This represents more research going into other widely used software programs like PHP. We expect to see more of it as open-source projects continue to use AI and other means to harden the code and provide a greater defense against vulnerabilities like this."

Today, such vulnerability exploitation requires a frontier model. Tomorrow that won't be the case.

Peter Nelson, CIQ

Nelson anticipates continued pressure as advanced vulnerability-research capabilities become more widely accessible. Lorenc similarly frames the challenge as an industry-wide problem extending beyond PHP. "This is unfortunately the new normal for the industry, and we're going to need to work together as one team to have a chance at securing our critical infrastructure fast enough to stop attackers from causing real harm."

Immediate operational demands

For enterprise environments, the immediate impact is operational. Gunnar Hellekson, Red Hat's vice president and general manager for Lightwell, a joint Red Hat–IBM initiative addressing vulnerable open-source dependencies, told The New Stack that the PHP flaws illustrate risks in foundational software that organizations often overlook. Stable production software can be easy to ignore even as AI-driven discovery increases both the volume and velocity of vulnerability findings. The PHP issues underscore how deeply open source is embedded in systems running businesses.

Hellekson emphasized obtaining tested updates from trusted sources, particularly for vulnerabilities affecting critical programs like PHP. "Given the potential impact of these vulnerabilities, Red Hat recommends that customers deploy validated, tested patches as soon as they are available from trusted sources including Red Hat, even outside of normal patching windows."

Software that supports millions of websites cannot depend on a handful of maintainers to manage increasingly sophisticated threats alone.

Kara Sprague, HackerOne

Beyond immediate patching, the industry needs greater resources for open-source software maintenance and security overall. Kara Sprague, CEO of HackerOne, stated: "The PHP discoveries are also a reminder that open-source security is everyone's responsibility. Software that supports millions of websites cannot depend on a handful of maintainers to manage increasingly sophisticated threats alone."

For organizations operating affected PHP systems, the urgent task remains: deploy a fixed build and examine systems for signs of attempted exploitation, including activity dating back to October 17.

This is where the competing assessments converge. Better-resourced maintainers, more resilient disclosure procedures, and broader access to defensive tools could address the longer-term challenge. That structural problem—not the immediate patch—represents the real issue facing the industry.