The Software Behind Millions of Websites Is Under Attack_

On October 17, Amazon's threat-intelligence systems recorded an attempt to exploit a vulnerability in PHP that had yet to be publicly disclosed. The attacker was four days ahead of the emergency patches that would address it.

On October 21, PHP released fixes for two critical vulnerabilities, CVE-2026–109618 and CVE-2026–109619, collectively known as PHP2Shell. Both carry a CVSS v4.0 severity score of 9.2, with successful exploitation potentially allowing unauthenticated attackers to execute arbitrary code on affected web servers.

The scale of potential exposure is considerable. According to W3Techs, PHP is used by approximately 70% of websites whose server-side programming language can be identified. It underpins platforms including WordPress, Drupal, Joomla, and MediaWiki.

Those figures describe PHP's prevalence, rather than the number of vulnerable installations. The affected PHP versions, server configurations, and available attack paths determine individual exposure.

The vulnerabilities themselves reside in PHP's core runtime. An otherwise secure WordPress installation could therefore remain exposed through the PHP engine running underneath it.

Memory Corruption Inside PHP_

Both vulnerabilities originate in PHP's handling of memory and internal state when a web request encounters a fatal error.

PHP allocates memory as requests are processed and releases it afterward. Under certain failure conditions, however, internal structures can remain partially initialized, or references to freed memory can survive beyond the request that created them.

CVE-2026–109618 involves out-of-memory corruption. If PHP exhausts its configured memory limit during a particular stage of request processing, execution can stop before internal data structures are fully initialized. Subsequent cleanup operations may then treat invalid data as legitimate, corrupting process memory.

CVE-2026–109619 involves stale global state. A fatal error can leave an internal reference pointing to memory freed after an earlier request. When another request reaches the same PHP worker, accessing that reference can cause a use-after-free vulnerability, potentially allowing an attacker to manipulate memory and execute code.

Researchers at Wiz demonstrated unauthenticated remote code execution against WordPress, Drupal, and Joomla. They also established an independent route to reading PHP process memory, which can contain passwords, authentication tokens, API keys, and other sensitive information.

The precise exploitation requirements vary across deployments. The PHP security advisory identifies Apache with mod_php as particularly exposed, since a demonstrated attack can execute before application code runs.

PHP-FPM and other configurations also have confirmed attack paths, although some depend on application behavior.

PHP Had Identified the Underlying Problem in 2024_

The first signs of the out-of-memory issue appeared during a 2024 security audit funded by Germany's Sovereign Tech Agency and organized through OSTIF.

While addressing a finding from security firm Quarkslab, a PHP core developer identified the underlying problem later associated with CVE-2026–109618. A possible exploit was considered, but no practical remote-code-execution path had been established.

The PHP security team developed several potential fixes. Some risked breaking backward compatibility, others introduced new denial-of-service concerns, and certain approaches required extensive changes to third-party PHP extensions.

Deciding among these alternatives proved difficult. PHP's consensus-based security process struggled to resolve the trade-offs, while the relatively small group of developers familiar with the engine's internals had other responsibilities.

The PHP Foundation acknowledged the delay as a structural failure involving both its decision-making procedures and limited engineering resources.

The investigation advanced considerably in August 2026.

On August 11, researcher Ryan A from Calif, participating in OpenAI's Patch the Planet initiative, reported an unconditional remote-code-execution vulnerability involving the same underlying problem. OpenAI independently reported the root cause that day.

Wiz discovered additional attack paths later in August and submitted its findings on August 24.

AI systems played a substantial role in the research. Wiz credited Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol with assisting vulnerability discovery, exploit development, testing, and patch validation.

Developing practical attacks required combining memory-corruption techniques and adjusting them to different PHP versions, configurations, and memory layouts. Wiz reported that the models considerably reduced the effort involved in adapting its exploits across applications.

With working remote-code-execution demonstrations now available, the PHP team prioritized a comprehensive fix. Developers worked with the researchers, software distributors, hosting providers, and security companies to prepare patched releases and temporary protections.

The Disclosure Timeline Fell Apart_

PHP originally scheduled the coordinated security release for October 22, allowing distributors time to prepare updated packages before technical details became public.

On October 20, the vulnerability identifiers began circulating online alongside an incorrect severity score and release time. The initial leak contained no technical exploit information, according to the PHP Foundation, but PHP moved the release forward to October 21.

Calif subsequently published an exploit demonstration video by mistake. Although removed, copies circulated online and exposed additional information.

On October 21, Chainguard published container images containing the fixes more than six hours before the coordinated release. Attackers could potentially compare those binaries against vulnerable versions to identify the changes while other administrators were still waiting for patches.

Meanwhile, Amazon Threat Intelligence had recorded an attempted attack on October 17 through its MadPot honeypot network.

The attempt originated from an IP address associated with a commercial anonymization service. Amazon could not establish how the actor obtained the vulnerability information or confirm that the attack would have succeeded against a production system.

Further attempts appeared during the early hours of October 21, using different infrastructure and payloads. Some preceded the scheduled 14:00 UTC disclosure, while additional proof-of-concept exploits circulated shortly afterward.

Amazon subsequently reported widespread exploitation activity against its sensors. The number of successful compromises involving real-world systems remains uncertain.

A Smaller Window for Defenders_

The PHP2Shell investigation illustrates how AI-assisted vulnerability research is altering the effort required to exploit complicated software defects.

Wiz's researchers had to account for memory allocation patterns, PHP configurations, and differences between applications. Their models helped automate parts of the analysis, testing, and iterative debugging that would otherwise require extensive specialist work.

The same capabilities helped defenders identify the vulnerabilities and test their fixes. However, identifying a flaw does not automatically produce a safe patch for software with decades of accumulated design decisions and compatibility requirements.

PHP's maintainers had already confronted those difficulties in 2024. Now, the volume of incoming security research is increasing as well.

According to the PHP Foundation, its security team had published 15 CVEs since July 1 and processed more than 100 additional reports that proved invalid, duplicated existing findings, or could not be reproduced. The team uses AI tools to help validate submissions and identify shared root causes, while human developers remain responsible for security decisions and patches.

Distributors face their own constraints. Patches must be packaged, tested, and deployed across hosting environments where application compatibility and service availability can complicate upgrades.

Amazon recommends measuring response times for critical vulnerabilities in internet-facing systems in hours rather than conventional seven- or thirty-day windows. It also advises investigating suspicious activity before the public disclosure date, using October 17 as the starting point for PHP2Shell.

The PHP project has published fixes in the following releases:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Linux distributions and long-term-support vendors may provide backported fixes. PHP 8.1 and older no longer receive upstream security updates, although some vendors continue maintaining their own packages.

Cloudflare and other security providers have deployed protections against known exploitation techniques. PHP's maintainers nevertheless state that updating the runtime is the only complete remedy.

The PHP Foundation has begun revising its security decision-making process and expanding the number of developers assigned to security work. Its October 21 statement also calls for more sustained funding from companies, hosting providers, and institutions whose services depend on PHP.

The 2024 discovery had already demonstrated the difficulty of fixing a deeply embedded memory-management problem without disrupting existing software. By August 2026, AI-assisted research had established practical exploitation paths, but the engineering work required to repair the underlying design still depended on a small group of specialists.

That shortage is now part of PHP's security response, alongside the vulnerabilities themselves.