Two critical PHP vulnerabilities allow unauthenticated remote code execution. A disclosure embargo broke down, while security experts warn that AI is making complex exploits more practical.
Two critical vulnerabilities in the PHP programming language are drawing urgent attention from security teams after researchers demonstrated unauthenticated remote code execution and Amazon reported an exploitation attempt four days before public disclosure.
The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively called PHP2Shell, affect PHP’s core runtime. Successful exploitation could allow attackers to execute code on vulnerable web servers and access sensitive information held in process memory.
The PHP development team released security updates on October 21, a day earlier than originally planned, after vulnerability details and proof-of-concept material surfaced ahead of the coordinated disclosure. India’s Computer Emergency Response Team (CERT-In) and other cybersecurity agencies have urged organizations to apply the relevant fixes.
Amazon Threat Intelligence said it identified an attempted exploitation of PHP2Shell in its MadPot honeypot telemetry on October 17, four days before public disclosure. The activity originated from an IP address associated with a commercial anonymization network.
Amazon said the incident suggested a threat actor had obtained actionable information while the vulnerabilities remained under embargo, although it could not determine how that information was acquired. The company also identified additional exploit attempts around the time of the public release.
“The time from patch to working exploit is shrinking for structural reasons,” Amazon Threat Intelligence wrote in an October 21 security blog post, warning that AI-assisted analysis could make it cheaper to turn a patch or vulnerability advisory into a working exploit.
Disclosure breakdown raises concerns
The incident has also raised questions about coordinated vulnerability disclosure, a process designed to give software maintainers and defenders time to prepare fixes before attackers learn the technical details.
John Bruggeman, vCISO at CBTS, said the release was originally scheduled for October 22 at 14:00 UTC, with researchers, the PHP Foundation and other participants working under an embargo. The PHP Foundation moved the release forward after information about the vulnerabilities began circulating publicly.
Bruggeman said the embargo failed at multiple points, including the early circulation of CVE details and proof-of-concept material. He also cited the publication of fixed container images by Chainguard before the agreed release time.
The PHP2Shell disclosure timeline records that CVE identifiers began circulating on October 20, a proof-of-concept video was published accidentally, and Chainguard shipped fixed images more than six hours before the scheduled release. The PHP security team published the fixes on October 21 at 14:00 UTC rather than the originally planned October 22 release time.
Bruggeman said the early availability of patched images gave attackers an opportunity to study the fix while other organizations were still waiting for the coordinated release.
“An embargo isn’t a formality,” he said. “It’s the only mechanism the security community has for giving defenders a head start over attackers on something this widespread.”
Amazon’s findings illustrate the limits of that protection. The company said it observed exploitation attempts before the planned disclosure date, while additional proof-of-concept exploits appeared within hours of the public release.
The incidents do not establish that every early attempt succeeded, or that all the activity resulted from the embargo breach. Amazon said technical analysis was continuing and that it remained unclear whether the observed attempts would have succeeded against real-world systems. It nevertheless warned organizations not to assume the public disclosure date marked the beginning of exploitation.
Core PHP flaws affect multiple applications
The vulnerabilities arise from memory-safety problems in PHP’s handling of errors and internal request data.
CVE-2026-109618 involves out-of-memory handling. When PHP encounters a memory-limit failure during request processing, execution can be interrupted while internal request data is only partially initialized. Subsequent cleanup may treat invalid data as valid, creating a route to memory corruption and potentially remote code execution.
CVE-2026-109619 involves stale internal state. Data associated with a request can persist after the memory backing it has been freed. A later request handled by the same worker may use that stale state before PHP resets it, creating another potential path to code execution.
Both vulnerabilities have a CVSS 4.0 score of 9.2 out of 10. Researchers at Wiz demonstrated unauthenticated remote code execution against WordPress, Drupal and Joomla deployments, showing that the risk is not limited to a flaw in any one of those applications.
The PHP project released fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Organizations running older, unsupported branches should check with their operating-system distribution or hosting provider for applicable patches and support options. The PHP project has also published source backports for selected older branches.
AI makes complex exploits practical
The research behind PHP2Shell also highlights how AI can help security researchers work through technically demanding exploit development.
Joseph Perry, cybersecurity researcher and advanced services lead at Arcova, said the significance of AI in this case was less about inventing an entirely new attack technique than making a difficult process practical.
“The thing in the way of developing an exploit like this is the need for constant, exhaustive debugging from platform to platform, version to version,” Perry said.
He said memory-corruption exploits can require extensive testing and repeated adjustments across software versions and deployment environments. AI systems can help automate repetitive testing and record results, reducing the time and effort required to make an exploit work reliably.
“The security researchers who developed this exploit were more than clever enough to do so by themselves,” Perry said, adding that they, like other human researchers, faced limits imposed by time and opportunity cost.
“Protecting against AI isn’t about protecting against futuristic exploits no human could possibly imagine,” he said. “It’s about protecting against the kind of exploits no human would bother to use.”
Wiz’s research also described AI models as part of the vulnerability investigation and exploit-development process. The episode reinforces concerns that the same automation used to discover and validate vulnerabilities can help attackers adapt public technical information into working exploits.
Patching must be accompanied by investigation
Security experts say organizations should not treat installation of the fixes as the end of the response.
Hitesh Sheth, CEO of Vectra AI, said patching addresses a known vulnerability but cannot establish whether an attacker has already exploited it or moved elsewhere in the environment.
“A patch can close a known weakness; it cannot tell you whether an attacker has already exploited it, where they’ve moved, or what they’re doing inside your environment,” Sheth said.
He recommended that defenders look for suspicious behavior across network and identity activity rather than relying exclusively on signatures for a particular vulnerability. Such activity could include unexpected processes, unusual access patterns or attempts to move between systems after an initial compromise.
Michael Centrella, head of public policy at SecurityScorecard, said organizations responsible for public services should also prioritize remediation according to the consequences of compromise or an outage.
“This is more than a vulnerability or patching issue,” Centrella said. “It is potentially a public-service continuity and concentration-risk issue.”
He urged government agencies to identify which essential services depend on vulnerable systems, including emergency services, health, transportation, benefits and payments. Shared hosting providers and managed service providers could also create common points of failure across multiple organizations.
The immediate priority remains upgrading vulnerable PHP installations to fixed versions. Organizations unable to patch promptly should consider isolating exposed systems or applying temporary mitigations while preparing updates. Amazon recommends reviewing web server logs, looking for suspicious multipart POST requests and checking for unexpected process execution or file modifications.
