Amazon Found PHP2Shell Probes Four Days Before the Patch

Amazon’s MadPot honeypots recorded a PHP2Shell exploit attempt on October 17, four days before PHP shipped patches for two critical bugs. The traffic came from an address tied to a commercial anonymization network, while the flaws were still under embargo. PHP’s public release was set for 14:00 UTC on October 21.

CJ Moses, who leads security at AWS, wrote that it remains unclear how the actor got exploit details before disclosure. The PHP Foundation had described that same stretch as the period when coordinated disclosure was still holding.

Amazon’s Honeypot Logged a Shot on October 17

Amazon Threat Intelligence published the finding on October 21 after looking back through MadPot, a network of decoy servers built to watch how attackers behave. The first recorded PHP2Shell exploitation attempt dating to Oct. 17 is not a victim count. It is one hit on a lure, from one hidden address, against bugs that were not yet public.

Moses said targeting a honeypot from an anonymized address points to a threat actor. He also said technical analysis was still running, and that it was unclear whether the early tries would have worked on real systems. The embargo window was set to lift at 14:00 UTC on October 21.

On that same calendar day, Amazon found multiple proof-of-concept exploits, the earliest around 02:00 UTC, twelve hours before the release. From 02:00 UTC to 08:00 UTC, more attempts hit MadPot from other anonymized infrastructure. The payloads and the hiding methods varied, which Amazon reads as several actors, not one.

After the patches went out, more demonstration code appeared within hours and was thrown at Amazon’s sensors almost at once. Moses then described PHP2Shell as seeing broad exploitation attempts in the wild. Amazon listed six addresses and asked operators to hunt from October 17, not from patch day.

The October 17 address was 103.216.220.92. The October 21 set was 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, and 95.217.98.37. Amazon said some of those addresses sit on shared anonymization infrastructure, so a match is a lead for investigation, not an automatic block list.

Identifiers Leaked Two Days Before the Planned Release

The PHP Foundation’s own timeline starts later than Amazon’s log. It said coordinated disclosure worked well until two days ahead of the original target date. That original slot was 14:00 UTC on October 22. The public release moved forward one day after the identifiers got out.

THE WEEK THE EMBARGO BROKE

1. October 17, 2026: MadPot records the first PHP2Shell attempt from a commercial anonymization network.
2. October 20, about 15:00 UTC: CVE-2026-109618 and CVE-2026-109619 begin circulating with a wrong release time and a wrong score of 10.0. The PHP Group’s score is 9.2. No technical details leaked with the IDs.
3. October 20, 19:30 UTC: PHP publishes an advance notice and moves the release to 14:00 UTC on October 21, because distributors were still packaging the fix.
4. October 20, about 20:00 UTC: Calif, one of the firms that reported the bugs, mistakenly publishes a video of its proof of concept. Copies spread after the original comes down.
5. October 20, about 23:00 UTC: Mitigation advice sent to a few critical infrastructure providers may have leaked as well.
6. October 21, 02:00 to 08:00 UTC: Amazon sees more anonymized attempts, and public demonstration code is already in circulation.
7. October 21, 07:41 UTC: Chainguard publishes built images that contain the fix, more than six hours before the coordinated release.
8. October 21, 14:00 UTC: The embargo lifts and PHP ships the patched releases.

The Foundation said any attacker could then study the fix in binary form while every other PHP user was still waiting. It called Chainguard’s move a unilateral break of the embargo that disregarded weeks of work by many parties. PHP’s security team watched the demonstration code that followed the leak and said it did not identify functional exploits at the moment of public disclosure.

A clip of that Calif demonstration was already moving around public feeds on the evening of October 20, hours after the CVE identifiers leaked. By early October 21, people were trading the session-upload-progress off switch as a stopgap, while the coordinated packages were still hours away. The quiet period was quietest for the operators who were not in the disclosure circle.

What PHP2Shell Does to a Live Worker

PHP2Shell is the informal name for two bugs in PHP itself, not in WordPress, Drupal, or any one app. Both can allow unauthenticated remote code execution in PHP. They sit in memory handling and error handling, which almost every request touches. PHP says there is no complete workaround, and that updating is the only safe choice.

THE TWO PHP2SHELL FLAWS

PHP rates each bug 9.2 under CVSS v4.0, with high attack complexity, no privileges, and no user action. The GitHub advisory for CVE-2026-109618 says complete remote code execution was validated over HTTP against mod_php with default input and memory limits. PHP considers Apache with mod_php the highest risk. The Foundation says remote code execution was also confirmed on PHP-FPM through application-level code paths.

Who is at risk, in PHP’s words, is every install that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. A WordPress or plugin update does not close this. The runtime has to move. After a package lands, every PHP worker still has to be restarted, because old processes keep running the old code.

If an update cannot go out at once, PHP published partial brakes: lift memory_limit in a way apps cannot override, cap post size, and turn off session.upload_progress before request parsing. On PHP 8.5 it also said to turn off fatal error backtraces. Those steps cut some paths. They do not make a server safe.

Agencies Told Operators to Pull Sites Offline

Some governments and other groups took key websites down ahead of the release, so they would not sit exposed while they applied the fix. CISA’s alert told U.S. organizations that cannot update immediately, or that still run PHP 8.1 or earlier, to take PHP-based systems offline until they can patch or move. A web application firewall, it said, may help only until the runtime is updated.

That advice is the practical admission inside the scramble. The bugs live below the application, so a Friday-night plugin rollout does not touch them, and an old host image may not have a vendor package at all. Pulling a site is crude. For operators who could not name every PHP worker they ran, it was faster than hoping a patch would land in time.

Cloudflare chief executive Matthew Prince wrote that the company saw thousands of attempts across its network in the 10 hours before the public announcement. That jumped to tens of thousands in the 45 minutes after, hundreds of thousands within two hours, and millions by the next morning. Those figures count tries on a huge proxy network. They are not a count of broken servers.

The Fix Sat Idle After a 2024 Audit

The OOM problem did not appear in October. In 2024, PHP had its first external security audit in years, funded by Germany’s Sovereign Tech Agency, organized through OSTIF, and carried out by Quarkslab. While fixing one of those findings, a core developer contracted by the PHP Foundation saw the first signs of the out-of-memory bug that became CVE-2026-109618. A possible exploit was theorized that year. No concrete path was found, and other issues with clearer impact took the queue.

Fixes kept stalling because each approach broke compatibility, added a new denial-of-service risk, or demanded changes across third-party extensions. The security team worked by consensus and could not pick. The Foundation now describes that stall in plain terms.

We won’t pretend otherwise: the delay was a structural failure, caused by both the security team’s decision process and its lack of resources.

The PHP Foundation, October 21, 2026

That is the Foundation’s phrase for the delay was a structural failure, written in its October 21 post on how the release came together. Calif joined OpenAI’s Patch the Planet audit of PHP on July 30. On August 11, researcher Ryan A at Calif reported unconditional remote code execution with the same root cause. OpenAI reported that root cause on its own. Wiz followed on August 24, and OpenAI sent further attack paths on September 18. From August 11, the Foundation says, fixing it became the top job for everyone it had on security.

OpenAI president Greg Brockman wrote that the company had spent two months leading a coalition to mitigate php2shell as part of Patch the Planet, and called it one of the most severe bugs in open source software found in recent memory. AI tools also flooded the PHP security team with noise. The Foundation said the team had published 15 CVEs since July 1 and had worked through more than 100 reports that were invalid, duplicates, or not reproducible. A person still makes every call and every patch.

Millions of Tries Have Not Produced a Confirmed Break-In

Broad scanning and a confirmed takeover are different facts, and they diverged quickly. Amazon reported wide exploitation attempts after the patches landed, and said compromise may predate the advisory. Elizabeth Barron, executive director of the PHP Foundation, said the organization did not know about Amazon’s research before it was published, and that to its knowledge there has been no successful attempt at remote code execution.

CISA’s alert, last revised on October 23, has not observed successful exploitation of these vulnerabilities in the wild as of publication. CrowdStrike said it had reproduced remote-code-execution variants and then asked why widespread weaponization had not been confirmed. Public demonstration code still leans on lab setups, and address-layout protections make a reliable hit harder than a 9.2 score sounds. The official vector already rates attack complexity as high.

WHAT WE KNOW

• The first probe: Amazon recorded a PHP2Shell attempt against MadPot on October 17 from a commercial anonymization network.
• The public wave: Demonstration code and scanning surged before 14:00 UTC on October 21 and reached millions of attempts on Cloudflare’s network by the next morning.
• The patch set: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 close both bugs; PHP 8.1 and older get no updates from the PHP project.

WHAT IS UNCONFIRMED

• The October 17 source: Amazon still does not say how that actor obtained exploit details during the embargo.
• A live break-in: Neither CISA nor the PHP Foundation has confirmed a successful remote-code-execution attack on a production server.
• The Chainguard binary: The Foundation said attackers could study the early images; it has not shown that anyone did.

Moses drew two lessons that go past this pair of bugs. An embargo protects operators only until someone else finds the same flaw, so the public date is not the earliest date of exploitation. The time from a patch to a working exploit is also shrinking, he wrote, because AI-assisted analysis makes it cheaper to turn a patch diff or an advisory into working attack code, and more actors can move in hours or minutes once details are out.

PHP 7 Still Runs More Than a Quarter of PHP Sites

W3Techs, which tracks site technology, said on October 24 that PHP is used by 69.3% of websites whose server-side language is known. Among those PHP sites, version 8 accounts for 65.4%, version 7 for 26.8%, version 5 for 7.7%, and version 4 for 0.1%. Add the last three and 34.6% of detected PHP sites are still on 7 or older, which the PHP project does not patch except for minimal source backports on 7.4, 8.0, and 8.1.

PATCHED PHP RELEASES

• PHP 8.5: 8.5.12 is the security release for that branch.
• PHP 8.4: 8.4.27 carries the same two fixes.
• PHP 8.3: 8.3.36 is the patched build on the security-only line.
• PHP 8.2: 8.2.35 is the oldest branch that still received a full upstream package.
• Older lines: PHP 8.1 and below need a vendor backport, a local build from PHP’s minimal source patches, or a move to a supported branch.

Linux distributions and LTS vendors received the patches in advance, which was the point of the embargo. Operators still have to install the package and replace running workers. On October 23, PHP also published an informational note asking people to keep session.upload_progress turned off until the next regular bugfix, a leftover brake from CVE-2026-109619 that it now ties to a separate session bug.

Amazon wants log reviews and file-integrity checks back to October 17. CISA, as of October 23, still had not confirmed that anyone had landed the bug on a live box. The embargo’s quiet days are the ones those logs have to cover.