Supply Chain Watch

Weekly digest·3 days logged · 9 watches

Week 43 · Oct 19–25, 2026

The week was dominated by runtime and infrastructure bugs rather than package malware: PHP2Shell is under active attack with at least one reported intrusion, and the Brotli decoder flaw behind Node2Shell spread to Python, Bun, Envoy and curl builds. LiteLLM's poisoned 1.107.0 release on PyPI and Docker, the Railway build-platform breach and the eMudhra CA key compromise all called for secret rotation or trust-store updates. PHP2Shell and the Brotli bug remain open; LiteLLM, GitLab, eMudhra, Railway and Wasmtime have fixes. The common thread is stolen CI and platform credentials, plus runtimes and trust stores that need patching beyond browsers.

21 entries7 critical6 high6 medium2 context

By severity

Critical7
High6
Medium6
Context2

By ecosystem

PyPI9
Runtimes9
npm7
Packagist4
Docker3
Dev infrastructure3
crates.io3
AI models2

Threats tracked this week

Critical and high this week

  1. CriticalFix available · timelineCompromised release · PyPI · Docker · AI modelsOct 23 · 22:45 ET

    LiteLLM 1.107.0 shipped a credential stealer on PyPI and in its Docker images

    On Oct 21 a release built from a lookalike repository pushed backdoored litellm 1.107.0 wheels to PyPI and matching images to GHCR and Docker Hub. The payload runs on every Python start via a .pth file, harvests cloud, CI, SSH and AI-tool credentials (and proxy provider keys when DATABASE_URL is set), and polls for remote code hourly. PyPI pulled the release in under two hours; the latest and main-stable Docker tags pointed at the bad image for roughly 2.5 hours. Researchers report the 1.106.x line as clean.

    litellm==1.107.0ghcr.io/berriai/litellm:v1.107.0docker.io/litellm/litellm:v1.107.0
    Am I affected?
    Installed versionpip show litellm 2>/dev/null | grep -i '^version'
    Lockfiles and requirementsgrep -rnE 'litellm.{0,4}1\.107\.0' --include='*.txt' --include='*.lock' --include='*.toml' --include='*.cfg' .
    Backdoor files on diskfind / -path '*site-packages*' \( -name cook.pth -o -name cook.py \) 2>/dev/null
    Container imagesdocker images --digests | grep -i litellm
    What to do

    Search lockfiles, image digests and mirrors for 1.107.0. If it ran anywhere with network access, rebuild that environment, pin litellm==1.106.2, block litellm.dev, and rotate every credential the host could reach.

  2. CriticalFix available · timelineVulnerability · Dev infrastructure · RubyGems · RuntimesOct 23 · 22:45 ET

    GitLab CVSS 10 RCE through Ruby's regex engine; Ruby ships matching fixes

    GitLab's Oct 21 critical patch release fixes an unauthenticated remote code execution bug triggered by a crafted Org-mode file, rooted in an integer overflow in Onigmo, the regex engine inside Ruby. Fixed GitLab versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13; GitLab.com is already patched. On Oct 23 the Ruby team released 4.0.9, 3.4.12 and 3.3.13 with fixes for the underlying regex bugs. It is not in CISA KEV yet, but public repositories claiming proofs of concept have appeared.

    GitLab CE/EE < 19.5.1ruby < 4.0.9 / 3.4.12 / 3.3.13
    Am I affected?
    GitLab version (Omnibus)cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
    Ruby versionruby -v
    What to do

    Upgrade self-managed GitLab now (older than 18.11 means following upgrade stops to 18.11.13 or later). Update Ruby on self-compiled installs and on any service that compiles regexes from untrusted input.

    ReferencesCVE-2026-110264

    SourcesKonfirmity, Convika, ruby-lang.org

  3. CriticalFix available · timelineVulnerability · Runtimes · npmOct 23 · 22:45 ET · updated 23:05

    Node.js Brotli bug (Node2Shell) shown to run code on an official build; patch to 24.22.1 and peers

    Node's Oct 21 security release fixed 10 CVEs across the 22.x, 24.x and 26.x lines. The worst, an out-of-bounds write in the bundled Brotli decoder, is no longer theoretical: on Oct 23 Imperva reported code execution on the official Node.js 24.22.0 Linux arm64 build, including through Express 5.0-5.3 and body-parser 2.0-2.3 request handling, though not on every attempt. Three high-severity TLS and DNS bugs in the same release let certificates match the wrong host or let a NUL byte truncate a hostname. No in-the-wild exploitation reported yet; Node 20.x and older are end-of-life and get no fix.

    node 26.12.1node 24.22.1node 22.23.4
    Am I affected?
    Local Node versionnode -v
    Node base imagesdocker images --format '{{.Repository}}:{{.Tag}}' | grep -E '(^|/)node:'
    Pinned versions in repogrep -rnE '(node-version|FROM node|"node":)' --include='*.yml' --include='*.yaml' --include='Dockerfile*' --include='package.json' --include='.nvmrc' .
    What to do

    Move to 26.12.1, 24.22.1 or 22.23.4 everywhere, including base images, CI runners and serverless runtimes; replace any Node 20.x. Until then, limit untrusted Brotli traffic at the edge.

  4. CriticalPublic exploitActive · timelineVulnerability · Runtimes · PackagistOct 23 · 23:05 ET

    PHP2Shell: unauthenticated RCE in PHP is under mass exploitation; emergency fixes out since Oct 21

    PHP shipped emergency releases on Oct 21 for two critical flaws that let an attacker without an account run code on a server. Exploit attempts reported since then number in the millions, with attackers trying to install Mirai botnet malware. On Oct 23 PHP flagged a separate, lower-risk session issue that the emergency builds do not fix; it only affects unusual session-handler configurations.

    php < 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
    Am I affected?
    PHP versionphp -v | head -1
    Stopgap setting in effectphp -i | grep session.upload_progress.enabled
    PHP base imagesdocker images --format '{{.Repository}}:{{.Tag}}' | grep -E '(^|/)php:'
    What to do

    Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, including container base images. As a stopgap (and to cover the Oct 23 issue), set session.upload_progress.enabled=0.

  5. CriticalPublic exploitActive · timelineVulnerability · PyPI · Runtimes · Dev infrastructure · OtherOct 24 · 06:08 ET · updated 17:53

    Update: Node2Shell's Brotli bug reaches Python, Bun, Envoy and curl builds, now dubbed HTTP2Shell

    CVE-2026-111497 sits in Google's Brotli C decoder (versions 1.0.3 to 1.2.0), not only in Node.js, so anything that decodes untrusted Brotli data with a bundled or linked copy is exposed. On Oct 23-24 researchers confirmed the PyPI packages Brotli (fixed in 1.2.1) and brotlicffi (fixed in 1.2.1.0) are affected; urllib3/requests, httpx, aiohttp and Scrapy load them automatically when installed and will decode br responses. Bun 1.4.4, Envoy 1.40.0/1.39.3/1.38.6/1.37.8 and Istio 1.29.9/1.30.6/1.31.2 carry the fix; libcurl and Git for Windows builds linking Brotli 1.2.0 are also in scope. Bundled copies in the .NET runtime, the PHP brotli extension, the Ruby brotli gem, DuckDB, ClickHouse and Apache Arrow were still listed as unpatched on Oct 24. Upstream Brotli fixes are 1.0.10, 1.1.1 and 1.2.1, Debian 13 ships 1.1.0-2+deb13u1, and the cdxgen SBOM tool is fixed in 12.8.9 and 13.5.0. Public proof-of-concept code reportedly crashes stock builds; code execution has only been shown in Imperva's lab on an official Node.js 24.22.0 arm64 build and that exploit is unreleased. No in-the-wild exploitation is confirmed, and GitHub's advisory did not list the PyPI packages on Oct 23, so Dependabot may not flag them.

    Brotli < 1.2.1brotlicffi < 1.2.1.0bun < 1.4.4envoy < 1.37.8 / 1.38.6 / 1.39.3 / 1.40.0istio < 1.29.9 / 1.30.6 / 1.31.2libbrotli 1.0.3-1.2.0cdxgen < 12.8.9 / 13.5.0
    Am I affected?
    Python Brotli packagespip show Brotli brotlicffi 2>/dev/null | grep -E '^(Name|Version)'
    Brotli in Python lockfilesgrep -rniE '^"?(brotli|brotlicffi)\b' --include='requirements*.txt' --include='poetry.lock' --include='uv.lock' --include='Pipfile.lock' --include='pyproject.toml' .
    Bun and Envoy versionsbun --version 2>/dev/null; envoy --version 2>/dev/null | head -1
    Ruby brotli gembundle list 2>/dev/null | grep -i brotli
    What to do

    Upgrade Brotli to 1.2.1 and brotlicffi to 1.2.1.0 in every Python environment and image, update Bun, Envoy/Istio and OS libbrotli packages, then rebuild images and bundled binaries. Where you cannot patch yet, reject Content-Encoding: br at the edge.

  6. CriticalPublic exploitActive · timelineVulnerability · Runtimes · PackagistOct 24 · 17:53 ET

    Update: PHP2Shell attacks continue but no confirmed break-ins yet; a private exploit now beats ASLR on hardened setups

    Two days into mass scanning for CVE-2026-109618 and CVE-2026-109619, no successful in-the-wild compromise has been confirmed: Sophos withdrew an earlier report of one, Wordfence and Hunt.io saw only failed attempts, and Sansec now says public exploits fail on default PHP settings. That window may not last. VulnCheck reports a working exploit for CVE-2026-109618 that leaks memory to defeat ASLR on x86-64 with error display off, the usual production setup; it is limited to its paying customers for now. Amazon's honeypots logged an attempt on Oct 17, four days before disclosure, so log reviews should start there. Fixed releases are unchanged (8.5.12, 8.4.27, 8.3.36, 8.2.35); PHP 8.1 and older get no fix, and neither CVE was in CISA KEV as of Oct 23.

    php < 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
    Am I affected?
    PHP versionphp -v | head -1
    PHP in Docker imagesdocker images --format '{{.Repository}}:{{.Tag}}' | grep -iE 'php|wordpress|laravel|drupal'
    Upload-progress probes in logsgrep -rl 'PHP_SESSION_UPLOAD_PROGRESS' /var/log/nginx /var/log/apache2 /var/log/httpd 2>/dev/null
    What to do

    Keep patching to the fixed PHP releases and rebuild PHP base images; for end-of-life PHP, block multipart uploads at the edge if you can, and hunt for POST bodies containing PHP_SESSION_UPLOAD_PROGRESS from Oct 17 onward.

  7. CriticalPublic exploitActive · timelineVulnerability · Runtimes · PackagistOct 25 · 12:05 ET · updated 17:57

    Update: Unit 42 describes a PHP2Shell-era intrusion that reached AD credentials within two hours

    Palo Alto Networks' Unit 42 updated its PHP2Shell threat brief (Oct 23, 12:30 PT) with a case in which attackers, apparently driven by an agentic AI platform, ran recon through a web shell at a European government body and obtained password hashes and MFA secrets within two hours of initial exploitation, then tried NTLM relay into Active Directory. The brief does not name the exact CVE used in that case, so treat it as strong but not definitive evidence that PHP2Shell has moved from attempts to real break-ins; our Oct 24 entry said none had been confirmed. Evening update: The Hacker News also reports that CYFIRMA tied a scanning campaign, with moderate confidence, to a suspected North Korea-linked actor probing 216 unpatched hosts in 12 countries (single source so far), and that ReliaQuest has published log artifacts for detection. Fixed PHP releases are unchanged (8.5.12, 8.4.27, 8.3.36, 8.2.35); a third flaw, CVE-2026-115560, still awaits a regular release, and neither main CVE was in CISA KEV as of this watch.

    php < 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
    Am I affected?
    PHP versionphp -v | head -1
    Recently changed PHP files in web rootsfind /var/www -name '*.php' -newermt 2026-10-17 2>/dev/null | head -50
    Upload-progress probes in logsgrep -rl 'PHP_SESSION_UPLOAD_PROGRESS' /var/log/nginx /var/log/apache2 /var/log/httpd 2>/dev/null
    What to do

    Assume unpatched internet-facing PHP may already be compromised: patch, then hunt for web shells and unexpected outbound connections from PHP hosts since Oct 17, and rotate credentials those hosts could reach.

  8. HighAdvisory · npmOct 23 · 22:45 ET · updated 23:05

    Electron distrusts compromised CA intermediates that allowed TLS impersonation

    eMudhra said on Oct 22 it will leave the global TLS certificate business after eight of its intermediate CA keys were found to be easily guessable. Electron published fixes that stop trusting the affected intermediates; until then, an attacker on the network holding a certificate from one of them could impersonate servers to Electron apps through Chromium networking or Node's tls, https and fetch. Rated CVSS 7.4; no known exploitation.

    electron 44.9.1electron 43.8.1electron 42.11.16electron 45.0.0-beta.6
    Am I affected?
    Electron version in a projectnpm ls electron
    What to do

    Bump electron to a fixed release for your major line and ship an app update, especially for apps that auto-update or call internal APIs over TLS.

  9. HighPublic exploitVulnerability · PyPIOct 23 · 23:05 ET

    Pillow 13.0.0 fixes image-parsing bugs rated up to CVSS 9.2, including command execution paths

    Pillow 13.0.0, released Oct 16, fixes several flaws now drawing attention: command execution through EPS files when Ghostscript is installed (versions 2.6.0 to 12.3.0), a crafted FPX file that can run commands on a single Image.open() when olefile is present, and memory overflows in lossless JPEG thumbnails and in-memory TIFF saves, the latter with a public proof of concept. The 9.2 scores overstate some of these, since each needs specific conditions; maintainers rate the EPS issue moderate. No exploitation reported.

    pillow < 13.0.0
    Am I affected?
    Installed versionpip show pillow 2>/dev/null | grep -i '^version'
    Requirements and lockfilesgrep -rniE '^pillow|name = "pillow"' --include='*.txt' --include='*.lock' --include='*.toml' -A1 .
    What to do

    Upgrade pillow to 13.0.0 (it requires Python 3.11+). If you can't yet, avoid opening untrusted EPS/FPX files, and remove ghostscript and olefile from images that don't need them.

  10. HighFix available · timelineAdvisory · PyPI · npm · Go · crates.io · Packagist · Runtimes · DockerOct 24 · 17:53 ET

    eMudhra CA key compromise: certifi, pip, uv, Node.js, Go and Rust trust stores need updating, not just browsers

    The eight eMudhra intermediate CA keys disclosed on Oct 20 were generated so weakly that anyone can recover them, which means a network attacker could mint certificates those intermediates sign; exposure dates back to April 2025, though no misuse has been found. Browsers block them already, but package managers, CI jobs and API clients that carry their own CA bundle keep trusting the chain until updated. Fixed bundles: certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Node.js 22.23.4/24.22.1/26.12.1, Go 1.27.3/1.26.10, rustls-webpki 0.103.16, webpki-roots 1.0.10, composer/ca-bundle 1.4.16/1.6.0, plus Ubuntu, Debian, Alpine, Fedora and Wolfi ca-certificates. Bun, FreeBSD and Java's JDK cacerts were still unfixed or unconfirmed on Oct 23, and container images keep the old roots until rebuilt.

    certifi < 2026.10.19pip < 26.2.2uv < 0.13.4node < 22.23.4 / 24.22.1 / 26.12.1go < 1.27.3 / 1.26.10webpki-roots < 1.0.10rustls-webpki < 0.103.16composer/ca-bundle < 1.4.16ca-certificates (distro)
    Am I affected?
    certifi and pip versionspip show certifi pip 2>/dev/null | grep -E '^(Name|Version)'
    emSign roots in certifi bundlegrep -c 'emSign' "$(python3 -m certifi)"
    emSign roots in system bundlegrep -c 'emSign' /etc/ssl/certs/ca-certificates.crt
    Runtime and Rust crate versionsnode -v; go version; uv --version; grep -A1 -E 'name = "(webpki-roots|rustls-webpki)"' Cargo.lock 2>/dev/null
    What to do

    Bump certifi, pip, uv, Node.js, Go and Rust webpki crates to the fixed versions, rebuild container images on patched base images, and check Java and Bun services separately; the system bundle should contain no emSign entries after updating.

  11. HighFix available · timelineCompromised release · Dev infrastructureOct 24 · 20:56 ET

    Railway build-infrastructure breach exposed decrypted customer env vars and CI credentials; rotate secrets

    Deployment platform Railway says an attacker escalated privileges through its build infrastructure on Oct 20-21, pulled encrypted customer environment variables, decrypted a subset, and obtained credentials for Railway's own CI environment. Its preliminary report puts potentially exposed environment variables at no more than 1.85% of workspaces, but it asked all users to rotate keys and sent AI providers broad key-revocation lists. Railway says the attacker was hunting AI provider API keys and that access was cut off by Oct 22; builds and deployments, paused during triage, were restored later that day, though commits pushed during the pause were not deployed. The entry point is not yet disclosed and a full report is pending; TechCrunch notes OpenCode reported a similar key-theft breach the same week.

    railway (deploy platform)
    Am I affected?
    Railway config in this repols railway.json railway.toml nixpacks.toml 2>/dev/null
    Railway tokens referenced in CIgrep -rnE 'RAILWAY_(TOKEN|API_TOKEN)' .github/workflows .gitlab-ci.yml .circleci 2>/dev/null
    Railway CLI version and loginrailway --version 2>/dev/null; ls ~/.railway 2>/dev/null
    What to do

    Rotate every secret stored in Railway (API, database, cloud and registry credentials), recreate Railway CLI and CI tokens, redeploy the latest commit, and review GitHub, Docker Hub and AI provider audit logs for use since Oct 20.

  12. HighFix available · timelineVulnerability · crates.io · RuntimesOct 25 · 12:05 ET

    Wasmtime sandbox escape on aarch64 via huge br_table (CVSS 9.9); fixed in 36.0.19, 48.0.7, 49.0.4

    CVE-2026-115893 (GHSA-mghf-wjfp-p5xm, RUSTSEC-2026-0379), published Oct 23, is a Cranelift code-generation bug on 64-bit Arm: a Wasm br_table with roughly 256,000 or more targets can compile to a wrong jump target, letting a guest module escape the sandbox. It matters to anyone running untrusted WebAssembly with Wasmtime on aarch64, such as plugin hosts and edge or serverless platforms; x86-64 is not named as affected. Fixed releases are 36.0.19, 48.0.7 and 49.0.4, which also roll up several smaller wasmtime-wasi fixes including a symlink-rename filesystem escape (RUSTSEC-2026-0352). A related truncation bug, CVE-2026-115889, is fixed in 36.0.19 and 43.0.0. No public exploit or in-the-wild use is reported.

    wasmtime < 36.0.19 / 48.0.7 / 49.0.4
    Am I affected?
    wasmtime in Cargo.lockgrep -A1 -E '^name = "wasmtime(-wasi)?"' Cargo.lock
    wasmtime CLI versionwasmtime --version
    Host architectureuname -m
    What to do

    Bump wasmtime (and wasmtime-wasi) to 36.0.19, 48.0.7, 49.0.4 or later wherever you run untrusted Wasm, prioritising Arm hosts.

    ReferencesCVE-2026-115893, GHSA-mghf-wjfp-p5xm, RUSTSEC-2026-0379, CVE-2026-115889

    SourcesTheHackerWire, CVE Brief

  13. HighFix available · timelineAdvisory · Runtimes · PyPIOct 25 · 20:52 ET

    Update: Oracle ships an out-of-band Java fix for the eMudhra roots; CPython assigns CVE-2026-115557, fix not yet released

    Oracle published a Security Alert on Oct 24 (CVE-2026-114820, CVSS 9.1) whose Java updates remove the affected eMudhra root CA certificates from the JDK trust store; listed as affected are Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1, GraalVM for JDK 17.0.21 and 21.0.13, and GraalVM Enterprise 21.3.20. Oracle's page does not list fixed version numbers and points to its patch availability note and an eMudhra page instead, so check your vendor's build notes. Separately, CPython assigned CVE-2026-115557 (CVSS 9.4) for a defense-in-depth denylist in the ssl module that rejects any chain containing a compromised eMudhra intermediate key; the pull request is approved and marked as a release blocker with backports requested to 3.11-3.15, but it was not merged as of this watch. One aggregator claims a public proof of concept exists for the Java issue; we could not confirm that.

    java (Oracle Java SE 8u511 / 11.0.33 / 17.0.21 / 21.0.13 / 25.0.5 / 27.0.1)graalvm (for JDK 17.0.21 / 21.0.13, Enterprise 21.3.20)python < 3.16.0 (ssl denylist pending)
    Am I affected?
    Java version in usejava -version 2>&1 | head -2
    eMudhra roots still in the JDK trust storekeytool -list -cacerts -storepass changeit 2>/dev/null | grep -i -A1 emudhra
    Python and certifi versionspython3 --version; pip show certifi 2>/dev/null | grep -i '^version'
    What to do

    Apply Oracle's Oct 24 Java update (or your JDK vendor's equivalent) on hosts that make TLS connections, and keep certifi and OS CA bundles current for Python until the CPython fix ships.

Also logged

How this works

Critical: act nowHigh: this weekMedium: check exposureContext

Four times a day (06:00, 12:00, 18:00 and 21:00 Eastern), Claude reads advisory and malware feeds, including cve.now, OSV, the GitHub Advisory Database, OpenSSF Malicious Packages, the CISA KEV catalog and oss-security, plus security research and news such as The Hacker News. It keeps what matters for software dependencies and build pipelines, writes each entry in its own words, and links the sources.

Entries are triage notes, not full advisories. "Am I affected?" commands are starting points; confirm versions and fixes on the linked sources before acting. EPSS is FIRST's estimate of the chance of exploitation in the next 30 days.

RSS feeds