This is external threat intelligence from the ReliaQuest Threat Research team. The findings describe threats, vulnerabilities, and attacker activity affecting third parties and the broader threat landscape—not ReliaQuest's own environment. Nothing in this report should be interpreted as a vulnerability in ReliaQuest's systems or data.
Key Points
PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets unauthenticated attackers run code on PHP web servers. PHP released fixes on October 21, 2026.
Attack attempts began hours before the patch. Expect fast weaponization as attackers reverse-engineer the fixes.
Patch now, isolate end-of-life PHP, rotate secrets on exposed servers, and hunt for web-server processes spawning shells.
What Happened
On October 21, 2026, the PHP project released emergency security updates (PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35) fixing two critical vulnerabilities, collectively dubbed “PHP2Shell.” Both flaws are rated CVSS v4.0 9.2 and allow unauthenticated remote code execution (RCE) on servers running PHP, the server-side language behind WordPress, Drupal, Magento, Laravel, and a large share of the world's websites.
Details of the vulnerabilities leaked on October 20, ahead of a coordinated embargo, forcing the PHP security team to publish an advance notice and bring the release forward to 14:00 UTC on October 21. By the time patches landed, Cloudflare and hosting providers were reporting early attack attempts, screenshots of a private exploit tool had circulated online, and proof-of-concept research code had appeared on GitHub.
Researchers found the flaws and reported them to PHP in August. Researchers credit frontier AI models with reducing an exceptionally complex exploit chain to roughly one week of work.
What We Know
The Vulnerabilities
CVE-2026-109618 (RCE via out-of-memory corruption): When PHP runs out of memory while setting up a request, it can exit midway and leave internal request data partially initialized. Request cleanup then treats that invalid data as valid, which attackers can turn into code execution using crafted multipart form requests.
CVE-2026-109619 (RCE via stale global state): Persistent PHP workers can keep references to memory from a finished request. A later request handled by the same worker may use that stale state, creating a use-after-free condition. Session upload progress handling and, in PHP 8.5, fatal-error backtraces are known paths.
Because the flaws sit in PHP itself, not in any one application, they affect every PHP installation that serves web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP rates mod_php as the highest risk, as a demonstrated exploit fires before any application code runs. Researchers have shown unauthenticated RCE against default installations of WordPress, Drupal, Joomla, and Magento without any application-layer flaw. The bugs can also leak worker memory containing passwords, session tokens, and API keys.
PHP Branch | Vulnerable Versions | Fixed Version |
|---|---|---|
8.5 | Earlier than 8.5.12 | 8.5.12 |
8.4 | Earlier than 8.4.27 | 8.4.27 |
8.3 | Earlier than 8.3.36 | 8.3.36 |
8.2 | Earlier than 8.2.35 | 8.2.35 |
8.1 and earlier (end of life) | Reported affected back to PHP 5.4 | No fix planned |
Exploitation Status
Allegations of in-the-wild activity are early and inconsistent. Reports of attacks first appeared shortly after 07:30 UTC on October 21, while security researchers noted that honeypots have observed exploitation. Other researchers had not seen exploitation by midmorning US Eastern time, and still further telemetry showed probing rather than confirmed exploitation. At the time of writing, ReliaQuest has not observed successful exploitation in customer environments.
Recommendations
Patch and Inventory
Patch immediately: Inventory all PHP instances, including containers and bundled application stacks, and prioritize internet-facing and business-critical services. Validate backups and rollback procedures, then deploy the applicable security update. Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35.
Verify Remediation: Confirm that every PHP installation serving web requests—not only the command-line PHP installation—has been updated. This includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Restart affected PHP workers, web servers, and containers after patching. Upgrade unsupported PHP versions or apply a confirmed vendor backport.
Increase monitoring: Configure EDR, SIEM, and web-server logging to identify PHP or web-server processes spawning shells, discovery commands, interpreters, or download utilities. Investigate unexpected web-root changes, new PHP files, web-shell patterns, PHP worker crashes or restarts, suspicious requests to PHP endpoints and anomalous outbound connections. Continue reviewing activity from before the update was applied, even after patching is complete.
Hunt and Detect
Shells from web servers: Alert on PHP and web-server processes (php-fpm, php-cgi, httpd, apache2, nginx, w3wp.exe) spawning shells or interpreters such as bash, sh, cmd.exe, or PowerShell.
Follow-on activity: Watch for discovery commands (whoami, id, uname, ipconfig), download tools (curl, wget, certutil), and reverse-shell patterns such as /dev/tcp launched by web processes.
Web shells: Look for new or modified PHP files in web roots that may be web shells.
Web traffic: Review logs for multipart POST requests followed by memory-limit errors or bursts of HTTP 500 responses, oversized or malformed PHPSESSID cookies, and PHP_SESSION_UPLOAD_PROGRESS fields in request bodies.
Assume exposure: Rotate credentials, tokens, and API keys on or reachable from exposed PHP servers, and hunt retroactively rather than from the patch date.
ReliaQuest Assessment: What Comes Next
The Exploitation Window Will Be Short
Now that patches are public, attackers will compare them against earlier releases to reverse-engineer the flaws. This is standard after major disclosures, but AI-assisted analysis has compressed the process from weeks to hours. Combined with a leaked exploit tool and public research code, we assess that mass scanning and exploitation of unpatched PHP servers are highly likely to begin within days. Early attackers will likely be opportunistic: botnet operators, cryptominers, and initial access brokers planting web shells to sell footholds to ransomware groups. Internet-facing content management systems, shared hosting, and customer portals present the broadest target set.
Patching Won’t Undo a Compromise
Patching closes the door but does not remove anyone already inside. Attackers who gained access before an update can persist through web shells, scheduled tasks, or new accounts. Because the flaws can leak worker memory, credentials and API keys exposed before patching stay valid until they are rotated. That could let attackers pivot into databases, cloud consoles, and connected software-as-a-service (SaaS) applications long after the vulnerable server is fixed.
End-of-Life PHP Is the Long Tail
Many organizations still run PHP 7.x or 8.1 inside legacy applications and third-party products. With no fix coming, these systems need a full version upgrade, often involving vendors and application rework. We expect them to stay exploitable for months and become a fixture of opportunistic scanning.
Post-Exploitation Will Look Familiar
The initial exploit may be difficult to spot: PHP environments vary widely, and malicious requests may blend into routine scanning. The activity that follows should be more recognizable. After gaining code execution through PHP, threat actors will likely interact with the underlying operating system to expand their access—spawning shells, running discovery commands, downloading tools, establishing persistence and moving laterally. These familiar behaviors can lead to broader server compromise, data theft and operational disruption. Behavioral detections are designed to identify this activity, making post-exploitation monitoring and retrospective hunting a critical part of the response.
