PHP2Shell, LiteLLM, and Node.js: Inside Exaforce’s Real-World Customer Threat Hunts

More than 5× typical weekly hunt volume. Over 1.3 million indicators evaluated. And in one LiteLLM case, 1 hour 39 minutes from detection to a consolidated remediation plan. Here is how Exaforce paired automated hunts with MDR investigation to turn three fast-moving threats into customer-specific action.

Introduction

Three fast-moving threats landed in the same week: PHP2Shell, the LiteLLM supply-chain backdoor, and a major Node.js security release. For defenders, the challenge was determining exposure, investigating suspicious activity, and prioritizing action across customer environments before these exposures turned into exploits.

During the week of October 18, 2026, the Exaforce MDR team handled more than 5× typical weekly hunt volume, measured against the weekly average over the prior three months, and evaluated over 1.3 million medium-and-higher indicators of compromise. Our Exaforce AI SOC platform carried the breadth of the hunt; our MDR analysts supplied the judgment, correlating findings with endpoint evidence and turning them into environment-specific remediation plans.

Across all three hunts, the focus was turning new intelligence into customer-specific action quickly. For PHP2Shell, automated hunts started as soon as the CVEs entered our feeds, and impacted customers received tenant-specific assessments and patch priorities by that evening. For LiteLLM, our MDR team combined hunt results with EDR evidence to deliver a consolidated case and remediation plan 1 hour 39 minutes after detection, identifying suspicious activity across 12 hosts. For Node.js, code-based hunts translated the advisory into an actionable inventory: vulnerable components across 5 repositories, a service requiring a major-version upgrade, and patch-level gaps needing review.

This article breaks down real-world customer case studies, showing how the Exaforce platform and MDR team worked together to help customers respond to these emerging threats.

Threat 1: PHP2Shell — from emergency patch to per-tenant answers in hours

On October 21, 2026, PHP shipped emergency releases (8.5.12, 8.4.27, 8.3.36, and 8.2.35) for CVE-2026-109618 and CVE-2026-109619. Both are CVSS 9.2 memory-safety flaws that can allow unauthenticated code execution through mod_php, PHP-FPM, and other request handlers, sometimes before application code runs. Affected code paths go back to PHP 5.4. Amazon Threat Intelligence later reported an exploitation attempt in its MadPot honeypots on October 17, four days before disclosure.

Reader update: PHP’s October 23 follow-up advisory also recommends keeping session.upload_progress.enabled=0 until the next regular bugfix release to protect against a remaining session-upload-progress edge case. Follow the current PHP and distribution-vendor guidance when patching.

What the Exaforce platform did

As soon as the CVEs hit our threat intelligence feeds, Exabot agents automatically ran a compromise hunt in every customer tenant. Each hunt looked for PHP workloads and exploitation signals in that tenant’s own telemetry, and wrote its results to the Exaforce Threat Center, linked from a single hunt finding.

What we told customers

By that evening, impacted customers had received a Threat Hunt Notice through their preferred communication channel: the ExaGo mobile app, Slack, Teams, email, or outreach from the MDR on-call team. Each notice was short and to the point:

• Whether the customer was affected.
• What we hunted and what we found.
• What we recommend: patch internet-facing PHP first, including WordPress environments, and confirm that PHP-FPM actually restarted.
• What we will keep doing: rerun hunts as new IOCs arrive.

Going beyond the hunt

Telemetry can reveal signs of an attack, but it does not always establish whether an environment is exposed. Our research team therefore built ExaPHP2Shell, a free scanner, and published a full technical analysis the next morning.

Example PHP2Shell hunt timeline

Threat 2: LiteLLM — investigating a credential-stealing supply-chain attack

On October 21, 2026, attackers used stolen GitHub credentials to push a trojanized LiteLLM 1.107.0 to PyPI and official Docker Hub and GHCR images. The package was available on PyPI from 11:39 to 13:20 UTC. Its payload was designed to run when Python started, even if LiteLLM was not imported, steal cloud and other credentials, send them to litellm[.]dev, and install an hourly backdoor loop. Wiz later observed stolen AWS credentials being used approximately four and a half hours after exfiltration.

That timing matters. In a supply-chain attack, the window between installation and credential abuse is critical.

Customer case study: multiple hosts affected

