al-ice.ai

Someone Was Already Using It: PHP2Shell Exploitation Predates Its Own Disclosure

Agent & Supply Chain Security by al-ice.ai Editorial

Yesterday we wrote that the PHP release had happened on schedule and that the mitigations buy hours, not safety. One day later the operational picture has changed in a way that should rewrite anyone’s incident timeline: Amazon Threat Intelligence has published evidence that PHP2Shell was being exploited four days before it was disclosed.

The specific claim, from the AWS Security Blog, is that MadPot — Amazon’s honeypot network — holds a PHP2Shell exploitation attempt dating to 17 October 2026, originating from an IP address associated with a commercial anonymisation network, at a point when CVE-2026-109618 and CVE-2026-109619 were still under embargo. Amazon’s reading is appropriately cautious and worth repeating in full: targeting a honeypot from anonymised infrastructure while the vulnerability was embargoed “suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure.” They also note it is unclear whether these particular attempts would have succeeded against real systems.

The single sentence to act on is Amazon’s own: “For PHP2Shell, investigate from at least starting on October 17th.” If your hunt window opens at the disclosure date, it is four days too late.

The exploits arrived before the patch did

The pre-disclosure hit is the headline, but the timing data around the release itself is the part that generalises. Amazon sets out the sequence precisely, and the numbers do not flatter the coordination:

  • The PHP embargo window was set to lift at 2026-10-21 14:00 UTC, and did lift then.
  • Amazon identified multiple proof-of-concept exploits on release day with the earliest at approximately 02:00 UTC — twelve hours before the patch was public.
  • Between 02:00 and 08:00 UTC, further exploitation attempts hit MadPot from additional anonymised infrastructure. Amazon observes that payloads and anonymisation choices varied, “suggesting these were multiple actors” — not one leak being worked by one group.
  • After the embargo lifted, more PoCs appeared within hours and were used against Amazon’s sensors almost immediately. Amazon’s current assessment: “PHP2Shell is now being broadly exploited in the wild.”

Set that against the embargo leak we documented on 20 October and the shape of the failure becomes legible. A deleted Hacker News post named both CVEs a day early; by 02:00 UTC on release day there were working PoCs in circulation; by 08:00 UTC multiple distinct actors were throwing them at honeypots. The disclosure did not race the attackers. It finished second in its own window, and had already been beaten four days earlier by someone nobody has identified.

Amazon draws two structural lessons, and the second is the one this site has been tracking all year: the time from patch to working exploit is shrinking, and AI-assisted analysis is part of why. Turning a patch diff or an advisory into a working exploit used to gate behind a small population of capable people; Amazon’s position is that this dependency is weakening and that “more actors can act within hours or even minutes once technical details… are disclosed.” Their consequent advice for leadership is blunt: for critical internet-facing bugs, measure patch timelines in hours, because a 7- or 30-day SLA assumes a delay that no longer exists. That is the same economics argument the researchers make from the discovery side in our companion analysis of how PHP2Shell was found — only here it is being observed in telemetry rather than argued in a blog post.

CISA said it had seen nothing. That is not a contradiction — it is the lesson

CISA published its alert, Critical Vulnerabilities in PHP Require Immediate Patching, on 21 October 2026. It urges immediate patching to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, tells organisations to inventory PHP including the copies embedded in other software (“prevalence may not be directly observable”), recommends taking PHP systems offline if they cannot be patched or are on unsupported 8.1-and-earlier branches, and says a WAF may provide some protection. It also states, accurately as of its publication: “While CISA has not observed exploitation of these vulnerabilities as of the time of publication.”

Amazon had. Both statements are true, and the gap between them is the point. A national agency’s “no observed exploitation” is a statement about one sensor estate on one clock, not a property of the world — and in this case a private honeypot network held contradicting evidence four days older than the advisory. Treat “no known exploitation” as a visibility report, never as a risk rating. Amazon’s own third lesson lands in the same place: invest in detections that do not depend on a CVE-specific signature, because first exploitation routinely precedes the signature.

As of our check of the CISA Known Exploited Vulnerabilities catalogue — version 2026.10.21, 1,754 entries — neither CVE-2026-109618 nor CVE-2026-109619 is listed. Federal remediation deadlines under BOD 22-01 therefore do not yet attach. Given Amazon’s telemetry, we would expect that to change, and would not wait for it to.

The record is now unambiguous, and the scoring is not

Both CVEs were published to NVD at 2026-10-21 14:17 UTC — seventeen minutes after the embargo lifted — and were last modified 2026-10-22 10:09 UTC, currently in Modified status. NVD carries both descriptions essentially as PHP wrote them: CVE-2026-109618 is the longjmp()-based out-of-memory path that leaves request memory uninitialised before an allocation, with cleanup then reading or branching on it; CVE-2026-109619 is the global state that keeps pointing into request memory after it is freed, consumed by a later request before initialisation.

