Four Days: Inside the PHP2Shell Exploitation Window

Attackers were testing PHP2Shell before a patch was available. Here’s what happened, what our MDR team found across 23 client environments, and why older vulnerabilities proved just as important.

On October 17, 2026, a request hit one of Amazon’s honeypots. Routed through an anonymization network, it targeted a previously undisclosed vulnerability in PHP. The official fix was still four days away.

PHP powers roughly seven in ten websites whose server-side language is known, making a critical vulnerability in its core a potential concern for organizations worldwide.

At COGNNA, we began investigating before the vulnerability became public knowledge. We checked which clients were exposed, hunted for signs of exploitation, and examined what was happening across their environments.

What we found was not the straightforward story of a new vulnerability being exploited. It was a reminder that the threats making headlines are not always the ones knocking on your door.

Four Days That Changed the Timeline

Researchers had identified the underlying weakness years earlier, but its exploitability had not been established. In August 2026, researchers at Calif and OpenAI used advanced AI techniques to demonstrate that it could be exploited.

PHP planned a coordinated security release for October 22. Then the plan broke.

On October 17, Amazon detected an exploitation attempt against the vulnerability in its MadPot honeypot infrastructure. On October 20, the CVE identifiers leaked, prompting PHP to move its security release forward. A mistakenly published exploit demonstration accelerated efforts to reproduce the attack.

The patch arrived on October 21. Organizations began identifying vulnerable systems and applying updates, with some government websites taken offline during remediation.

But publishing a patch does not mean every vulnerable server gets fixed immediately. Organizations must locate affected installations, assess compatibility, coordinate maintenance windows, and restart services where necessary. Meanwhile, attackers can continue testing whatever remains exposed.

That gap between disclosure and remediation is where active threat hunting becomes critical.

Inside Our MDR Investigation

We approached the investigation in three stages: identify exposure, hunt for exploitation, and determine whether any attempts had succeeded.

1. Finding exposed systems

Our initial attack surface scan identified three clients with PHP published directly to the internet. We notified each client and recommended patching the affected systems.

This is the starting point for vulnerability response: knowing what is exposed. PHP may run on standalone servers, inside containers, or as part of applications that are not always visible in a central software inventory.

2. Hunting across 23 client environments

We expanded the investigation to 23 clients running PHP, reviewing activity from October 15 through October 25. Starting two days before Amazon’s first reported sighting allowed us to investigate activity that might have preceded public disclosure.

We used multiple signals to identify impacted systems. Our newly published ASM module helped identifying publicly accessible and vulnerable hosts for our clients, we leveraged the Velociraptor PHP2Shell YARA artifact, consulted public detection rules such as Elastic Security Labs’ detection guidance and CISA’s Sigma rule, and deployed a new updated detection rules written specifically for PHP.

We also studied a public proof of concept to understand how exploitation worked and what traces it might leave behind.

The objective was not simply to search for a known exploit signature. We needed to determine what the activity targeted, whether it matched PHP2Shell, and whether it indicated a successful compromise.

3. Separating the new threat from the old ones

The results were revealing.

Across the different environments we monitor including honeypots, we identified over 4,502 PHP exploitation attempts targeting 29 hosts from 200 public IP addresses.

None of the attempts we observed could be attributed to PHP2Shell. Approximately 90% were associated with the RedTail cryptomining botnet, exploiting CVE-2024-4577, a vulnerability affecting PHP-CGI on Windows that was disclosed in 2024.

While the security community focused on a newly disclosed vulnerability, much of the exploitation activity in our clients’ environments involved a bug that had been known for years.

The vulnerability in the headlines was not the vulnerability behind most of the activity we observed.

This distinction matters. A spike in exploit traffic does not automatically mean a particular vulnerability is being exploited. Security teams must establish what the activity targets before deciding how to respond.

4. Determining whether the attacks succeeded

