PHP2Shell: What a Coordinated Security Response Looks Like
A coordinated response
This week, the PHP project released emergency security updates for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619, collectively known as “PHP2Shell”.
Because PHP powers nearly 70% of all websites globally and underpins platforms such as Drupal, WordPress, and Laravel, the critical PHP2Shell vulnerabilities created an urgent need for organisations to apply patches rapidly across supported branches (PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35).
An emergency update is never welcome, but the discovery of a vulnerability does not mean that an open-source project is unhealthy. Quite the opposite: transparent disclosure, coordinated fixes and rapid patching show that the security ecosystem is working as it should.
AI is changing vulnerability research
Software vulnerabilities are nothing new. What is changing is how quickly they can be found.
Researchers at Calif and Wiz discovered these flaws while using frontier AI models to audit open-source dependencies. Analysis that might have previously required months of focused human effort was completed in weeks with automated tooling.
That acceleration benefits defenders, but it also changes the threat landscape. The same techniques that help researchers find and fix vulnerabilities can make it easier for attackers to identify and exploit them. The time between disclosure and active exploitation is getting shorter, making preparation and rapid response more important than ever.
Open source responded quickly
The response to PHP2Shell demonstrated the strength of open-source collaboration.
A cross-industry group spent two months coordinating fixes, with Linux distributions and long-term support vendors receiving patches ahead of public disclosure. When technical details leaked earlier than planned, the PHP maintainers adapted and released the updates the following day. They also provided backports for the unsupported PHP 7.4, 8.0 and 8.1 branches.
Infrastructure providers added another layer of protection at the network edge. For example, Cloudflare published WAF rules across all its service tiers on the first day.
No security response is perfect, particularly when an embargo is disrupted. But this was a strong example of maintainers, researchers, vendors and infrastructure providers working together to protect a widely used technology.
How Zoocha responded
Zoocha’s DevOps and support engineers began preparing before the patches were published.
After receiving notice of the release window, we allocated engineering capacity, prepared our deployment pipelines and staged the necessary testing environments. That meant our engineers were ready to begin deployments as soon as the official updates became available.
Using our established Service Desk and vulnerability-management processes, we patched the majority of client production environments within 30 minutes of patch release, well within our contractual two-hour Priority 1 resolution SLA. Automated regression testing and post-deployment verification followed immediately.
In line with the wider PHP community, Drupal association guidance and wider threat intelligence, including AWS Threat Intelligence reports showing exploitation attempts predating public disclosure, we conducted thorough security checks across client environments. Specifically, we extended our investigation window back a full week to 17 October 2026, reviewing access logs, firewall telemetry, and system metrics for suspicious request patterns, worker crashes, or unauthorised file modifications, finding no indications of compromise. All managed applications and infrastructure remained fully secure.
Security advisories are a feature, not a failure
It can be tempting to see frequent security advisories as evidence that a piece of software is less secure. In reality, silence is not necessarily reassuring.
If the software you depend on rarely reports vulnerabilities, that doesn't mean it's free of flaws. It may simply mean they haven't been found yet, or haven't been disclosed. An undiscovered vulnerability is still an unpatched and potentially exploitable risk.
Healthy software projects make it possible for researchers to report problems responsibly. They coordinate fixes, publish clear guidance and give users a practical route to remediation. Just as importantly, organisations using that software need the processes and people required to respond without delay.
Maintaining a resilient web estate depends on disciplined patch management, tested deployment pipelines, continuous monitoring and a support team ready to act when it matters.