How AI-assisted research uncovered two critical vulnerabilities in PHP—and why the response has become a defining test for modern cybersecurity.
October 22, 2026 | Cybersecurity & Artificial Intelligence
On October 21, 2026, an emergency security release for PHP triggered a response rarely seen in the history of web infrastructure.
Government services went offline. Hospitals and public institutions temporarily disconnected websites. Security teams raced to identify vulnerable systems, while cloud providers deployed emergency protections across their networks.
In the United Kingdom, 32 government services became unavailable, with another four experiencing partial disruption. The Netherlands and Finland also took precautionary measures affecting public-facing services.
At the center of the disruption were two vulnerabilities in PHP, one of the programming languages most widely used to build and operate websites.
Known collectively as PHP2Shell, the flaws had remained in the underlying software for approximately 14 years.
Their discovery tells two stories. The first concerns a serious failure in how a trusted programming language manages memory. The second concerns a profound shift in cybersecurity: artificial intelligence is beginning to change how quickly complex vulnerabilities can be found, understood, and potentially exploited.
The Vulnerabilities: What Actually Went Wrong?
The two flaws, identified as CVE-2026-109618 and CVE-2026-109619, were assigned critical severity ratings of 9.2 out of 10.
Both affect PHP's handling of internal memory and error conditions. Under particular circumstances, an attacker can exploit these weaknesses to execute unauthorized code on a vulnerable server without authenticating.
The first vulnerability, CVE-2026-109618, arises when PHP runs out of memory while processing partially initialized request data. During cleanup, the runtime can mistakenly treat invalid memory as legitimate information.
The second, CVE-2026-109619, involves stale internal state. A previous request can leave references to memory that has already been released, potentially allowing a subsequent request to manipulate that memory.
These are not ordinary application-level bugs.
A website can have carefully reviewed code, updated plugins, and properly configured authentication while still depending on an affected PHP runtime.
Researchers demonstrated that even simple PHP applications could be exposed under vulnerable configurations.
Successful exploitation could allow attackers to compromise servers, access sensitive information, interfere with hosted applications, or extract secrets stored in process memory.
Who Discovered PHP2Shell?
The discovery was not the work of one individual.
Ryan Austin, a researcher at cybersecurity company Calif, reported an early finding to PHP maintainers in August 2026 while working under OpenAI's Patch the Planet initiative.
Separately, researchers at Wiz—including Sagi Tzadik, Shir Tamari, Nir Ohfeld, and Tomer Schwartz—investigated related vulnerabilities and submitted their findings later that month.
OpenAI's internal research team subsequently identified an additional version of the problem.
The sequence matters because it illustrates how vulnerability discovery is changing. Multiple groups, equipped with increasingly capable AI systems, were able to investigate obscure weaknesses in software that had already undergone years of conventional security review.
The research also revisited concerns that PHP developers had encountered previously, but which had not been understood as presenting the same level of practical exploitation risk.
AI's Role: A New Frontier in Vulnerability Research
Finding suspicious code is only part of the work involved in discovering a serious security vulnerability.
Researchers must establish whether the behavior can be triggered, whether it creates meaningful security consequences, and whether those consequences remain possible under real deployment conditions.
Memory-corruption vulnerabilities are especially difficult because exploitation depends on intricate details of program execution and memory allocation.
According to the research accounts discussed in this briefing, advanced AI systems helped investigators analyze vulnerable code paths, investigate exploitability, and validate proposed fixes.
Wiz reported using its Atlas research technology alongside advanced models from Google and OpenAI.
The significance is not simply that AI found a bug.
It is that AI-assisted research helped specialists investigate sophisticated vulnerabilities at a speed that would previously have required considerably more human effort.
That advantage is available to defenders, but the underlying capabilities are not inherently defensive.
As AI systems become more effective at software analysis, attackers may also gain the ability to investigate newly disclosed vulnerabilities and adapt exploitation techniques more quickly.
The result is a narrowing security response window.
The Global Response: Why Websites Went Offline
The public disclosure on October 21 prompted immediate action across governments and commercial infrastructure.
In the United Kingdom, officials confirmed the temporary unavailability of 32 government services and partial disruption to four others.
Authorities in the Netherlands and Finland also took public-facing systems offline as a precaution.
Other European governments and cybersecurity agencies issued urgent warnings, directing organizations to update vulnerable PHP environments or isolate systems that could not be secured immediately.
These shutdowns should not be confused with confirmed successful cyberattacks.
In many cases, organizations deliberately suspended access to reduce exposure while administrators installed updates or verified their environments.
The distinction is important.
A vulnerable website is not necessarily a compromised website, and a precautionary shutdown is not evidence that attackers successfully breached the service.
Nevertheless, security monitoring organizations reported substantial exploitation activity around the disclosure period.
Amazon observed an apparent exploitation attempt on October 17, before the public release. Subsequent monitoring documented rapidly increasing attack attempts as knowledge of the flaws spread.
This reinforced the urgency of the response.
Which Industries Were Exposed?
PHP underpins websites, applications, publishing platforms, administrative interfaces, and numerous enterprise systems.
The potential exposure therefore extended well beyond technology companies.
Government and public administration: Public portals, government websites, and local authority services required urgent assessment and, in some cases, temporary suspension.
Healthcare: Hospital websites and other healthcare applications faced potential operational disruption, particularly where older web infrastructure remained in use.
Financial services: Financial institutions and fintech providers needed to assess internet-facing PHP applications that could handle sensitive information or connect to internal services.
E-commerce and digital businesses: Retail platforms, customer portals, and payment-adjacent applications were potentially exposed wherever vulnerable PHP runtimes were deployed.
Hosting and cloud infrastructure: Providers had to review managed environments, update runtime images, and coordinate deployments across potentially large customer populations.
Open-source ecosystems: Applications built with WordPress, Drupal, Joomla, and similar technologies required attention to the underlying PHP environment, regardless of whether their application code contained the vulnerability.
The wider risk is not determined solely by the number of websites using PHP.
It depends on which versions are running, how those systems are configured, whether they are exposed to untrusted traffic, and whether effective updates have been installed.
How the Industry Responded
The emergency demonstrated how much the internet now depends on coordinated action between software maintainers, cloud providers, hosting companies, and security vendors.
PHP maintainers released fixed versions for supported branches on October 21:PHP branchFixed versionPHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35
Cloud infrastructure companies and security providers deployed additional defensive measures.
Web application firewalls were updated to detect and block known malicious traffic patterns. Managed hosting and cloud environments received security updates, while administrators of self-managed servers were responsible for upgrading their own installations.
Importantly, these actions were not equivalent.
Firewall rules can reduce exposure to known attacks, but cannot guarantee protection against every exploitation technique.
The PHP project has explicitly stated that upgrading to a fixed version is the only complete remedy.
Organizations running unsupported versions face additional complexity. PHP 8.1 and earlier no longer receive official upstream security updates, although some Linux distributors and long-term support vendors may provide backported fixes.
What Website Owners Should Do Now
For organizations operating PHP-based systems, the priority is to establish which runtimes are exposed and whether effective patches have actually reached production.
1. Identify affected installations. Review web servers, managed hosting accounts, container images, legacy applications, and administrative interfaces.
2. Apply supported security updates. Upgrade to an appropriate fixed PHP release or a vendor-confirmed backported package.
3. Restart affected services. Verify that PHP-FPM, Apache, container instances, or other runtime services are actually using the updated binaries.
4. Isolate systems that cannot be secured. Restrict public access where immediate remediation is unavailable. Treat firewall rules as temporary protection rather than a permanent fix.
5. Investigate suspicious activity. Review relevant logs and monitoring data, including activity before public disclosure. Security researchers have recommended examining activity dating back to at least October 17.
6. Protect sensitive credentials. If compromise or memory exposure is suspected, investigate affected systems and rotate potentially exposed passwords, tokens, and API keys.
7. Verify dependencies and hosting providers. A patched website application is insufficient if the underlying runtime remains vulnerable.
The operational lesson is straightforward: knowing the version of your application framework is not the same as knowing the security condition of the infrastructure beneath it.
How Vulnerable Is the Internet?
The most striking aspect of PHP2Shell is not simply its technical severity.
It is how much critical infrastructure can depend on a relatively small number of widely used software components.
PHP has remained a foundational part of web development for decades, supporting everything from personal websites to large business applications.
That reach creates efficiency and interoperability. It also means that a serious defect in the shared runtime can affect organizations with very different levels of security maturity.
The widely cited figure that PHP supports roughly 70% of websites should not be interpreted as meaning that 70% of the internet was successfully attacked—or even that every such website was exploitable under identical conditions.
Actual risk varies considerably according to software versions, deployment configurations, network exposure, and patch status.
The larger concern is the long tail of outdated systems.
An actively maintained cloud application may receive a security update rapidly. A legacy business platform, embedded management interface, or abandoned internal application may remain vulnerable far longer.
That imbalance is one of the internet's most persistent security problems.
Could This Happen Again?
Almost certainly.
The underlying conditions that made PHP2Shell significant are not unique to PHP.
Modern infrastructure relies on large software ecosystems, complex dependencies, long-lived codebases, and maintainers who must balance security work against ongoing development.
Meanwhile, the capabilities available to vulnerability researchers are improving rapidly.
Advanced AI may help defenders identify previously overlooked weaknesses before attackers exploit them. But it also increases pressure on maintainers to validate findings, prepare fixes, coordinate disclosure, and help organizations deploy updates quickly.
The future security challenge will not be limited to finding vulnerabilities.
It will be managing the growing difference between how quickly flaws can be discovered and how quickly real-world systems can be secured.
The Bigger Lesson
PHP2Shell should be understood as a warning about the security of shared digital infrastructure.
The incident exposed weaknesses not only in software memory management, but also in disclosure coordination, legacy-system maintenance, and emergency response readiness.
It demonstrated the increasingly important role of AI in sophisticated security research.
It also offered a reminder that software security remains a human responsibility.
AI can help find vulnerabilities. Security teams must still validate the evidence, coordinate responsible disclosure, develop reliable patches, and ensure those patches reach the systems that need them.
For organizations, the most important question is not whether another severe vulnerability will emerge.
It is whether they will be ready when it does.
References and Further Reading
Wiz Research — PHP2Shell: Critical PHP Remote Code Execution Vulnerabilities
Google Cloud — Responding to Core PHP Vulnerabilities
PHP Project — Official Security Releases
The Register — PHP2Shell and UK Government Service Disruption
SecurityWeek — Emergency PHP2Shell Patches
The New Stack — PHP's Security Scramble and AI-Assisted Vulnerability Discovery
PHP Project — Supported Versions
Editorial note: This article reflects information available through October 22, 2026. The incident remains under investigation, and reported exploitation activity and service disruptions may change as further evidence emerges.
