Black October 2026 Triage Playbook: How to Check Your Exposure to PHP2Shell, LiteLLM and eMudhra

New to PHP2Shell? Start here. This playbook is a companion to our deep dive, PHP2Shell: A Patch Plan for Two Critical PHP Vulnerabilities. It covers what PHP fixed, how to patch every runtime and what to do if you cannot update today. Read it first, then come back here to triage everything else that surfaced the same week.

Short Answer

“Black October” is the informal name for a cluster of separate security disclosures that became public between October 19 and 22, 2026. Coverage that checked the claim found no evidence the incidents were coordinated. The useful question is which of them touch your estate: PHP2Shell, the malicious LiteLLM 1.107.0 release, the eMudhra certificate authority keys, and the Node.js Brotli and GitLab fixes.

Key Takeaways

• Use the 60-second triage below to see what touches you, then work each item with the same four questions: exposure, window, reach and proof.
• LiteLLM and eMudhra risk sits in lockfiles, CI logs, trust stores and long-lived secrets, so the checks differ from a normal patch.
• Most of the triage can be automated, with humans approving anything that changes production.

Am I Affected? A 60-Second Triage

If you run or use…	What to know	What to do
PHP on any web-serving runtime (PHP2Shell, CVE-2026-109618 and CVE-2026-109619)	Fixed on October 21 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official fixes (see the 8.1 end-of-life guidance in our patch plan). PHP advisory	Patch every runtime, including containers and vendor-bundled copies; restart and verify; review logs back to October 17
LiteLLM (litellm==1.107.0)	Live on PyPI 11:39 to 13:23 UTC, on Docker Hub 11:46 to 14:20 UTC, and pulled from GitHub Container Registry by 13:51 UTC on October 21 (incident report)	Check lockfiles, CI logs and registry pulls. Do not just uninstall, and do not run pip first. Rebuild and rotate everything the host could reach
Certificates chaining to the eMudhra root (emSign ECC Root CA - G3)	Google and Mozilla removed the root as a precaution. Chrome’s removal was due on October 27 (Google)	Inspect certificate chains, reissue affected certificates and update trust stores in operating systems, runtimes and images
Node.js (Brotli, CVE-2026-111497)	Fixed October 21 in 22.23.4, 24.22.1 and 26.12.1. Node.js 20 and older get no fix (Node.js advisory)	Update Node.js and check other tools that bundle Brotli
Self-managed GitLab (CVE-2026-110264)	CVSS 10.0, fixed October 21 in seven releases (GitLab release post). Servers patched on October 12 are still exposed	Upgrade to the fixed release for your branch
Any platform named in a vendor breach notice	Some vendors, such as Railway, asked all customers to rotate secrets	Rotate secrets on any tool that named an incident, most sensitive first

Triage Any Disclosure With Four Questions

Incident names change. The method does not. Answer these four for every disclosure and keep the evidence in the ticket.

Question	What you are working out	Evidence to record
1. Exposure: do we run it, where and which version?	Affected systems	Inventory export, lockfile matches, image digests
2. Window: when was it exploitable, and when were we exposed?	Time range to investigate	Release windows, deploy and pull timestamps
3. Reach: what could it touch if it ran?	Blast radius	Credentials reachable from the host, CI role permissions
4. Proof: what shows we are clean or compromised?	A defensible conclusion	Log queries, file checks, rebuild records

Then act, verify and record. Treat the window carefully: the day a disclosure goes public is not the day attacks began. See why the patch window has shrunk for how that gap has changed.

PHP2Shell: Confirm It Is Closed Across Your Estate

Our patch plan covers fixed versions, temporary measures and signs of compromise. After patching, use this checklist:

1. Compare patched runtimes to your inventory, not to your memory. Anything missing is where the next incident starts.
2. Check software that bundles PHP. The NCSC-NL repository lists affected vendor products, and CERT-EU advisory 2026-018 points to it.
3. Check Windows PHP builds. PHP’s October 26 notice says Windows builds were rebuilt with a fixed Brotli, because the decoder can be reached through cURL when automatic decompression is on. See PHP’s notices.
4. Close the loop on logs. Record the date range you reviewed and the result.

If a system cannot be patched today, CISA and the NSA both advised taking it offline until it can be. CERT-EU’s October 23 update also flags a third PHP vulnerability, CVE-2026-115560, with no public detail yet, so recheck the advisory.

LiteLLM 1.107.0: How to Check and Clean Up Safely

LiteLLM’s incident report gives the exposure windows in the triage table. Wiz describes a credential stealer targeting browser, cloud and AI secrets, and saw stolen AWS role credentials tested about 4.5 hours after exfiltration. The sequence below checks for exposure without running anything that could execute the payload.

