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.
Update: Lab Testing Reveals Exploitation Signals, Visibility Gaps and AI’s Role
October 22, 2026: Following publication, ReliaQuest researchers independently reproduced exploitation of CVE-2026-109618 in separate, controlled lab environments. This testing identified a specific sequence of artifacts across PHP error, Apache access, Apache error, and system logs that may help defenders detect exploitation. It also demonstrated how PID-level correlation can connect a failed request to the subsequent Apache worker crash and exposed visibility gaps caused by inconsistent collection of PHP and web-server logs.
Using public reporting and a commercially available AI model, the underlying memory-corruption behavior was reproduced and code execution was achieved in a lab configuration where the required exploit prerequisites were already present. This was not a universal, fully weaponized exploit chain capable of targeting deployments where those prerequisites are absent. Developing that broader chain—which requires overcoming additional technical barriers—is substantially more difficult.
These findings show that AI can help researchers and threat actors translate public technical reporting into functional exploit components. They do not indicate that reliable, widespread exploitation is simple or imminent. ReliaQuest has not observed successful exploitation in customer environments.
What Exploitation Looked Like
During lab testing, a malicious POST request (used to send data to a server) exhausted PHP’s available memory, triggering the vulnerable condition in CVE-2026-109618. The server returned an HTTP 500 error and could not complete the request. Seconds later, the Apache worker handling the request reported memory corruption and crashed.
The following sequence appeared in the logs:
|
The request path, process ID and other values will vary. Defenders should focus on the sequence: a POST request returns a 500 error, PHP reports memory exhaustion and heap corruption, and the Apache worker handling the request crashes. Each event may be benign on its own, but the full sequence occurring within seconds and involving the same process is a much stronger indication of exploitation.
ReliaQuest observed these events in PHP error, Apache access, Apache error and system logs. In the lab, those included:
/var/log/php/error.log/var/log/apache2/access.log/var/log/apache2/error.log/var/log/syslog
These paths are specific to the lab environment. Log destinations and formats will vary by Linux distribution, web server, PHP execution model, container platform, and application stack.
Two Promising Log-Based Detection Approaches
The testing identified two opportunities for defenders:
PHP memory errors containing in Unknown on line 0: Normal PHP memory errors identify the application file and line where the problem occurred. During exploitation, PHP instead reported in Unknown on line 0, suggesting the failure occurred inside PHP before an application file was identified. Organizations should determine whether the pattern occurs during normal activity and correlate it with other suspicious events. Searches should not depend on the size of the failed memory request because the final allocation observed in the lab was small.
Connecting a failed request to a worker crash: Defenders can connect a POST request returning a 500 error to the subsequent crash of the Apache worker that handled it. This requires the process ID, or PID (the number identifying that process), to appear in both the access and error logs. Organizations should collect both sources and configure Apache access logs to include the PID.
Why Visibility May Be Limited
These server-side approaches depend on organizations collecting the relevant PHP and web-server logs. Connecting a failed request to a worker crash also requires access logs to record the worker PID. ReliaQuest found that these logs and fields were not consistently available, which may prevent organizations from seeing or reconstructing the initial exploit. The absence of matching events should not be treated as proof that exploitation did not occur.
Existing endpoint monitoring can still detect activity that follows exploitation. Organizations should watch for PHP or web-server processes launching shells, running discovery commands, downloading tools, making unexpected outbound connections or creating PHP files that may be web shells. These behaviors can reveal an attack even when the initial request is not visible.
AI Reduces the Barrier to Weaponization
Public reporting does not need to include a complete, ready-to-run exploit to create risk. Using a commercially available AI model, ReliaQuest researchers translated public reporting into proof-of-concept code that reproduced the underlying memory-corruption behavior and achieved code execution under specific lab conditions.
That proof-of-concept relied on exploit prerequisites already being present in the targeted application. It did not reproduce the complete PHP2Shell chain needed to achieve code execution against deployments where those prerequisites are absent. Building such a broadly applicable exploit requires additional techniques and considerably more exploit-development work.
The distinction is important: AI can reduce the effort needed to understand public research, generate code, and reproduce individual exploit components, but it does not necessarily make a complex, universal exploit chain easy to build. ReliaQuest’s testing demonstrates acceleration—not automatic or effortless weaponization.
Taken together, the findings reinforce the need to act quickly while avoiding assumptions that widespread exploitation is inevitable. ReliaQuest has used the lab results to strengthen existing hunting and detection coverage, including updated detections for suspicious shell and reconnaissance activity launched by PHP and web-server processes where supported.
Updated Hunt and Detection Guidance
Based on the lab findings, organizations should:
Collect and correlate server logs: Centrally collect PHP error, Apache access, Apache error and operating-system logs. Export and retain logs generated inside containers and configure Apache access logs to include the worker PID.
Hunt for the exploit sequence: Look for POST requests to PHP resources that return HTTP 500 responses, followed by memory errors ending with in Unknown on line 0, zend_mm_heap corrupted, or AH00052: child pid … exit signal Abort (6). Where possible, confirm that the request and crash involve the same PID. Do not limit searches to large memory allocations.
Monitor endpoint activity: Alert when PHP or web-server processes launch shells, run discovery commands, start download tools, make unexpected outbound connections or create or modify PHP files in web roots.
Hunt retrospectively: Review activity from before patching was completed. Patching closes these vulnerabilities but does not remove web shells, accounts or other persistence established during an earlier compromise. Applying available security updates and mitigations addresses known vulnerability conditions but does not remove web shells, accounts, or other persistence established during an earlier compromise.
These measures complement, but do not replace, patching. Full remediation guidance and temporary measures for organizations that cannot patch immediately are included in the Recommendations section below.
Published on October 21, 2026
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.
Apply temporary measures if patching is delayed: For PHP-FPM, the vulnerability researchers recommend disabling session upload progress with
session.upload_progress.enabled=0andsetting memory_limit=-1``<sup>1</sup>. For Apachemod_php, it’s recommended to setmemory_limit=-1. These are temporary, partial mitigations and do not replace patching. Removing PHP’s memory limit can allow applications to exhaust available system memory, so test and monitor the change carefully.
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.
