PHP2Shell exploitation began before fixes were available
The calendar matters here. Amazon Threat Intelligence says it observed attackers targeting the PHP2Shell flaws on October 17, four days before PHP released security patches on October 21. That turns this from a routine “install the update” story into a reminder that public disclosure dates rarely tell defenders when hostile activity actually began.
The observation came from MadPot, Amazon’s honeypot network. According to Amazon, the first attempts targeted a honeypot while the vulnerabilities were still under embargo. The activity originated from an IP address associated with a commercial anonymization network. AWS Chief Information Security Officer CJ Moses said that suggested a threat actor was involved, but Amazon did not know how the actor obtained information about the flaws before disclosure.
That distinction matters. A honeypot records activity directed at a decoy; it does not establish that an exposed production server was compromised. Amazon said it remained unclear whether the observed attempts would have succeeded against real-world systems. Payloads and anonymization choices varied, and technical analysis was still ongoing. The defensible conclusion is narrow but important: targeting started before patches, while the scale and success of those early attempts were not confirmed.
What the PHP2Shell report says—and does not say
PHP2Shell refers to two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can enable unauthenticated remote code execution on vulnerable systems, according to the reporting and Amazon’s security advisory. The PHP team released fixes October 21. The vulnerabilities affect PHP deployments, including services behind popular content management systems; the presence of WordPress, Drupal, or Joomla alone does not establish that a server is vulnerable. The relevant issue is the PHP runtime and whether it has been updated to a fixed version.
The disclosure process also moved earlier than originally planned. Reporting says the PHP team had to accelerate the targeted release date beginning October 20 after details—including the CVE identifiers and mitigation advice shared with some critical infrastructure providers—leaked online. Some proof-of-concept material appeared before patches, but the PHP security team said those examples were not functional. Amazon later reported that attackers deployed multiple PHP2Shell proof-of-concept exploits hours after disclosure, from VPN IP addresses. Contemporaneous reporting also described the PHP2Shell disclosure leak and emergency patching.
Those are separate points in the timeline: pre-disclosure attempts against a honeypot; a compressed disclosure schedule after information leaked; and exploit activity after public disclosure. They should not be collapsed into one claim that every attempt worked. Amazon said the activity was now broadly occurring in the wild, but also said the success rate was unclear. Its warning is practical: defenders should not assume that a public announcement marks the first day of exploitation.
Why a four-day gap changes incident response
Many incident processes start their search window at a CVE announcement or vendor advisory. That’s convenient, but this case shows why it can leave a blind spot. If an organization operated an affected PHP service during the days before patches, the investigation should consider that earlier exposure window rather than treating October 21 as day one.
Amazon specifically advised defenders to investigate from at least October 17. That is a useful starting point tied to the observed activity, not proof that every PHP environment was attacked on that date. Security teams should review relevant web-server and application telemetry for the affected period, preserve evidence before routine retention deletes it, and compare suspicious requests with the vendor and threat-intelligence indicators available to them.
The practical question is not whether an organization’s logs contain a request that looks vaguely unusual. It is whether systems running vulnerable PHP received exploit attempts, whether those requests were followed by unexpected process or file activity, and whether the affected runtime remained exposed after fixes were available. A timeline-based review helps answer those questions without overstating what the Amazon report demonstrates.
Patch first; treat workarounds as temporary
The PHP team released security updates on October 21. Amazon’s guidance is to upgrade immediately to fixed PHP versions. AWS says upgrading is the only complete remediation for both CVEs; it does not identify a configuration-only workaround that fully resolves both vulnerabilities.
That makes prioritization straightforward. Inventory externally reachable PHP deployments, confirm the actual runtime versions, and patch systems that remain affected. Include applications whose PHP runtime is managed through hosting platforms or containers: a web application’s brand or framework does not tell you whether the underlying PHP version is fixed. Confirm the update in the running environment rather than relying only on a change ticket or a build artifact.
For deployments that cannot be patched immediately, Amazon says organizations may consider blocking multipart file uploads, while evaluating the effect on their applications before enabling that restriction. That is a stopgap to assess, not a substitute for upgrading. A workaround can disrupt legitimate functionality and still leave risk that the vendor patch removes.
Look beyond a single signature
A newly disclosed vulnerability often outpaces the availability of reliable detection signatures. AWS recommends looking for suspicious POST requests associated with exploitation, but a request pattern should be treated as an investigative lead, not a verdict on its own. Review surrounding application and host activity, and correlate events across the relevant timeframe.
The same discipline applies to the pre-patch period. If logs are retained only briefly, preserve what remains for affected systems and check whether monitoring records the necessary request details. Where a suspicious request is found, determine what happened next: whether the server generated unexpected files, launched unusual processes, or made anomalous outbound connections. Those are checks for defenders to conduct, not outcomes established by the honeypot report.
Amazon’s evidence came from its own sensor network and provides a useful early signal. It does not offer a complete census of attacks across the internet. The report explicitly leaves open how many attempts succeeded, and says the underlying technical analysis was continuing. Keep those limits in view while responding quickly; uncertainty is a reason to investigate, not a reason to wait.
A concise response checklist
- Identify PHP services and verify their runtime versions, especially internet-facing deployments.
- Apply the PHP security updates that fix CVE-2026-109618 and CVE-2026-109619.
- For systems still awaiting updates, assess whether temporarily blocking multipart uploads is viable; do not treat it as complete remediation.
- Review logs from at least October 17 for affected systems, not just from the October 21 patch release.
- Investigate suspicious POST activity alongside subsequent process, file, and network behavior.
- Record what was exposed, when it was patched, and what evidence was reviewed.
The core lesson is blunt: patch promptly, and set the investigation window according to the earliest credible activity—not the date an advisory made it public. In this case, Amazon’s October 17 observation gives defenders a concrete place to start, while the unanswered questions about successful compromise deserve careful, system-by-system review.
Sources
- Amazon says PHP2Shell exploitation began four days before patches
- Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure
