Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

Elastic Security Analyzer graph showing systemd, then php-fpm, then a second php-fpm process, then a terminated whoami process, with the alert Suspicious Child Execution via Web Server rated Medium at Oct 21, 2026 10:27:36.
Screenshot: Elastic Security Labs, a controlled PHP-FPM diagnostic launching whoami that raised a Suspicious Child Execution via Web Server alert (the test did not exploit either CVE), Oct 21, 2026 (fair use).

Detection

Amazon Saw a PHP2Shell Exploit Attempt Four Days Before Disclosure, as Cloudflare Counts Millions of Tries and Elastic Says the Signal to Hunt Is a Web Server Spawning a Shell

Amazon Threat Intelligence says its MadPot honeypots caught a PHP2Shell attempt on Oct. 17 and told defenders to start investigations from that date, not from the advisory. Elastic, writing before any reliable public exploit existed, published the process and file rules that catch what a compromised PHP worker does next. The IP addresses, rule names and inventory queries defenders need.

Ava Okello, DetectionLondon6 min read

LONDON - Someone was trying the PHP2Shell flaws four days before the world knew they existed. Amazon Threat Intelligence said its MadPot honeypot network recorded an exploitation attempt against CVE-2026-109618 and CVE-2026-109619 on Oct. 17, while the two critical PHP core bugs were still under embargo, from an IP address associated with a commercial anonymization network.

"The targeting of a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure," Amazon wrote in a post signed by CJ Moses, the chief information security officer of Amazon Integrated Security. The company told security teams to "start investigations from the earliest known exploitation, not from the disclosure date," and, for PHP2Shell, to investigate from at least Oct. 17.

That moves the start of the hunt window back by four days for every team that patched on Wednesday and assumed the clock started with the advisory.

From embargo to "broadly exploited"

The embargo was due to lift at 14:00 UTC on Oct. 21. Amazon said it identified multiple proof-of-concept exploits that day, the earliest around 02:00 UTC, and between 02:00 and 08:00 UTC saw more exploitation attempts against MadPot from other anonymized infrastructure. The payloads and the anonymization services varied, which Amazon said suggests multiple actors. It said analysis was ongoing and that it was unclear whether any of those attempts would have succeeded against real systems.

Once the patch shipped, Amazon said, more exploits appeared within hours "and we saw them used against our sensors almost immediately. PHP2Shell is now being broadly exploited in the wild."

Header and opening of the AWS Security Blog post Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, by CJ Moses, Oct 21, 2026, stating that an exploitation attempt dating to Oct. 17 was identified four days before public disclosure.
Screenshot: AWS Security Blog, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, Oct 21, 2026 (fair use).

Others saw the same surge. "In the 10 hours before it was publicly announced, across the Cloudflare network we saw thousands of attempts to exploit it," Cloudflare chief executive Matthew Prince said Thursday, according to SecurityWeek. "That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now."

Much of that traffic is noise. watchTowr's head of threat intelligence, Jake Knott, told SecurityWeek that "the exploits being sprayed indiscriminately either don't work at all, test for timing-based differences, or crash the target." VulnCheck told the publication that at least one Chinese IP address had tried, without success, to use PHP2Shell to deploy a web shell. The exposure is large: of 2.58 million internet-facing hosts Censys saw on Oct. 21, roughly 1.58 million reported an identifiable PHP version and about 1.57 million of those were not patched, SecurityWeek reported.

The National Security Agency said on Wednesday that "cyber actors are likely to weaponize PHP2Shell vulnerabilities," and recommended enhanced logging, replacing end-of-life PHP services and taking systems offline if they cannot be updated immediately.

AWS Security Blog list of immediate recommended actions and an Indicators of Compromise table listing IP addresses 103.216.220.92 observed 10/17/2026 and 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37 observed 10/21/2026.
Screenshot: AWS Security Blog, Amazon's recommended actions and PHP2Shell indicators of compromise, Oct 21, 2026 (fair use).

What to look for

Amazon published six IP addresses: 103.216.220.92, seen on Oct. 17, and 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37, seen on Oct. 21. It warned that they include shared anonymization infrastructure and are not exclusive to this activity, and that organizations should investigate any hits rather than block them. It also told defenders to look for POST requests carrying the PHP_SESSION_UPLOAD_PROGRESS string in form uploads, review web server logs and check for unexpected process execution or file modification on web application servers. Where patching cannot happen at once, Amazon suggested considering blocking multipart file uploads after weighing the effect on the application.

The trigger itself may leave little behind, which is why Elastic Security Labs built its guidance around what comes next. Writing on Oct. 21, before any reliable public proof of concept could be run end to end, researchers Ruben Groenewoud and Bryan Porras Blanch argued that the bug class matters less than the outcome. "An RCE in a PHP web application ends in the same observable place: a PHP worker process doing something a PHP worker process should not do," they wrote.

Their endpoint rule Payload Execution by Web Server keys on a non-interactive parent such as apache2, httpd, nginx, php-cgi, php-fpm or lsphp launching bash, dash, sh, zsh or ksh with a -c argument and a command line that touches /dev/tcp, base64 -d, curl, wget or /etc/shadow, or runs id, whoami or hostname. Elastic pairs it with SIEM rules that match known-bad command lines from a web server parent and with a new_terms rule, Unusual Command Execution via Web Server, that learns what each web server normally runs on a host and alerts on anything new.

Elastic Security Analyzer graph from Elastic's earlier wp2shell investigation showing systemd, then apache2, then a second apache2 process, then a terminated dash process with three alerts, then a terminated hostname process.
Screenshot: Elastic Security Labs, process lineage from its earlier wp2shell investigation, shown as a behavioral example of a web server spawning a shell, Oct 21, 2026 (fair use).

Further layers cover a web server spawning a non-shell child such as an interpreter or downloader (Suspicious Web Server Child Process on the endpoint, plus Suspicious and Unusual Child Execution via Web Server in the SIEM), a web server pulling a second stage (Payload Downloaded via Curl or Wget by Web Server), and a web server writing new script content into the web root (Unusual File Creation via Web Server and File with High Entropy Created by Web Server). Elastic said the high-entropy rule requires Elastic Stack 9.3.0 or later with the Defend setting linux.advanced.events.populate_file_data turned on. The researchers were candid about the gaps: "there could be other forms of post-exploitation that we don't catch, like creation of an account or fileless PHP script execution."

What detection teams should do now

  • Set the hunt window for PHP2Shell to start on Oct. 17, 2026, not Oct. 21, as Amazon recommends, and preserve web server and PHP logs from that date before rotating them.
  • Search web and WAF logs for Amazon's six IP addresses and for POST requests containing PHP_SESSION_UPLOAD_PROGRESS in form uploads. Treat IP hits as leads to investigate, not as block-list entries.
  • Alert on any web server or PHP worker process (apache2, httpd, nginx, php-fpm, php-cgi, lsphp) spawning a shell, an interpreter such as python -c or perl -e, or curl and wget, whatever SIEM or EDR you run.
  • Watch the web root for new .php or .phtml files and high-entropy script files written by the web server account, and for new cron entries, systemd units or SSH authorized_keys added afterward.
  • Inventory PHP beyond the obvious web tier. Elastic published a Kibana process query and Osquery file, deb and rpm package queries to find PHP binaries, PHP-FPM pools and Apache PHP modules on Linux and Windows, including control-panel and bundled runtimes.
  • Patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and measure the deadline in hours. "A 7-day or 30-day SLA assumes a delay that no longer exists," Amazon wrote.

Sources:


Ava Okello covers detection engineering, EDR telemetry and SOC hunting for SOCtember from London.

Related stories

Detection desk