Supply Chain Attacks in October 2026: 15 Incidents, 3 Patterns

What Is a Supply Chain Attack?

A supply chain attack reaches you through something you depend on instead of through your own code: a package, a build pipeline, a vendor's download, or a platform that keeps your secrets. Nothing in your repository has to be wrong.

Below are 15 incidents from October 2026 in three patterns: poisoned releases of real packages, platforms that leaked the secrets customers stored on them, and the certificates and runtimes everything else trusts. Sources are vendor reports, the security firms that investigated, or news reports quoting them.

Pattern 1: Real Packages, Poisoned Releases

These are the hardest to spot: the name and the source were genuine, but the release was bad.

Sources: LiteLLM, GMO Flatt Security, Socket, StepSecurity, and BleepingComputer on OVHcloud and Rank Math.

LiteLLM's attack-chain write-up shows how small the first step was. A config file committed to a public repository on 27 May held the master key for the LiteLLM Agent Platform, and the key was never revoked. On 10 October the attacker used it to pull an organisation owner's GitHub CLI token, then used CI workflows to collect two more maintainers' tokens. The release approval rule had also been relaxed that week, so any two engineers could trigger and approve a release.

OVHcloud's cause was just as ordinary. Its CEO said GitHub's release immutability setting was off, so an account with enough rights could change existing releases without going through CI.

Pattern 2: Platforms That Hold Your Secrets

Here you stored keys on a service, and the service was breached.

Sources: Zeabur, Railway, Infosecurity Magazine on OpenCode, and BleepingComputer on TeamUpdraft and ConnectWise.

Railway believes its incident is part of a series of attacks on platform companies aimed at AI inference providers. OpenCode's leak was AI provider keys, and StepSecurity lists Anthropic, OpenAI and OpenRouter keys among what GhostAction collected. If you keep AI provider keys on a hosting platform, rotate them first.

Pattern 3: The Trust Layer Itself

• eMudhra: eight of its intermediate certificate authority keys were so weak they could be worked out, letting someone issue certificates for websites they do not control. Browsers blocked them. Our eMudhra guide shows how to check your certificate.
• Tailscale was not breached. Its bulletin TS-2026-013 of 21 October says v1.104.2 or later distrusts the eMudhra certificates even if they are still in the system store.
• PHP2Shell: on 21 October PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fixed CVE-2026-109618 and CVE-2026-109619, which can let an attacker run code on a server without logging in. See our PHP2Shell guide.
• Node.js was not attacked either. Its scheduled security release on 21 October fixed 10 CVEs, 4 rated high, in v26.12.1, v24.22.1 and v22.23.4. CVE-2026-111497 in the Brotli decoder can lead to remote code execution if your app decompresses attacker-supplied Brotli data with node:zlib.

Were You Affected? How to Check

Start with what is installed now, then check CI logs and image build history, because a later rebuild can replace the bad version.

# Python: LiteLLM 1.107.0 is the bad version
pip show litellm | grep -i '^version'

# Docker: compare the digest with the one in LiteLLM's incident post
docker images --digests | grep -i litellm

# npm: bad versions are tensorlake 0.5.144 and @subql/common 5.8.3
npm ls tensorlake @subql/common

# GitHub Actions: every workflow file ever added, newest first
git log --diff-filter=A --name-only --format='%h %ad' -- .github/workflows

GhostAction committed under real maintainers' names, so judge each workflow file, not who added it. StepSecurity also suggests a GitHub code search for "193.32.204.199" path:.github/workflows across your organisation, forks included. On WordPress, check your Rank Math PRO version and your UpdraftCentral connection keys.

If a bad version ran, removing it is not enough. LiteLLM says any Python start in an affected environment re-runs the malicious files. Socket warns that revoking the stolen GitHub token while tensorlake's gh-token-monitor is running can wipe your home directory. Follow each vendor's clean-up steps, rebuild the machine or image, then replace every key it could reach.

How to Fix It: Make the Next One Cheaper

You cannot audit every maintainer or platform, but you can limit how far one bad release or one leaked key travels.

Pin exact versions and commit the lockfile. A loose version lets the next install pick up whatever was published an hour ago.

# BAD: no fixed version, so the next install takes whatever is newest
# requirements.txt
litellm

# package.json
"tensorlake": "latest"

# GOOD: exact pins with pip's hash-checking mode.
# It needs every dependency, indirect ones too, pinned with a hash,
# so generate requirements.txt with a lock tool.
litellm==1.106.2 \
    --hash=sha256:<hash from your lock tool>

pip install --require-hashes -r requirements.txt

# npm: install exactly what package-lock.json says
npm ci

A pin does not help if you already pinned the bad version. A hash recorded before the swap does catch a file replaced inside an existing release, which is what OVHcloud's attacker did.

Turn off install scripts where you can. Setting ignore-scripts=true in .npmrc stops npm running scripts in package.json files, which would have blocked tensorlake's preinstall hook. It does not stop code that runs on import.

Lock down your own releases. If you publish packages or binaries, turn on GitHub's release immutability setting, which OVHcloud had off, and keep release approval strict. LiteLLM's had been relaxed the week it was attacked.

Know where every secret lives. When a platform you use is breached, the slow part is remembering what you stored there. Keep a list of each key, where it is stored and where to revoke it, and prefer keys that expire and have narrow permissions. Then scan your code: LiteLLM's chain started with one key in a public repository.

Tools like VibeDoctor's Vibe Check (vibedoctor.io) automatically scan your codebase with Gitleaks and their own secret checks. They also flag *, latest and open >= versions in package.json, unpinned lines in requirements.txt, and a missing lockfile. Free to sign up. The scan's package checks look for imports that do not exist, brand-new packages and likely typos of popular names. They are not built to detect a poisoned release of an established package like LiteLLM 1.107.0, so the steps above still apply.

FAQ