At one customer, suspicious activity appeared on production hosts four minutes after the release went live. Following disclosure, five automated hunts ran over the next eight hours, with the last hunt linking the activity to the attack. Our MDR analysts combined the hunt results with the customer’s EDR data and sent one consolidated case with a remediation plan that night, 1 hour 39 minutes after detection. The investigation found:

• 12 hosts used openssl under Python to package files into hidden folders, a pattern not previously observed in the tenant.
• 4 hosts—one VM and three GKE nodes—contacted the attacker’s domain, the cloud metadata endpoint, and GitHub.
• Follow-up hunts confirmed malicious files on four GKE nodes, and the files were quarantined the next morning. Payload execution and data exfiltration from this customer’s environment were not proven.
• Guidance identified the egress IPs to check, dropped files to look for, and specific accounts, identities, and API keys to rotate.
• Do not run pip install on an infected host: starting Python can rerun the payload. Replace affected nodes, isolate VMs, rotate credentials without waiting for forensics, and rebuild with the known-safe litellm==1.106.2 version pinned for this incident.

Threat 3: Node.js — answering “where are we running it?” from the code up

The same day, Node.js shipped fixes for ten vulnerabilities, four rated high severity. They included CVE-2026-111497, a Brotli decompression flaw that can lead to code execution, as well as TLS hostname verification and DNS handling issues. Patched releases were 26.12.1, 24.22.1, and 22.23.4. The releases also updated certificate trust following the eMudhra intermediate CA compromise. Updating a runtime version in configuration is not enough: rebuild and redeploy container images and update the Node.js runtime used by self-hosted applications, including Next.js.

A runtime vulnerability calls for a different hunt from a backdoor. There may be no exploit traffic to find yet. The useful question is inventory: which services run which Node.js version, and which cannot be patched on their current release line?

For customers with GitHub connected, Exaforce answered that question using software bills of materials (SBOMs) and repository lockfiles. At one customer, the hunt report identified:

• Multiple vulnerable components across 5 repositories.
• 1 service on Node.js 20.x, an end-of-life release line that will not receive the fix and requires a major-version upgrade.
• Multiple repositories pinned only a major Node.js version, leaving the patch level unconfirmed from code and requiring manual review.
• Endpoint gaps tied to the certificate issue: CLI tools such as curl still trusting the affected roots, one outdated Firefox installation, and multiple unsupported Microsoft Windows machines that would not receive an update.

The report also gave the customer a one-line test to distribute through MDM or EDR to find endpoints that still trusted the compromised certificates. That turned a broad advisory into a list of machines with owners.

How it works: agentic hunts, human judgment

These three threats looked very different: a pre-authentication RCE, a poisoned package, and a runtime security release. The response followed the same loop each time.

1. Automatic intelligence updates. New CVEs, advisories, and IOCs enter Exaforce’s threat intelligence feeds alongside our own research, with continuous updates as intelligence changes.
2. Hunt everywhere, automatically. Exabot launches a compromise hunt in every tenant against that tenant’s identity, cloud, endpoint, code, and SaaS data. No ticket or analyst queue is needed.
3. Findings, not noisy alerts. Results land in Threat Center as one hunt finding per tenant, with evidence attached.
4. Human judgment. MDR analysts review hits, combine related signals into one case, and write guidance specific to the environment: which hosts, accounts, and keys need attention.
5. Involve the customer where it matters. The team triages the noise so customers receive the steps that require their action.
6. Rerun as intelligence changes. Hunts rerun as new IOCs are published, and impact is reassessed as the threat picture develops.

Two things make this work. First, hunts use data the customer already sends us, so there is nothing new to deploy when a zero-day appears. Second, we are explicit about coverage. When a tenant lacks the telemetry to rule something out, the notice says so and explains exactly what the customer needs to check.

Key takeaways

This week showed how quickly exposure can become urgent: exploitation can begin before disclosure, and suspicious activity can reach production within minutes. As new indicators and security updates arrive, teams need to revisit earlier findings rather than rely on a one-time check.

Exaforce was built for moments like these. Automated hunts assess customer environments as new intelligence arrives, while our MDR team investigates findings, checks evidence, and provides clear remediation guidance. This combination of automation and human judgment helps customers respond as threats change, with a platform that proactively checks for impact and a team that explains what findings mean and what to do next.

Get a demo to see Exaforce threat hunting in action.