PHP2Shell did not wait for defenders to finish reading the advisory. Amazon has traced an exploitation attempt to October 17, 2026, four days before PHP publicly disclosed CVE-2026-109618 and CVE-2026-109619. More attempts appeared before the coordinated release, and broad exploitation attempts followed within hours of the patches.

That does not prove every observed payload worked, or that a named production organization was compromised. It does change the incident-response window. An internet-facing PHP server that remained vulnerable on October 17 should not be treated as a routine patching ticket with October 21 as day zero.

This is a follow-up to our initial PHP2Shell exposure assessment. The fixed versions and root causes have not changed. What has changed is the evidence about attacker activity, the demonstrated impact beyond a visible shell, and the amount of operational guidance now available from cloud providers, distributions, researchers, and hosting platforms.

TL;DR

  • Amazon observed the earliest known PHP2Shell exploitation attempt on October 17, while the vulnerabilities were still under embargo. It then saw several actors and broad attempts around the October 21 release.
  • AWS says it is unclear whether the early attempts would have succeeded on real systems. Public evidence of attempts is not proof of a successful compromise.
  • Independent researchers reproduced pre-authentication code execution. Wiz also demonstrated remote PHP process-memory disclosure, which can expose secrets without producing an obvious shell.
  • Application authentication, a CMS update, or a WAF alone does not repair the PHP runtime. Install a corrected PHP or vendor-backported package and replace every serving worker.
  • Hunt from at least October 17. Look for suspicious multipart traffic, PHP memory errors, unexpected child processes, file changes, persistence, and outbound connections—but do not expect one universal PHP2Shell indicator.

What Changed After the Patch Release

The first day of PHP2Shell reporting mixed together three different questions: can the flaws be exploited, are attackers trying, and have they succeeded against production systems? We now have better answers, but they are not all the same answer.

QuestionWhat is established as of October 23
Can the flaws produce RCE?Yes. PHP’s advisories document unauthenticated RCE, and several research teams independently reproduced attack paths.
Can an attacker bypass application login checks?Yes for demonstrated pre-application paths. PHP parses the malicious request before the target application’s authentication code runs.
Are attackers trying in the wild?Yes. Amazon observed attempts before disclosure and broad attempts after release.
Did every observed attempt work?No such conclusion is supported. Amazon explicitly says the success of the early payloads on real systems was unclear.
Is there a publicly verified, named victim compromise?We found no authoritative public report establishing one by the time of this review. That absence is not evidence that none occurred.
Is a clean crash dashboard proof of safety?No. A successful exploit does not have to crash the PHP worker, and memory disclosure may leave different evidence from command execution.

The timeline is now operationally important:

  • October 17: Amazon’s MadPot telemetry recorded an attempt from commercial anonymization infrastructure.
  • October 20: the CVE identifiers and incorrect severity details circulated publicly; PHP advanced its release schedule.
  • October 21, before 14:00 UTC: Amazon observed multiple proof-of-concept payloads and attempts from different anonymized infrastructure, suggesting more than one actor.
  • October 21, 14:00 UTC: PHP published the corrected releases and advisories.
  • Within hours: additional proofs of concept appeared and were used against Amazon’s sensors almost immediately.

Amazon calls the current activity broad exploitation attempts in the wild. Its wording matters: defenders should act on the activity, while analysts should preserve the distinction between an attempted exploit, demonstrated lab reliability, and a verified intrusion.

The Impact Is Broader Than “A Shell Appeared”

The nickname PHP2Shell emphasizes command execution, but it can narrow an investigation too much.

Code execution inherits the PHP worker’s access

The immediate execution context is normally the account running the web worker, not automatically root. That boundary still contains valuable access: application code and configuration, database credentials, API tokens, signing material, writable web directories, internal services, and any cloud or workload identity exposed to the process.

From there, the outcome depends on the deployment. A tightly confined, read-only worker is a different incident from a shared hosting process with broad file access or a web tier holding long-lived infrastructure credentials. The CVE does not make those architectures equivalent; it gives the attacker the privileges that the affected process already has.

Process-memory disclosure can steal secrets without spawning a shell

Wiz demonstrated application-independent disclosure of PHP worker memory in addition to RCE. Process memory may contain passwords, session material, API keys, tokens, certificates, or data belonging to requests handled by that process.

This creates a quieter failure mode. A defender looking only for sh or bash beneath php-fpm can miss an attacker whose objective was to read memory and leave. The exact data available depends on what the worker processed and retained; the research does not justify claiming that every secret on a host is exposed.

A successful request does not need to look like a crash storm

Datadog’s independent reproduction found that exploitation does not inherently require brute force or a crashing worker. Memory-exhaustion errors and HTTP 5xx responses remain useful leads, but their absence cannot clear a host. Likewise, ordinary HTTP 200 responses do not establish successful exploitation.

This is why incident review needs both sides of the boundary: request telemetry at the proxy or WAF, and process, file, network, and identity activity on the origin.

Why “We Updated WordPress” Is Still the Wrong Test

PHP2Shell lives in the interpreter. WordPress, Drupal, Joomla, Laravel, and other applications are useful demonstration targets because they reach the runtime in realistic ways; they are not the component that the PHP patch replaces.

The corrected upstream releases remain:

PHP branchCorrected upstream release
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Do not turn that table into a simplistic string comparison. Ubuntu, Red Hat, hosting vendors, and extended-support providers can backport fixes while retaining an older upstream version number. Ubuntu, for example, published corrected packages for supported releases and ESM-covered older releases. The full distribution package version is the evidence, not only PHP 8.x.y in a banner.

