Vulnerability Overview

CVE-2026-109618 and CVE-2026-109619 are memory-corruption vulnerabilities affecting PHP's handling of HTTP requests. Both carry a CVSS v4.0 severity score of 9.2.

CVE-2026-109618 involves improper memory handling when an allocation fails during request parsing. PHP can leave internal structures in an incomplete state, potentially allowing subsequent cleanup operations to corrupt memory.

CVE-2026-109619 involves the reuse of stale pointers after a fatal error interrupts memory cleanup. Under exploitable conditions, an attacker may manipulate the resulting memory corruption to achieve arbitrary code execution.

Neither vulnerability requires authentication. Because the flaws reside in PHP itself rather than in a specific application or plugin, vulnerable installations may be exposed even when their application code contains no independently exploitable defect.

The PHP project released emergency security updates on October 21, addressing both vulnerabilities.

Exploitation Timeline: From Scanning to Working Shells

The exploitation picture has changed substantially since the vulnerabilities became public.

Amazon Threat Intelligence identified an exploitation attempt dating to October 17, four days before the emergency patches were released. Other security organizations subsequently documented widespread scanning, fingerprinting, and attempts to exploit the vulnerabilities.

Initially, however, researchers struggled to establish successful code execution. Many publicly circulated proof-of-concept exploits were unreliable, ineffective, or dependent on unusually favorable configurations.

On October 23, VulnCheck reported significant progress in exploit development. Its researchers demonstrated remote code execution against multiple PHP 8.4 and 8.5 releases on AMD64 and ARM64 systems, including default Apache mod_php configurations and certain WordPress Docker installations.

The exploit also bypassed Address Space Layout Randomization (ASLR), a memory protection that complicates reliable exploitation.

The most consequential development followed on October 24.

Karimi's honeypot infrastructure recorded 35 successful shell executions across three systems. Two attacker-source IP addresses were associated with the activity. The observed attack sequence involved memory exhaustion, disclosure of process memory, and subsequent execution of shell commands.

Packet-level evidence and process execution records supported the conclusion that the attacks achieved genuine remote code execution rather than merely crashing PHP workers.

The activity was consistent with exploitation of CVE-2026-109618. The available evidence does not independently establish successful exploitation of CVE-2026-109619.

Importantly, the honeypots used a single-worker Apache mod_php configuration favorable to exploitation. The findings should not be interpreted as proof that the same technique operates reliably across every PHP deployment.

No second-stage payload download was observed in the reported honeypot activity.

Exposure and Exploitability

PHP2Shell presents a broad potential attack surface because PHP remains extensively deployed across web applications, content management systems, and supporting infrastructure.

However, the likelihood of successful exploitation varies by configuration.

Apache mod_php deployments warrant particular attention. Researchers have demonstrated exploitation paths that can trigger vulnerable behavior before application-level code executes.

PHP-FPM configurations may present additional barriers. Red Hat notes that PHP-FPM workers commonly terminate during early initialization failures before vulnerable memory structures can be reused. Exploitation in these environments may require additional application behavior or less common execution paths.

These distinctions are operationally important.

A vulnerable PHP version does not establish that every installation is equally exploitable. Conversely, the absence of a publicly demonstrated exploit against a particular configuration should not be treated as proof of immunity.

Organizations should evaluate the installed PHP version, execution model, internet exposure, and application behavior when prioritizing remediation.

CISA Guidance and KEV Status

CISA issued an urgent advisory on October 21 calling for immediate remediation of both vulnerabilities.

The agency recommends identifying affected PHP installations, prioritizing internet-facing systems, applying available security updates, and monitoring for suspicious activity associated with PHP processes.

CISA subsequently expanded its detection guidance, including a Sigma rule intended to help identify potentially malicious activity.

As of the morning of October 26, neither CVE-2026-109618 nor CVE-2026-109619 appeared in the KEV catalog.

That distinction matters. Confirmed command execution against internet-facing honeypots provides strong evidence of successful exploitation under observed conditions, but it does not automatically establish that CISA has completed its assessment for KEV inclusion.

Organizations should not interpret the absence of a KEV listing as a reason to postpone remediation.

No KEV-specific federal remediation deadline has been established for these vulnerabilities as of this report.

Recommended Defensive Actions

Organizations operating PHP-based infrastructure should prioritize the following measures:

1. Inventory affected installations. Identify PHP runtimes across web servers, applications, containers, and third-party products. Include embedded or less visible PHP dependencies.

2. Apply security updates immediately. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, as appropriate. Where vendors provide backported fixes, verify their applicability rather than relying solely on upstream version numbers.

3. Prioritize internet-facing systems. Apache mod_php installations should receive particular attention because of demonstrated exploitation paths. Other PHP execution models remain within the affected population.

4. Investigate suspicious process activity. Review web-server, application, and endpoint telemetry for unexpected shell processes, unusual child processes launched by PHP workers, suspicious outbound connections, and evidence of memory-exhaustion activity.

5. Apply temporary exposure controls where necessary. Restrict access to vulnerable applications when immediate patching is impossible. Web application firewalls may provide partial mitigation but should not substitute for security updates.

6. Verify remediation. Confirm that updated PHP runtimes are actually active, restart affected services, and rebuild or replace vulnerable container images where necessary.

Unsupported PHP releases require particular attention. Organizations should migrate to supported versions or obtain verified security fixes from their distribution or extended-support provider.

Intelligence Assessment

Assessment: High confidence that attackers have successfully exploited PHP2Shell against deliberately vulnerable internet-facing honeypots.

The October 24 observations represent a meaningful progression from scanning and unsuccessful exploit attempts to verified operating-system command execution.

Separate research demonstrating ASLR bypasses and exploitation across multiple PHP versions further increases concern that practical attack techniques will continue to mature.

Nevertheless, the available evidence does not establish widespread compromise of ordinary production systems, nor does it demonstrate uniform exploit reliability across all affected PHP configurations.

Defenders should distinguish three separate findings:

• Exploitation attempts: Widespread and independently documented.
• Successful code execution: Confirmed against internet-facing honeypot systems.
• Verified compromise of ordinary production environments: Not established by the evidence reviewed for this report.

The most important development to monitor is whether subsequent incident investigations confirm successful compromises of production environments, particularly across PHP configurations beyond the Apache mod_php setups already demonstrated.

Bottom line: PHP2Shell has moved beyond a theoretical remote-code-execution risk. Successful exploitation has been observed, practical exploit techniques are advancing, and immediate patching is warranted. The evidence supports urgent defensive action without assuming that widespread production compromise has already occurred.

Sources and References

• CISA — Critical Vulnerabilities in PHP Require Immediate Patching
• Amazon Threat Intelligence — PHP2Shell Exploitation Prior to Public Disclosure
• VulnCheck — PHP2Shell Vulnerabilities and Exploit Research
• Red Hat — PHP2Shell Security Bulletin RHSB-2026-013
• SecurityWeek — PHP2Shell Exploitation Moves From Probes to Working Shells
• BleepingComputer — PHP2Shell Security Flaws Successfully Exploited in the Wild
• Canadian Centre for Cyber Security — PHP2Shell Advisory

Cyber Comply | Vulnerability Intelligence | October 26, 2026