READ. SCROLL. LISTEN.

Unbiased headlines. Facts, not spin.

Unbiased Headlines is an independently owned news organization. We bring you the facts, not opinions, written fresh from 110+ named sources. Sources linked so you can verify it yourself.

← Back to headlines

Amazon Says Attempt to Exploit PHP2Shell Hit Its Honeypot Four Days Before Patches Shipped

Amazon Says Attempt to Exploit PHP2Shell Hit Its Honeypot Four Days Before Patches Shipped
Amazon Threat Intelligence says a probe against its MadPot honeypot on Oct. 17 targeted the PHP2Shell flaws four days before the Oct. 21 patch release, and that the bugs are now broadly exploited. The PHP Foundation says it knows of no successful remote code execution. How the early attacker got exploit details is still unexplained.

Since the PHP Foundation pulled forward its patch release and shipped fixes on Wednesday, Oct. 21, for two critical flaws known as PHP2Shell, the question has shifted from whether attackers would move to how early they did. Amazon says the answer is at least four days early.

CJ Moses, chief information security officer of Amazon Integrated Security, said the company's MadPot honeypot recorded a PHP2Shell exploit attempt on Saturday, Oct. 17. It came from IP address 103.216.220.92, geolocated to Australia and tied to a commercial anonymization network.

"While the vulnerability was under embargo, the targeting of a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor," Moses wrote, "though it remains unclear how the actor acquired exploit information prior to disclosure."

An Amazon spokesperson told The Hacker News the activity was largely a one-off probe.

What the flaws are

The two bugs are CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on the CVSS scale. Both allow pre-authentication remote code execution.

The first involves out-of-memory handling that can interrupt PHP while request data is only partly initialized. The second lets request-owned state survive after its memory is freed, so a later request on the same worker can use it.

Researchers at Calif and Google-owned Wiz found them, with OpenAI's Patch the Planet project collaborating, according to Infosecurity Magazine. Wiz said frontier AI models lowered the barrier to turning a long-standing flaw into a working exploit.

PHP runs on roughly 69.7% of websites whose server-side language is known, according to W3Techs data. That includes WordPress, Drupal, Joomla and Magento sites. VirusTotal tracks more than 5.1 million exposed PHP hosts, about 3.8 million with at least one open port.

CrowdStrike said exploitation leaves almost nothing behind. Responses return HTTP 200, application logs show no anomalies, and the only trace is a single memory-limit fatal error in the web server log that is "routinely dismissed as noise."

A leak, then a scramble

The PHP Foundation says the fixes were stuck for years. It first theorized the bug in 2024, but every proposed fix risked compatibility breaks, new denial-of-service paths, or changes to third-party extensions that seemed "impossible to coordinate."

Then details got out. The CVE identifiers and a proof-of-concept leaked, and the PHP team said mitigation advice given to some critical infrastructure providers also surfaced online. Infosecurity Magazine reported that a pseudonymous user on the Hacker News forum posted some of the information on Oct. 20. The PHP security team said the early proofs of concept were not functional.

The foundation moved the release up. Patches landed Oct. 21 at 14:00 UTC (10 a.m. ET) in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The team also issued minimal source backports for 7.4, 8.0 and 8.1, which are no longer supported.

The French public administrations, the Dutch National Cyber Security Centre and the University of Vienna took sites offline before patching, Infosecurity Magazine reported. The UK's National Cyber Security Centre told organizations to update immediately or take unpatched PHP servers offline.

Disputed picture of exploitation

Amazon says it logged multiple proof-of-concept exploits on release day, the earliest around 02:00 UTC. It logged more attempts between 02:00 and 08:00 UTC from other anonymized infrastructure. Payloads varied, which Amazon says suggests multiple actors. After the patch dropped, it saw new exploits used against its sensors "almost immediately." Moses said PHP2Shell is "now being broadly exploited in the wild" and warned defenders "should not assume the public disclosure date is the earliest date of exploitation."

Amazon also said its analysis is ongoing and it is unclear whether any of the attempts would have worked against real systems.

The PHP Foundation reads it more cautiously. Executive director Elizabeth Barron said that "to our knowledge, there has been no successful attempt at remote code execution," while stressing that upgrading is "imperative." She told Wired the foundation was unaware of Amazon's research before it was published.

Other vendors saw less. Cloudflare, watchTowr, Previdian, Hadrian and Patchstack reported unsuccessful attempts before disclosure, according to Bleeping Computer. Cisco Talos reported no exploitation as of 14:00 UTC on Oct. 21, and Huntress saw none on partner systems at 20:30 UTC, according to Brandefense's timeline. As of Thursday morning, Oct. 22, neither CVE was on CISA's Known Exploited Vulnerabilities list.

Different sensors see different traffic. A honeypot is built to attract attacks. A partner network full of real customers is not.

The long tail

Security researcher Kevin Beaumont said the flaws will "lead to a mass of incidents" and called it one of the biggest vulnerabilities in years. Forensics expert Hal Pomeranz said there will be "a long tail," with embedded installations that never get patched and forgotten, unmaintained apps.

Some admins face a delay. The volunteer-run repository rpms.remirepo.net will not have updates available Thursday, and users were advised to move to distribution packages or build from source.

Misinformation is circulating too. Two near-identical posts around 13:47 and 13:50 UTC on Oct. 21 claimed PHP 8.2 got no fix. PHP.net lists 8.2.35 as fixed. Brandefense also counted about 380 new GitHub repositories mentioning php2shell in 36 hours. Some of them warn the code is AI-generated or untested, and running unvetted exploit code is its own risk.

The foundation says it is changing its process so serious vulnerabilities stuck on hard trade-offs reach its leadership sooner and get resolved on a timelier schedule.

Still unanswered: how a party using an anonymized address knew enough to target a honeypot on Oct. 17, days before any public leak. Amazon says its technical analysis continues and has not named an actor.

Sources used for this briefing

8 links from 8 independent newsrooms (syndicated copies of the same report count once)

These are the sources it draws on, linked so you can verify.

center
The Hacker NewsSomeone Tried to Exploit PHP2Shell 4 Days Before the Vulnerabilities Were Publicly Disclosed
center-left
WiredHackers Exploited the PHP Vulnerabilities Days Before They Were Patched
left
The VergeThe disastrous PHP vulnerabilities were exploited days before the patch
unknown
Help Net SecurityPHP2Shell: Critical PHP vulnerabilities patched, update now!
unknown
Bleeping ComputerAmazon says PHP2Shell exploitation began 4 days before patches
unknown
brandefense.ioPHP2Shell Timeline: First 36 Hours, With Data
unknown
aws.amazonAmazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot | Amazon Web Services
unknown
Infosecurity MagazinePHP2Shell Exploitation Attempt Detected Four Days Before Disclosure