Plesk illustrates a second inventory trap. Its advisory covers both customer-selectable PHP packages and the PHP-based sw-engine or plesk-engine used by the control panel itself. Plesk’s corrected 7.4, 8.0, and 8.1 builds retain the same PHP version number and are distinguished by build date. Checking one website’s CLI binary would miss both facts.

Containers add the same problem in another form. Rebuilding an image is not enough if an old digest is still running on one replica, scheduled job, canary, or standby node. Record the corrected package or image digest, deployment time, and worker replacement time for every serving instance.

How to Hunt Without Pretending There Is One Magic IOC

Start the review at 00:00 UTC on October 17, 2026, or earlier if your own threat intelligence justifies it. Preserve the raw evidence before log rotation or a rebuild removes it.

Request and edge telemetry

Prioritize unusual multipart/form-data POST requests to PHP-backed routes, especially:

  • requests containing PHP_SESSION_UPLOAD_PROGRESS where the application does not use that feature;
  • abnormal numbers of multipart sections, empty file parts, deeply nested field names, or excessive per-part headers;
  • repeated multipart requests from one actor or campaign against unrelated PHP routes;
  • requests followed by memory-limit errors, worker anomalies, unusual response sizes, or backend timeouts;
  • traffic from the anonymization addresses published by AWS, used only as investigation pivots rather than proof or permanent block indicators.

Standard NGINX or Apache access logs usually do not retain multipart request bodies. Not finding PHP_SESSION_UPLOAD_PROGRESS in a normal access log is therefore weak evidence. WAF, reverse-proxy, packet-capture, or application-performance telemetry may provide the missing body and transaction context.

Cloudflare deployed several managed rules and a response-aware control that can correlate both sides of a transaction. AWS published WAF patterns for multipart uploads, request size, rate limiting, and the upload-progress field. Both providers are clear about the limit: edge rules reduce exposure to known paths but cannot observe PHP’s internal state or cover every server-side producer and consumer.

Origin and workload telemetry

Correlate suspicious request times with:

  • a shell, interpreter, downloader, archive tool, or system utility launched by php-fpm, php-cgi, httpd, apache2, lsphp, or a FrankenPHP process;
  • unexpected outbound DNS, HTTP, TLS, SSH, or database connections from a web worker;
  • new or modified PHP files in web roots, upload directories, caches, temporary directories, or plugin and theme trees;
  • new cron entries, systemd units, authorized keys, users, scheduled tasks, or application administrator accounts;
  • access to instance metadata, secret stores, cloud APIs, control-panel credentials, or deployment keys;
  • PHP OOM, fatal, parse, timeout, session, unserialization, or early-configuration diagnostics that align with abnormal requests.

Each item is a lead, not a PHP2Shell verdict. Web applications legitimately upload files, spawn helper processes, and write caches. The useful evidence is the correlation between an unusual request, the serving worker, and an action that does not fit the application’s baseline.

If process-memory disclosure is plausible, add identity and secret-use logs to the review. A stolen token may be used from another system after the web request ends, leaving no webshell on the PHP host.

Public Exploit Code Is a Separate Risk

Exploit repositories appeared quickly after disclosure. Their labels do not establish that they are functional, safe, or even related to the real vulnerability. Early PHP2Shell repositories included incomplete claims and prank behavior, while researchers continued adapting reliable chains to specific versions, SAPIs, applications, and memory layouts.

Do not run an unknown exploit on a production server to answer whether it is vulnerable. That test can crash workers, expose data, execute hidden payloads, or destroy the evidence needed for an investigation. Validate remediation through package provenance, deployed artifact identity, worker replacement, and a controlled non-production test built from trusted source.

What You Can Do Today

  1. Patch the runtime, then replace every worker. Deploy a corrected upstream release or your vendor’s documented backport. Restart or roll every Apache, FPM, CGI, LiteSpeed, FrankenPHP, control-panel, and container instance that loaded the old runtime.
  2. Prove what serves each domain. Map the public route to its real SAPI, FPM pool, container or remote backend. A local CLI version does not prove what an NGINX upstream or hosting panel executes.
  3. Record package-level evidence. Save the full package version, repository or vendor advisory, image digest, deployment time, and process start time. This is especially important for backports whose upstream version string does not change.
  4. Hunt from at least October 17. Preserve WAF, proxy, web-server, PHP, EDR, audit, DNS, flow, cloud-control-plane, and identity logs. Correlate request activity with host behavior rather than relying on a single IP list.
  5. Use temporary controls honestly. If patching is delayed, block multipart requests where the application does not need them, disable session upload progress, apply the PHP 8.5 backtrace mitigation where applicable, and enable managed WAF protections. These controls cover selected paths, not both CVEs completely.
  6. Respond to evidence as an intrusion. Contain the affected workload, preserve volatile and disk evidence, scope reachable systems and data, and rotate exposed secrets after containment. Patching prevents reuse of the fixed paths; it does not remove persistence or invalidate stolen credentials.
  7. Ask hosting providers for specifics. Request the exact corrected build for both CVEs, the SAPI serving your account, the worker replacement time, and whether the provider reviewed telemetry back to October 17. “We updated PHP” is not enough evidence for a shared platform.

The most important update is not that PHP2Shell suddenly became simple or universally reliable. It is that attackers did not respect the disclosure date, multiple teams have demonstrated serious impact, and a clean patch event cannot retroactively prove that an exposed worker was untouched.

Sources