Step 1: search source and lockfiles (no Python or pip).

# Requirements-style pins across a repo or monorepo
grep -rn "litellm==1.107.0" --include="requirements*.txt" --include="*.in" .

# poetry.lock and uv.lock: show the version line after each litellm entry
grep -rn -A1 'name = "litellm"' --include="poetry.lock" --include="uv.lock" .

Step 2: check CI and registry logs for installs or image pulls inside the windows, including unpinned pip install litellm steps and images tagged latest.

Step 3: if it ran, do not start with pip install. LiteLLM warns that any Python start in an affected environment, pip included, re-runs the payload, so uninstalling the package does not clean the host. Delete the dropped files first without launching Python, then rebuild environments from scratch. The file list is in the incident report.

Step 4: rotate by reach, not by suspicion. Start with anything the host could read: cloud keys, AI provider keys, CI secrets, tokens and environment files.

Make the Next Poisoned Release a Non-Event

The PyPI package was live for under two hours, but container tags stayed compromised until 14:20 UTC. A short delay on new versions would have avoided the PyPI window. That is our inference, and LiteLLM does not claim it.

// renovate.json: wait a day before adopting a brand-new release
{
  "packageRules": [
    { "matchDatasources": ["pypi", "npm"], "minimumReleaseAge": "1 day" }
  ]
}

• Pin and verify: pin exact versions, use pip install --require-hashes, and pin container images by digest, not by tag.
• Bind publishing to the exact source: in LiteLLM’s corrected attack chain, the release workflow was repointed at a lookalike fork. Tie trusted publishing to the exact repository, workflow and environment.
• Keep approvals on: LiteLLM notes a strict release approval had been relaxed that week. Track any relaxation with an expiry.

eMudhra: How to Check Certificates and Trust Stores

Google reports that eight intermediate certificates (six for TLS, two for code signing) under the emSign ECC Root CA - G3 were blocked, and that Google and Mozilla removed the root as a precaution. Chrome’s removal was due to reach devices on the morning of October 27, Pacific time, so treat chains to this root as already failing in current Chrome.

Step 1: find certificates that chain to the root.

# Replace example.com with each public hostname you operate
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | grep -i -E "emsign|emudhra"

No output means the presented chain does not mention eMudhra. Any match means reissue from another certificate authority.

Step 2: scan the places certificates hide: load balancers, CDNs, API gateways, internal services, code-signing pipelines and partner endpoints.

Step 3: update trust stores, not only browsers. Operating systems, runtimes, container base images and tools with their own certificate lists all need it. Go, Mozilla’s NSS, Python tooling, Java and Linux distributions have shipped updates.

Step 4: rebuild images from updated bases so old trust stores do not linger.

Node.js Brotli and GitLab: Quick Checks

Node.js. CVE-2026-111497 is an out-of-bounds write in the bundled Brotli decoder. Check what you run:

node -v
node -p "process.versions.brotli"   # the Brotli version bundled with this build

The fixed versions are 22.23.4, 24.22.1 and 26.12.1. The proofs of concept arrived in two steps. A first public one on October 22 mostly crashed the process, and the same day Imperva showed code execution on the official Node.js 24.22.0 Linux arm64 image, needing several attempts. Imperva named it Node2Shell; Aikido’s write-up shows it also circulating as HTTP2Shell. Both names mean the same CVE. Other software that bundles Brotli needs library versions 1.0.10, 1.1.1 or 1.2.1.

GitLab. CVE-2026-110264 is an integer overflow in GitLab’s regular expression compiler that can give an unauthenticated attacker code execution. It affects self-managed CE and EE from 7.0, and GitLab.com is already patched. The fixed releases are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Third-party analysis traces the entry point to rendering an .org file. Servers patched on October 12 for CVE-2026-97229 are still exposed, so upgrade again.

Which Secrets to Rotate First

Rotation stalls because nobody knows what is reachable. Order the work by reach:

Priority	Credential type	Why first
1	Anything readable by an affected host or process	Direct exposure
2	Owner-level and admin tokens, especially in automation	One token unlocks everything
3	CI/CD and release-pipeline secrets	They can publish software under your name
4	Long-lived keys with no expiry or owner	Hardest to reason about
5	Credentials for any platform that named an incident	Some vendors, such as Railway, asked all customers to rotate

Keep a secrets register (credential, owner, scope, created, expiry, location). It is the credential-side twin of the PHP runtime inventory.

Automating Triage With Agentic Workflows

Most of this work is repetitive: read an advisory, extract versions and windows, match them to inventory, open tickets and record evidence. Agentic automation earns its place here, as long as it stays bounded.

triage_agent:
  mode: read_only              # reads inventory and advisories, writes tickets
  grounded_in: [primary advisories, lockfiles, registry, cert scans, secrets register]
  requires_human_approval: [patch_production, rotate_secret, revoke_token, take_offline]
  never: [run_python_or_pip_on_suspected_host]   # encodes LiteLLM's cleanup guidance
  audit_log: every_step

Automate: parsing advisories into affected-version records, searching lockfiles and certificate chains, producing evidence reports, chasing tickets and re-checking after the fix.

Keep human-approved: patching production, rotating or revoking credentials, taking a service offline, declaring an incident closed and speaking to customers or regulators.

A Seven-Day Readiness Plan

Day	Focus	Output
1	Inventory PHP runtimes, container bases and dependencies	One list with an owner per item
2	Patch and restart PHP and Node.js; verify what serves requests	Verified versions, recorded
3	LiteLLM check across lockfiles, CI and registry logs	Clean or exposed, with evidence
4	Certificate and trust-store review	Reissue list; updated stores and images
5	Secrets register and priority rotation	Rotation log with owners and expiry
6	Automate the repeatable checks	Scheduled scans and ticket creation
7	Assign standing owners	Runbook and on-call route for the next notice

The Rule to Adopt

Ask the same four questions of every disclosure: exposure, window, reach and proof. Record the evidence, automate the checks, and let a human approve anything that changes production. A team that already works this way spends its first hour on answers, not on deciding where to start.

How Incresco Can Help

Incresco is a Claude and Storyblok partner. We build and maintain PHP and Laravel applications, cloud systems and AI agents. For Black October, we can help you:

• Run the triage with you: inventory, exposure checks and evidence for PHP2Shell, LiteLLM, eMudhra, Node.js and GitLab.
• Close the gaps: patch and verify runtimes and containers, update trust stores and rotate secrets in priority order, through our cloud and DevOps and custom platform development teams.
• Build the automation: agentic triage workflows grounded in your inventory, with approval gates and audit logs, through our AI transformation practice.

Your Free 30-Minute Discovery Call: The Journey

The call is a working session built around your stack, with an Incresco engineer from our PHP, cloud and agentic automation work.

Step	What happens	What you get
1. We listen first (about 5 minutes)	We learn what you run, how your team ships and patches, and what worries you most about the October disclosures	A shared picture of your setup and priorities, in your words
2. We walk through your estate (about 10 minutes)	We take you through exposure, window, reach and proof for PHP2Shell, LiteLLM, eMudhra, Node.js and GitLab, using your runtimes, pipelines, certificates and secrets	A clear view of what is in scope and where the biggest risks sit
3. We work a live example (about 10 minutes)	We take your highest-risk item and work it through: the check to run, the evidence to keep, the fix order and where automation would take over	A concrete triage outline you can act on right away
4. We agree the way forward (about 5 minutes)	We recommend what to do first, who owns each step, and whether automation is worth building now	A short, prioritized plan, yours to keep with no obligation

What to bring (optional): a rough list of runtimes, pipelines, public certificates and where secrets live. With nothing prepared, we start from scratch together.

Book a Free 30-Minute Discovery Call

Frequently Asked Questions

What Is Black October 2026?

An informal label for a cluster of security disclosures made public between October 19 and 22, 2026. It is not a CVE or an agency advisory title. The incidents were separate, and no coverage we reviewed shows coordination.

Does Black October 2026 Affect My Systems?

Possibly, if you run PHP web services, Node.js, self-managed GitLab, LiteLLM or certificates that chain to the eMudhra root. Use the triage table above and record the evidence for each answer.

Where Do I Start With PHP2Shell?

Start with our patch plan, then use the checklist here to confirm the whole estate is covered.

How Do I Check Whether I Installed LiteLLM 1.107.0?

Search lockfiles with the grep commands above, then review CI and registry pull logs against the published windows. Do not launch Python or pip on a host you suspect ran it.

Can an AI Agent Handle Security Triage?

It can handle the repetitive parts: reading advisories, matching versions, producing evidence and opening tickets. Keep a human approval gate on anything that changes production.

Related Articles

• PHP2Shell: A Patch Plan for Two Critical PHP Vulnerabilities
• Your API’s Next User Is a Model: Agent Experience (AX) for Engineers

Sources: PHP security advisory; CERT-EU 2026-018; NCSC-NL php2shell; SecureWorld; LiteLLM incident report; Wiz; Google Chrome and Android Security; Node.js; Sysdig; Aikido; Tanium; GitLab; SecurityToday.