PHP2Shell: How the flaws work and which versions fix them

PHP2Shell is the name for two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. PHP published fixed releases on October 21, 2026. AWS reported attempts against its honeypot sensors, but its observations do not establish that an attempt succeeded on a real server.

For administrators, the key steps are to identify the PHP runtime actually serving requests and update it to a fixed release or a vendor package with a confirmed backport. A VPN or configuration change can reduce exposure or block specific paths, but PHP says updating is the complete remediation for these two flaws.

How the two PHP2Shell flaws work

The flaws affect PHP’s handling of request data and memory. CVE-2026-109618 involves out-of-memory handling: request data can remain only partly initialized and later be treated as valid during cleanup. CVE-2026-109619 involves stale state: a later request handled by the same worker can use request-owned data after the memory behind it has been freed. PHP classifies both as capable of remote code execution without authentication and rated each 9.2 under CVSS v4.0.

PHP says installations serving web requests may be at risk across PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Its highest demonstrated risk was for Apache mod_php. The practical first check is therefore not just which PHP version a website reports, but which runtime is serving each application, including runtimes inside containers and vendor images.

What AWS observed around disclosure

Amazon Threat Intelligence reported an attempted PHP2Shell exploit against its MadPot honeypot telemetry dated October 17, 2026. AWS identified the earliest proof-of-concept exploits in its telemetry at about 02:00 UTC on October 21, then observed additional attempts against MadPot between 02:00 and 08:00 UTC. The disclosure embargo ended at 14:00 UTC that day.

AWS said it could not determine whether the observed attempts would have succeeded against real-world systems. The October 17 observation is evidence of an attempt recorded by honeypot telemetry, not proof of a real-server compromise. AWS also cautioned that the IP addresses it listed included shared anonymization infrastructure, so they are not exclusive indicators of PHP2Shell activity.

LiveOverflow separately described a lab experiment using Codex and public clues to rediscover the vulnerability. The presenter reported reaching a use-after-free and code execution, but not obtaining an address leak or a fully generalized, reliable exploit. That account describes a bounded research experiment, not a universal exploit chain.

What Check Point’s impact estimate counts

In a report published October 22, 2026, Check Point said 10% of organizations worldwide had been “impacted” since disclosure. The company defines that measure as organizations facing exploitation attempts; it does not count confirmed successful compromises. Check Point reported 14% for Europe, 6% each for North America, Latin America and APAC, and 4% for Africa. Its North America figure is regional, not a US-specific rate.

Which PHP releases fix the flaws

PHP lists these upstream releases as fixes for CVE-2026-109618 and CVE-2026-109619:

The PHP security release says PHP 8.1 and older no longer receive upstream releases, although some distributions and long-term support vendors may backport fixes. If PHP comes from a vendor package, check that package’s version and confirm that the vendor has backported the relevant fix. For self-hosted systems, include containers and vendor images in the inventory, not just PHP installations on the main host.

Why a VPN or configuration change is not a complete fix

Restricting a service to a VPN can reduce who can reach it, but it does not repair a vulnerable PHP runtime. PHP says updating to a fixed release, or to a vendor package with a confirmed backport, is the complete remediation for the two PHP2Shell flaws.

PHP describes configuration measures such as request-size limits and changes to memory_limit as incomplete. Disabling session.upload_progress.enabled blocks confirmed session-related paths for CVE-2026-109619, but not every variant. Treat these settings as limited measures, not substitutes for updating.

The PHP archive also describes a separate, unlikely RCE vector, CVE-2026-115560. It requires session.serialize_handler to begin as php_binary or php_serialize, switch to php at runtime before session_start(), and leave session upload progress enabled. This is a distinct configuration-dependent issue, not one of the two PHP2Shell CVEs.

Updating also does not remove malicious code or damage that may already be present. Check Point recommends investigating unfamiliar PHP files, unusual requests, unexpected system-command execution and unknown outbound connections as part of a post-update review.