None of the observed attempts we investigated succeeded. Most targeted software that was not installed on the affected systems. Of the 121 attempts that received a normal response, we found no evidence of an impact.

We also reviewed more than one million cases in which a web server or PHP process started a shell. Every case we examined had a legitimate explanation, including scheduled jobs, deployments, and document conversion.

A web server spawning a shell can be a valuable indicator of suspicious activity, but it is not proof of compromise on its own. Elastic Security Labs’ PHP2Shell detection analysis similarly explores web-server shell execution as a key detection opportunity.

Without context, broad detection rules can overwhelm security teams with false positives. With context, investigators can distinguish routine operations from activity that warrants further investigation.

The findings were reassuring, but they were not a reason to stop monitoring.

Why the Threat Is Still Evolving

Our analysis of the public proof of concept helped explain why exploitation was not straightforward. It relied on a specific PHP build and memory offsets measured in advance. Changing the target environment could cause those assumptions to fail.

However, that difficulty should not be mistaken for lasting protection. Subsequent research has demonstrated progress toward exploiting more hardened environments.

On October 26, SecurityWeek reported that PHP2Shell exploitation had progressed from probes to working shell commands on honeypots.

Attackers can refine their techniques, adapt publicly available code, and build on other researchers’ discoveries. An exploit that initially works only under specific conditions may become more effective over time.

The lesson is simple: use the available time to patch, validate exposure, and strengthen detection rather than assume exploitation is too difficult to succeed.

When Patching Cannot Happen Immediately

One client told us they could not update immediately because the required downtime was unacceptable. Their request was straightforward: keep a closer eye on their assets.

This is a familiar operational challenge. Security teams may understand the urgency of a patch while business teams face genuine constraints around availability and compatibility.

Monitoring is not a substitute for remediation, but it can help organizations manage risk while they work toward a fix.

For PHP2Shell, updating to a patched version remains the primary solution. Configuration changes do not fully address both vulnerabilities.

If an affected system cannot be updated promptly, organizations should assess whether they can remove its internet exposure and apply additional controls while arranging remediation.

What Organizations Should Do Now

1. Find every PHP installation

Inventory PHP across internet-facing servers, internal systems, containers, and applications that bundle their own runtime. Compare the inventory against external attack surface discovery and endpoint telemetry to identify overlooked systems.

2. Patch affected systems

According to watchTowr’s PHP2Shell FAQ, the relevant patched releases are:

Verify the applicable vendor guidance for your specific deployment. After updating, restart PHP where required and confirm that the patched version is running.

3. Prioritize internet-facing assets

Patch exposed systems first. If immediate remediation is not possible, assess whether the service can be taken offline or restricted from external access. Apply additional protective controls while arranging a permanent fix.

4. Investigate activity dating back to October 17

Review web server, endpoint, and PHP telemetry for suspicious process activity, unexpected shell execution, and unusual memory-related errors.

Use established detection guidance, including Elastic Security Labs’ analysis and CISA’s Sigma rule. Tune detections to your environment and validate alerts against legitimate workloads.

A lack of alerts is not proof that a system was never compromised. Your conclusions depend on the telemetry available and the period it covers.

5. Keep monitoring

PHP2Shell exploitation research continues to evolve. Monitor updated advisories, reassess exposure, and review detection coverage as new techniques emerge. A vulnerability investigation should not end simply because the initial wave of activity has passed.

The First Request Is Still Unanswered

We still do not know who sent the request that first reached Amazon’s honeypot. Amazon’s investigation confirmed the October 17 attempt but did not establish who was behind it.

What we do know is that the exploitation attempts we observed across our clients largely involved older vulnerabilities, not PHP2Shell. None of the attempts we investigated succeeded, and we found no evidence of impact from the activity examined.

That is good news, but it is not the end of the story.

At COGNNA, we are keeping our new detection rules active and continuing to monitor the environments we protect.

Because the next suspicious request may not land on a honeypot.‍

It may land on your server.