CVE-2026-109618 and CVE-2026-109619: PHP2Shell RCE Exposure

CVE-2026-109618 and CVE-2026-109619: PHP2Shell RCE Exposure | 2026

Executive Summary

CVE-2026-109618 and CVE-2026-109619 affect PHP runtimes and are collectively discussed as PHP2Shell. PHP classifies both issues as critical. Practical risk is not determined by PHP version alone: the deployed SAPI, web-server integration, application behavior, request lifecycle, and worker permissions influence whether a target is exploitable.

Horizon3.ai validated exploit feasibility under specific deployment conditions, while PHP's advisory identifies mod_php as the highest-risk configuration. PHP released fixed versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026. Organizations should inventory every PHP runtime, including versions bundled inside products and containers, then apply a trusted vendor update.

The Flaw: Two Critical PHP Runtime Vulnerabilities

CVE-2026-109618 is an out-of-memory corruption vulnerability, while CVE-2026-109619 involves stale global state that can persist across requests handled by the same worker. Together, these conditions may create a pre-authentication remote code execution path in susceptible deployments.

The affected runtime surface includes PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed integrations. Their exposure is not identical. PHP's official guidance places special emphasis on mod_php, while other SAPIs must be assessed against their own request and worker behavior.

How the Exploitability Chain Works

1. Runtime discovery: An attacker identifies an internet-facing application backed by a vulnerable PHP runtime.
2. Request processing: A crafted request reaches a vulnerable code path in the PHP runtime and its configured SAPI.
3. Memory/state interaction: The first request may create corruption or stale state that survives in a long-lived worker.
4. Follow-on request: A later request handled by the same worker can trigger the unsafe state under the right conditions.
5. Process impact: If worker permissions allow it, the result can extend beyond the web request into command execution or local resource access.

The exact chain depends on deployment details. A PHP version scan alone is not a complete exploitability assessment.

What Is the PHP2Shell Timeline?

Date	Event	Status
October 21, 2026	PHP publishes fixed releases and advisory details	✅ Patch available
October 22, 2026	Horizon3.ai publishes deployment-focused exploitability research	📢 Public disclosure
October 23, 2026	Organizations review runtime, SAPI, container, and worker exposure	🔍 Continuing assessment

Why This Matters: Version Inventory Is Not Enough

Key Challenges

1. Hidden runtimes: PHP may be bundled inside appliances, hosted applications, Docker images, or vendor products absent from the main inventory.
2. SAPI-dependent risk: mod_php, PHP-FPM, php-cgi, and other integrations do not expose the same request lifecycle or worker behavior.
3. Stateful workers: A stale-state condition may require multiple requests to reach the same long-lived worker.
4. Privilege amplification: Impact depends on the permissions of the PHP worker, container, and attached service accounts.

How to Protect Against PHP2Shell

🔴 Upgrade PHP and Vendor Images (Critical Priority)

• Upgrade supported PHP branches to 8.5.12, 8.4.27, 8.3.36, or 8.2.35.
• Refresh Docker and hardened images from a trusted vendor after fixed packages are available.
• Use a vendor backport when an operating-system distribution maintains an older PHP branch.
• Identify the runtime and SAPI used by a product before declaring it remediated.

👥 Reduce Worker Blast Radius

• Run PHP workers as a dedicated, least-privileged account.
• Restrict filesystem writes, shell access, credentials, metadata services, and outbound network access.
• Separate internet-facing PHP applications from administrative and backup networks.
• Treat patch management as a tracked control for bundled runtimes.

🔍 Detection and Response

Review web-server, PHP-FPM, process-creation, container, and egress logs around disclosure and suspicious request bursts. Look for unexpected child processes, shell interpreters, credential access, unusual outbound connections, and repeated requests reaching the same worker pool.

Example Splunk starting point:

index=web OR index=php OR index=process
| search process_name IN ("sh", "bash", "cmd", "powershell", "curl", "wget")
    OR parent_process IN ("php-fpm", "httpd", "apache2", "php-cgi")
| stats count values(command_line) values(src_ip) by host, parent_process, process_name
| sort -count

If suspicious activity is found, preserve logs and host evidence, isolate the service, rotate credentials reachable by the worker, and follow incident response procedures. Treat the event as a potential compromise until telemetry establishes otherwise.

🧱 Temporary Risk Reduction

PHP documents configuration-level mitigations such as reducing request and memory limits and disabling upload progress where appropriate. These may reduce exposure, but are not a replacement for the fixed runtime. Apply them only as short-term defense-in-depth while patching.

Bottom Line

PHP2Shell is a critical runtime issue whose real-world risk depends on how PHP is integrated and what the worker can reach.

Key Takeaways

✅ Patch first — move supported PHP runtimes to fixed releases or apply a trusted backport.

✅ Inventory beyond servers — inspect containers, appliances, hosted products, and vendor-managed applications.

✅ Prioritize mod_php and long-lived workers — integration and state behavior can materially change exploitability.

✅ Limit blast radius — least privilege and egress controls reduce impact.

For your clients and users: verify PHP runtime and SAPI exposure today, then document remediation for every bundled or containerized deployment.

References

1. PHP2Shell Exposure Depends on More Than Whether You Use PHP
2. PHP security releases for CVE-2026-109618 and CVE-2026-109619
3. Security update on PHP2Shell impact for Docker customers
4. Technical Advisory: PHP2Shell Pre-Auth RCE