AI-assisted research helped establish practical attacks against PHP’s memory-handling flaws. Website owners should patch promptly, while distinguishing attack attempts from confirmed breaches.
Two critical PHP vulnerabilities are highlighting how artificial intelligence can change the security assessment of longstanding software problems.
The flaws, collectively called PHP2Shell, can allow an unauthenticated attacker to execute code on a vulnerable server under specific conditions. PHP released fixes on October 21, 2026, in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
The story extends beyond another emergency update. Researchers revisited historical memory-handling issues and demonstrated consequences that earlier investigations had not established.
What are the PHP2Shell vulnerabilities?
The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619.
The first concerns memory corruption when PHP encounters an out-of-memory condition. The second involves internal state retaining references to memory from an earlier request. Both affect the PHP runtime—the software executing application code—rather than a particular website plugin.
The PHP Foundation reports that researchers demonstrated remote code execution through different paths involving Apache’s mod_php and PHP-FPM. Actual exposure depends on the deployment and reachable application behavior.
How AI helped researchers revisit older problems
Calif’s research traces a related out-of-memory issue through a 2020 bug report and a 2024 audit. Exploitability had not been proven during that earlier audit.
In August 2026, Calif identified paths to remote code execution and began coordinated reporting to PHP. Its account credits AI-assisted investigation alongside detailed knowledge of PHP’s vulnerability history.
Importantly, Calif says the initial discovery did not require access to models unavailable to the public. The researcher also emphasizes that models cannot simply uncover every vulnerability from a basic prompt: knowing where to investigate remained essential.
That makes the case more nuanced than a claim that AI independently discovered a hidden disaster. Human expertise helped frame the questions, interpret the results and establish a working attack.
Attack traffic does not prove successful compromise
Cloudflare reports observing attack traffic and attackers modifying payloads in attempts to bypass its protections. The company deployed web application firewall measures and says administrators should still patch PHP.
Rapid7’s assessment adds an important qualification. Its researchers found that public proof-of-concept exploits depended on particular combinations of operating system, PHP version and web server. Its own work had produced exploitation only under narrow laboratory conditions, and it reported no observed exploitation in the wild in the assessment reviewed for this article.
Rapid7 nevertheless recommends emergency updates because more portable techniques could emerge.
These observations describe different things. A suspicious request can demonstrate an attack attempt without proving that the server executed the attacker’s code. Equally, limited evidence of successful attacks does not make an unpatched system safe.
What website owners should do
The immediate priority is confirming that the PHP installation serving the website has received both fixes.
| Website setup | Recommended action |
|---|---|
| Managed hosting | Ask the provider to confirm that the website’s active PHP runtime is patched. |
| Self-managed server | Install the appropriate fixed PHP or vendor package and follow its deployment instructions. |
| Older PHP branch | Obtain a supported vendor fix or plan an upgrade to a supported branch. |
| Multiple websites or PHP pools | Check each active runtime rather than assuming one update covers everything. |
| Web application firewall enabled | Keep protection active while completing the PHP update. |
Rapid7 notes that distribution vendors can backport fixes without adopting the upstream version number. Administrators should therefore check their package vendor’s security status rather than relying on a version string alone. PHP 8.1 and older no longer receive routine upstream updates.
For WordPress operators, the runtime distinction matters: updating WordPress core, themes or plugins does not establish that the hosting environment’s PHP package has been fixed.
Avoid applying unfamiliar configuration changes from social posts without reviewing official guidance. Temporary workarounds can address only particular paths and may introduce operational trade-offs.
The broader lesson: exploitability needs reassessment
TechLayers analysis: PHP2Shell shows why an earlier conclusion that exploitation has not been demonstrated should remain open to review.
Improved tools, fresh expertise and a different application context can change what researchers can prove. AI may accelerate that process, but this incident alone cannot establish that every old defect will become an easily exploitable vulnerability.
For organizations, the useful response is practical: maintain an inventory of deployed runtimes, assign responsibility for security updates and verify that fixes reach the services actually handling requests.
The advantage comes from shortening the interval between a validated warning and a completed update.
