PHP2Shell, LiteLLM, and GitLab: The Race to Identify and Patch

---

Date: October 26, 2026 | Author: Cloud Sleuth | Read Time: $\approx 11$ minutes

Between October 16 and 23, 2026, the cybersecurity landscape was hit by a barrage of critical incidents affecting PHP, Node.js, GitLab, LiteLLM, OpenCode, and the eMudhra certificate authority. While patches for PHP, Node.js, and GitLab were released on October 21, that same day saw the rollout of a compromised LiteLLM version.

The standard advice for every single one of these advisories was the same: upgrade, rebuild, or rotate. However, the actual challenge isn't the act of patching—it's the discovery phase. Organizations struggle to determine exactly where these assets are running, who owns them, and what their blast radius is. Without a real-time inventory, security becomes a chaotic series of Slack threads.

🚨 The Week's Security Incidents

The following table summarizes the chaos of the past week:

---

📉 The Shrinking Exploit Window

The time between the disclosure of a vulnerability and its active exploitation is collapsing. Mandiant's historical data illustrates this trend:

• 2018–2019: $\approx 63$ days
• 2020–2021: $\approx 44$ days
• 2021–2022: $\approx 32$ days
• 2023: $\approx 5$ days (with $70\%$ being zero-days)

Recent analysis suggests that Large Language Models (LLMs) have accelerated this further. The gap between a public RCE disclosure and automated attacks is now measured in hours. In this week's events, AI helped find the bugs, and exploit attempts began before most admins could even download the patch.

The Exposure Window = (Time to Find Affected Assets) + (Time to Fix)

While CI/CD and managed runtimes have minimized the "Time to Fix," the "Time to Find" is still plagued by spreadsheets and tribal knowledge.

Compliance and Standards

• CIS Controls: Asset inventory (Controls 1 & 2) must precede vulnerability management (Control 7).
• CISA BOD 23-01: Mandates US federal agencies perform:
  • Automated asset discovery every $\text{7 days}$.
  • Vulnerability enumeration every $\text{14 days}$.

---

🛠️ Practical Discovery: Using Native Tools

If you are managing a large estate on AWS or Azure, you can use native tools to hunt for these vulnerabilities.

Example: Hunting Node.js in AWS Lambda

Managed runtimes usually update automatically. However, there are two danger zones:

1. Deprecated Runtimes: nodejs20.x stopped receiving security updates in April 2026.
2. Container Images: These are static; you must rebuild them to update the Node.js version.

To identify these, you can run the following script:

# Find Node.js and container-image Lambda functions across all enabled regions
for region in $( aws ec2 describe-regions --query "Regions[].RegionName" --output text ); do 
  echo "== $region " 
  aws lambda list-functions --region "$region" \
    --query "Functions[?PackageType=='Image' || (Runtime && starts_with(Runtime, 'nodejs'))].[FunctionName, Runtime || PackageType]" \
    --output text 
done

Note: Because the Lambda API cannot "see" inside a container image, all image-based functions are flagged for manual review.

Example: PHP2Shell on Azure

For PHP vulnerabilities, Azure App Service provides the runtime stack for each Linux app, allowing admins to filter for outdated PHP versions.

---

❓ Frequently Asked Questions

$\square$ Was my AWS Lambda function affected by the Node.js Brotli vulnerability?

It depends on your deployment method. If you used a managed runtime that is still supported, AWS likely patched it automatically. If you used nodejs20.x (EOL April 2026) or a custom container image, you are likely vulnerable.

$\square$ What should I do if an environment installed LiteLLM 1.107.0?

1. Isolate: Immediately stop the affected environment.
2. Rebuild: Deploy a known-good version of LiteLLM.
3. Rotate: Assume all credentials accessible to that environment's identity (IAM roles, API keys) have been stolen and rotate them immediately.

$\square$ How does Cloud Sleuth help when a new vulnerability is announced?

Cloud Sleuth eliminates the "Time to Find" by providing a real-time, searchable inventory of your cloud assets, allowing you to identify affected versions across accounts and regions in seconds rather than days.

Patching Checklist:

• Identify all affected assets (Containers, VMs, Serverless).
• Determine ownership and blast radius.
• Apply patches/updates.
• Rotate compromised secrets (if applicable).
• Verify the fix via scanning.