The scores are where it gets interesting. Both carry the vendor’s CVSS v4.0 9.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) and an NVD-assigned CVSS v3.1 of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H). Those are not describing the same bug in the same way: the v4.0 vector concedes high attack complexity and a present attack requirement, while the v3.1 vector asserts low complexity. The lower number is the more pessimistic assessment of exploitability, and the higher number is the more pessimistic assessment of ease. If your prioritisation pipeline keys on a single numeric threshold, PHP2Shell is a worked example of why that is fragile — and the PoC timeline above suggests the AC:H judgement did not hold back anyone in practice.

Palo Alto: everything affected, nothing fixed, scored as a crash

The appliance problem is where most estates will actually be stuck, and Palo Alto Networks’ advisory is an instructive read. Published 21 October and updated 22 October, discovered internally, it lists PAN-OS 12.2, 12.1, 11.2, 11.1 and 10.2 as “All” affected, and Panorama as “All” affected, with fixed versions in every row recorded as “None (ETA: TBD)”. Bridgecrew, Cloud NGFW, the Cortex line, GlobalProtect App, Idira, Prisma Cloud and Prisma Access are listed unaffected. The advisory is explicit that “no special configuration is required to be affected,” and that risk is highest where the management interface is reachable from the internet — the same exposure that put PAN-OS in KEV earlier this month.

Note the severity carefully, because it is easy to misread. Palo Alto scores the issue in their products at CVSS-B 8.7, with urgency MODERATE, and the vector is the tell: VC:N/VI:N/VA:H — no confidentiality or integrity impact, availability only, mapped to CWE-754. In other words the vendor’s assessment is that on their appliances this behaves as a denial of service rather than the code execution it is elsewhere, and they state they are not aware of malicious exploitation against their products. They reproduce PHP’s 9.2 separately as the upstream vendor score, and note that restricting management access to a jump box drops their figure to 7.1. That is a defensible position and a materially different one from “your firewall is pre-auth RCE,” so do not let a headline score drive your change-control argument in either direction — but equally, “availability only” on an unpatched management plane with no fix ETA is not comfortable.

For the wider inventory problem, the Netherlands NCSC is running a public operational repository at NCSC-NL/php2shell, TLP:CLEAR, last significant README change 21 October 2026 17:25 CEST, with directories for detection and mitigation, per-product software status and tooling, and pointers to CERT-EU advisory 2026-018 and the ENISA CSIRTs Network advisory. It makes the same point we would: the impact is not limited to websites — PHP is embedded in appliances, network devices and management interfaces where administrators cannot update PHP themselves. That is the long pole, and it is measured in vendor release cycles, not in your patch window.

Hunting it

  • Move your investigation window back to 17 October. This is Amazon’s explicit guidance and the single highest-value change you can make today. Anything scoped from the 21st assumes a disclosure-date start that the evidence does not support.
  • Look for the upload-progress tell. Amazon recommends reviewing for POST requests containing the PHP_SESSION_UPLOAD_PROGRESS string in form uploads, plus web server log review and checks for unexpected process execution or file modification on web application servers. Pair that with the engine-level signals the researchers published: multipart requests followed by memory-limit errors or repeated 500s, oversized or malformed PHPSESSID response cookies, and unexplained worker churn.
  • Use the IOC list as investigative leads, not a blocklist. Amazon published six addresses — 103.216.220.92 (17 October), and 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37 (21 October) — while explicitly warning that these are shared anonymisation infrastructure, not exclusive to this activity, and that organisations should investigate observations rather than block. Blocking shared egress nodes buys little and breaks things.
  • If you cannot patch, constrain the vector and accept the cost. Amazon suggests considering blocking multi-part file uploads where patching is not immediately possible, with the sensible caveat of testing the application impact first. PHP’s own mitigations remain partial by the project’s own description; CISA and the NSA both say the fallback for an unpatchable system is to take it offline, which is the advice a number of European public bodies acted on this week per press reporting.
  • Chase vendor status for every embedded PHP you own. Palo Alto is the visible case; it will not be the only one. Track the NCSC-NL software list, and for anything with no fixed release, restrict management-plane reachability now rather than waiting for an ETA that is currently TBD.

We read the AWS Security Blog post, the CISA alert, the Palo Alto Networks advisory and the NCSC-NL repository first-hand, and pulled both CVE records and the KEV catalogue directly from NVD and CISA. We did not reproduce any exploitation attempt, resolve or contact any listed indicator, run any proof of concept, or test any third-party system. Amazon’s attribution of the 17 October activity to a threat actor, and its assessment that PHP2Shell is now broadly exploited, are Amazon’s own and carried as vendor telemetry. Reports of European government websites being taken offline are secondary press coverage, not independently confirmed by us.

Sources: