PHP2Shell Confirmed RCE Report: Urgently Patch PHP 8.2–8.5 Servers

The two flaws are CVE-2026-109618 and CVE-2026-109619. Patching is the only complete fix.

What was reportedly observed​

Karimi described the capture as confirmed RCE with usable memory disclosure, not just a crash followed by a suspicious process. His account has three parts:

• The server's response delivered an 800 KiB decoded cookie dump.
• A function address derived from that dump, using offsets from the public exploit, appeared in the later execution payload.
• The shell command ran about 1.6 milliseconds after the final captured byte of the execution request.

Expel threat researcher Marcus Hutchins, who has been tracking a stream of alleged successful PHP2Shell reports, called it the highest-quality confirmation of in-the-wild exploitation he had seen so far.

These details come from Karimi and the BleepingComputer report. I found no independent copy of the honeypot telemetry, so treat the exact figures as his claims. The pattern is internally coherent, though. A memory leak feeds a calculated address, and that address shows up in the payload that follows.

Why "attempts" and "success" are different things​

Reports of exploitation have piled up since before the patches shipped, and they mean different things.

• Before disclosure: Sophos's advisory notes that Amazon Threat Intelligence reported an exploitation attempt on October 17, 2026, before public disclosure. Cloudflare, Hadrian, watchTowr, Previdian and Patchstack also saw attempts. BleepingComputer says all of those were flagged as unsuccessful.
• After disclosure: watchTowr says its Attacker Eye honeypot network observed exploitation of CVE-2026-109618 and CVE-2026-109619 in the wild on October 21, 2026. Tenable's FAQ adds that Amazon says it is unclear whether any of the October 21 attempts would have succeeded against real-world systems.
• Dataminr's view: According to BleepingComputer, Dataminr's TRACE team said that until Karimi's findings, activity was limited to scanning, fingerprinting and non-working exploits, with no known compromises.
• Public PoCs: The PHP security team said the proof-of-concept exploits published before the patches were not functional.

The new report matters because it is the first one described as a completed, verified chain. Some vendors already use "exploited in the wild" for what is probably noisy probing, so read that phrase carefully in vendor advisories.

Who is affected​

PHP's fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Amazon's security bulletin lists these affected upstream ranges:

Older branches are a muddier story. Amazon's bulletin says PHP 5.4 through 8.1 are end-of-life with no planned upstream fix, and that migration to a supported branch is required. SOCRadar, however, lists source backports for 8.1, 8.0 and 7.4. I can't reconcile the two from the evidence I have. If you run an old branch, check your distribution or vendor for a backported package rather than assuming either way.

The deployment scope is broad. Tanium's summary says affected server setups include PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed, and PHP rates mod_php as the highest risk. That fits Karimi's catch, which was against mod_php.

Because the flaw is in PHP itself, Recorded Future notes that websites running vulnerable PHP versions may be exposed, including those built on WordPress, Drupal, and Joomla.

Why mod_php is the nasty case​

Sophos warns that in-process protections such as RASP or application-embedded WAF agents may not stop exploitation. On Apache mod_php, CVE-2026-109618 can be triggered by an unauthenticated request before any application code runs.

Datadog's independent reproduction points the same way. It triggered the out-of-memory corruption on PHP 8.5.11 with an unauthenticated HTTP POST, and the request never reaches the target application's code. In practice, your login page, your framework's middleware and your application firewall plugin may all be bypassed. Network-edge controls and the PHP version itself are what matter.

The separate unpatched issue: CVE-2026-115560​

A third flaw is easy to confuse with the first two. On October 23, PHP published an informational advisory on session upload progress.

• The advice: Set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect against an unlikely RCE vector.
• The conditions: An application must set session.serialize_handler to php_binary or php_serialize, then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled.
• Who can relax: Applications that never change the serialize handler at runtime can keep the feature enabled.
• The paperwork: PHP says a full advisory for CVE-2026-115560 will come with the next release. That means there is no patch yet.

The same setting was already listed as a mitigation in the October 21 advisory for CVE-2026-109619. If you applied it then, keep it in place.

Don't read that setting as a PHP2Shell fix. Datadog's key points say that only patching fixes these vulnerabilities, and community mitigations like disabling upload progress don't fully protect you. Amazon says the same: upgrading is the only complete fix, and configuration changes may reduce impact but none is a complete mitigation.

What to do now​

1. Inventory first. List every internet-facing PHP runtime and check the version that is actually deployed. Include hosting panels, appliances and containers, not just the application you built.
2. Upgrade to a fixed release. Use 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's confirmed security package. Restart PHP workers or Apache afterwards so the old code isn't still resident.
3. Check managed platforms. Amazon's bulletin shows how much this varies:
   • Elastic Beanstalk has updated platform versions.
   • Lambda has no managed PHP runtime, so custom runtimes and container images must be rebuilt and redeployed.
   • Lightsail instances can't be updated in place, so you create new instances from updated blueprints.
4. Add the interim setting where you can't patch yet. Use session.upload_progress.enabled=0, after confirming nothing depends on upload-progress tracking.
5. Layer a WAF, but don't rely on it. Amazon says its AWS WAF PHP managed rule group has been updated for both CVEs. Customers on a pinned version should move to the latest one. Amazon still calls patching the only complete fix.
6. Hunt for compromise. Sophos recommends reviewing activity on exposed systems from August 1, 2026 onward. The PHP project received the first reports on August 11, and exploitation attempts have been seen since at least October 17. Look for web server processes spawning shells, unexpected outbound connections, new webshells and strange crashes or restarts of PHP workers.

Scale, and a caveat on the numbers​

BleepingComputer cites VirusTotal estimates that PHP runs roughly 70% of websites, with more than 5.1 million PHP hosts exposed online and about 3.8 million with at least one open port. I couldn't independently check those figures. Even if they're off, the exposure is large.

Bitdefender's technical advisory offers a useful counterweight. It said it had seen no PHP2Shell exploitation in its own telemetry at publication, and added that this is not evidence the threat is overstated. Telemetry coverage varies, and one vendor's quiet network says little about another's honeypot.

Bottom line​

The reported honeypot capture suggests the working exploit chain is now real, and the public exploit's offsets are reportedly good enough to use. Defenders had a one-day head start after patches landed on October 21, and some had none, given the pre-disclosure leak. Patch first, hunt second, and treat the upload-progress setting as a stopgap for CVE-2026-115560, not a fix for PHP2Shell.