Skip to content

Back to the catalog

Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
aws.amazon.comarticle

Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot

Amazon Threat Intelligence reports PHP2Shell exploitation (CVE-2026-109618, CVE-2026-109619) seen in MadPot honeypot telemetry on 17 October 2026, four days before the 21 October disclosure, from anonymization-network IPs. Multiple actors and PoCs appeared within hours of the patch. It recommends upgrading PHP, hunting for PHP_SESSION_UPLOAD_PROGRESS in multipart POSTs, and investigating from the earliest exploitation date, with patch SLAs measured in hours.

TL;DR AWS honeypot data shows PHP2Shell was exploited four days before disclosure, so defenders should patch in hours and investigate from 17 October 2026.
Open original ↗
Document

What it is

Amazon Threat Intelligence saw a PHP2Shell exploitation attempt against its MadPot honeypots on 17 October 2026. That is four days before public disclosure of CVE-2026-109618 and CVE-2026-109619 on 21 October. The source IP belonged to a commercial anonymization network. The page does not say how the actor learned of the bug during the embargo.

How it works

The page gives no exploit mechanism and says technical analysis is ongoing. The only payload-level indicator is the string PHP_SESSION_UPLOAD_PROGRESS in multipart POST form uploads.

Timeline

  • 17 October 2026: first attempt seen in MadPot.
  • 21 October, 0200 UTC: earliest public proof of concept, about 12 hours before the embargo ended.
  • 21 October, 0200 to 0800 UTC: more attempts from other anonymized infrastructure. Payloads and anonymization choices differed, which Amazon takes to mean several actors.
  • 21 October, 1400 UTC: embargo lifted and patch released. More PoCs followed within hours and were used against the sensors almost immediately.

Amazon states PHP2Shell is now broadly exploited in the wild.

What to do

  • Upgrade to the fixed PHP versions. The page names no version numbers. It says upgrading is the only complete fix for both CVEs and that no configuration-only workaround covers both.
  • If you cannot patch yet, consider blocking multipart file uploads. Test the effect on your application first.
  • Search POST requests for PHP_SESSION_UPLOAD_PROGRESS in form uploads.
  • Review web server logs, and check web application servers for unexpected process execution or file modification.
  • Start the investigation window at 17 October, not at the disclosure date.
  • Treat the published IPs as investigation leads, not a blocklist. They are shared anonymization infrastructure and not exclusive to this activity.

Caveats

  • Amazon does not know whether any observed attempt would have succeeded against a real system.
  • The page cites AI-assisted conversion of patch diffs into exploits as the reason time to exploit is shrinking. This is Amazon's assessment, not a measured result.
  • Amazon argues that 7-day or 30-day patch SLAs are obsolete for critical internet-facing systems and should be measured in hours. It also recommends detections that do not depend on a CVE-specific signature.
  • The page leaves out the fixed version numbers, the affected version range, the exploit mechanism and the IOC list itself.

Organisations named here

  • PHP_SESSION_UPLOAD_PROGRESS

CVEs named here

  • CVE-2026-109618
  • CVE-2026-109619

Technologies named here

  • PHP
  • AWS re:Post and AWS Support
  • AWS
  • MadPot

Techniques named here

  • Honeypot telemetry for early detection of exploitation

Threat actors named here

  • PHP2Shell

Related in Threat Intel