PHP, the scripting language that powers a huge share of the web, including WordPress, Laravel and countless other sites, rushed out emergency patches on October 21, 2026 for two critical security flaws that let an attacker take over a web server without needing a password or any user interaction. The pair of bugs has been nicknamed PHP2Shell, and both carry a CVSS v4.0 score of 9.2, close to the maximum severity rating.
The first flaw, tracked as CVE-2026-109618, is a memory-handling bug that lets an attacker read data straight out of a PHP worker’s memory before they have even managed to execute any code. The second, CVE-2026-109619, goes further and allows full remote code execution. It lives in how PHP tracks the progress of file uploads during a session, a process that kicks off before PHP has even finished setting up the incoming request. Because both issues sit inside the PHP engine itself rather than in any particular application, writing secure code in WordPress, Laravel or a custom app does nothing to protect against them. The underlying code has reportedly existed in PHP for more than a decade, meaning the flaws touch almost every version released since PHP 5.4.
Who found it, and how AI played a role
The flaws were identified and reported by security researchers at Wiz, a firm called Calif, and OpenAI’s Codex Security team, who then worked alongside PHP’s own security team and engineers from Google’s Gemini team to build and test the fix. One detail that stands out is that the researchers said AI models helped them turn the raw bugs into working exploit code, a sign of how automated tooling is changing vulnerability research on both the offensive and defensive sides.
There is also an uncomfortable backstory. According to the PHP Foundation, a core PHP developer had already spotted signs of the memory-handling bug during an external audit back in 2024. The fix, however, stalled for months because of internal disagreement and limited resources, a reminder that even widely used open source infrastructure can run on a shoestring of volunteer attention.
A messy, accelerated disclosure
The release timeline was anything but calm. On October 20, a public post claimed the vulnerabilities would be disclosed on October 22, which pushed the PHP team to move its patch release forward by a day. That same evening, around 20:00 UTC, the firm Calif accidentally published a video showing its working proof of concept exploit. Then, at 07:41 UTC on October 21, the container image maintainer Chainguard published updated images that already contained the fix, which gave anyone paying close attention a way to study the patch and work out the underlying bug before most administrators had even had a chance to update.
Are attackers already exploiting it?
Yes, at least in part. Cloudflare said it observed early exploitation attempts before PHP’s official patch was even released and had to keep adjusting its firewall rules as attackers changed their payloads to slip past them. The security firm watchTowr initially said it had seen no active exploitation, then reversed that assessment later on October 21, reporting “active exploitation attempts” against both CVEs. As of publication, no organization has confirmed an actual breach tied to the flaws, and the U.S. Cybersecurity and Infrastructure Security Agency had not added either CVE to its Known Exploited Vulnerabilities catalog. Even so, HR software provider BambooHR took its service offline as a precaution, and several Dutch government and education websites did the same, though neither reported that attackers had actually gotten in.
What is affected, and how to fix it
The bugs touch PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP and LiteSpeed. Sites running mod_php face the highest risk, since a single unauthenticated request can trigger the memory bug before any application code even runs. PHP-FPM setups are somewhat less exposed to that particular flaw, but the second, code-execution bug can still reach them depending on what the application is doing at the time.
PHP has shipped fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 8.1 and older no longer receive official support, though PHP did publish source-level backports for the 7.4, 8.0 and 8.1 branches. Some Linux distributions had already patched their own PHP packages before the public disclosure, so administrators should check package changelogs for the CVE numbers rather than relying on the version string alone.
Updating the PHP runtime is the only complete fix, and it is a separate step from updating a web application. Patching WordPress or Laravel does nothing if the PHP interpreter underneath them is still vulnerable. After updating, Apache, PHP-FPM and any long-running PHP worker processes need to be restarted for the fix to take effect.
For teams that cannot patch immediately, there are partial mitigations. For CVE-2026-109618, setting memory_limit to -1 so applications cannot override it, keeping post_max_size low, and enforcing request size limits at the web server or load balancer can reduce exposure, though administrators should avoid using RLIMIT_AS or RLIMIT_DATA, since those can trigger the same vulnerable code path. For CVE-2026-109619, disabling session.upload_progress and restarting all workers helps, and PHP 8.5 users should also turn off fatal_error_backtraces. None of these steps make a server fully safe, they only narrow the paths an attacker can use while a proper update is scheduled.
Organizations wanting to check whether they have already been targeted should look for unusual multipart form requests followed by memory-limit errors, repeated HTTP 500 responses, abnormally large PHPSESSID cookies, and PHP worker processes restarting without an obvious cause.
Cloudflare’s chief technology officer was blunt about the situation, describing the company’s firewall rules as a stopgap and urging administrators to patch their systems rather than relying on network-level filtering to hold attackers off indefinitely.
Source: The Hacker News, reporting by Swati Khandelwal, October 21, 2026.
