https://vanemmerik.ai/supply-chain/ Supply Chain Watch entries: Docker. en https://vanemmerik.ai/supply-chain/2026-10-24/#emudhra-trust-store-updates vea-sc-2026-10-24-emudhra-trust-store-updates Sat, 24 Oct 2026 21:53:00 +0000 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. 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. https://vanemmerik.ai/supply-chain/2026-10-24/#litellm-root-cause-leaked-master-key vea-sc-2026-10-24-litellm-root-cause-leaked-master-key Sat, 24 Oct 2026 16:01:00 +0000 LiteLLM's Oct 23 write-up says a master key for its Agent Platform was committed to a public repo in May and never revoked. On Oct 10 the attacker used it to pull an org owner's unscoped GitHub CLI token, then ran throwaway CI branches that shipped repository secrets to a webhook, yielding two more maintainer tokens; the owner token overrode branch protection to point the Oct 21 release at a lookalike fork. Socket separately found two successful secret-stealing cache.yml runs on Oct 10 and Oct 12 (branches ci-tmp-a351cc and ci-tmp-4d8517) targeting 20 secrets, including AI provider keys and a GitHub App private key. This corrects LiteLLM's earlier theory that a token leaked through internal logs. Affected artifacts are unchanged: only 1.107.0 on PyPI and its Docker images; LiteLLM says it is revoking every token and key. What to do: If 1.107.0 ever ran, the earlier guidance stands: rebuild, pin 1.106.2 and rotate. For your own org, revoke keys that were ever committed (even if force-pushed away) and alert on workflow files appearing on short-lived branches. https://vanemmerik.ai/supply-chain/2026-10-23/#litellm-1-107-0-compromise vea-sc-2026-10-23-litellm-1-107-0-compromise Sat, 24 Oct 2026 02:45:00 +0000 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. 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.