https://vanemmerik.ai/supply-chain/ Supply Chain Watch entries: PyPI. en https://vanemmerik.ai/supply-chain/2026-10-25/#emudhra-oracle-java-cpython-update vea-sc-2026-10-25-emudhra-oracle-java-cpython-update Mon, 26 Oct 2026 00:52:00 +0000 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. 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. https://vanemmerik.ai/supply-chain/2026-10-25/#aider-conf-yml-command-execution vea-sc-2026-10-25-aider-conf-yml-command-execution Mon, 26 Oct 2026 00:52:00 +0000 CVE-2026-115726 (CVSS 7.8, published Oct 25 via VulnCheck) affects the Aider AI coding assistant through 0.86.2: it loads a .aider.conf.yml from the working repository without a trust prompt, and values in fields such as notifications-command or editor are run through a shell. Opening Aider inside a cloned, untrusted repository can therefore run attacker commands with your privileges. The public issue was opened Oct 20 with no maintainer response or fix so far, and no exploitation or public exploit is reported. What to do: Do not start Aider in repositories you have not reviewed; inspect any .aider.conf.yml for command-bearing keys first. https://vanemmerik.ai/supply-chain/2026-10-25/#hf-datasets-pandas-pickle-rce vea-sc-2026-10-25-hf-datasets-pandas-pickle-rce Sun, 25 Oct 2026 16:05:00 +0000 CVE-2026-57845 (CVSS 8.8, published Oct 24 by VulnCheck) covers datasets.load_dataset("pandas", ...), which hands user-supplied files to pandas.read_pickle, so a crafted dataset file runs code with the loader's privileges. All versions through 5.1.0 are listed as affected, a fix is proposed in PR #8879 but not released, and the researcher has published a proof of concept. Exposure is limited to pipelines that load third-party datasets through the pandas builder, but that is a common pattern in ML training jobs. What to do: Do not load untrusted datasets with the pandas builder; prefer Parquet, CSV or JSON loaders and pin datasets until a fixed release ships. https://vanemmerik.ai/supply-chain/2026-10-24/#brotli-http2shell-python-bun-envoy vea-sc-2026-10-24-brotli-http2shell-python-bun-envoy Sat, 24 Oct 2026 21:53:00 +0000 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. 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. 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-24/#x402-sdk-spending-limit-flaws vea-sc-2026-10-24-x402-sdk-spending-limit-flaws Sat, 24 Oct 2026 10:08:00 +0000 V12 reported three flaws in the x402 agent-payment SDKs, published Oct 22-23. The TypeScript fetch and axios clients had no default spending cap, so a hostile API could ask an agent to sign away its full balance; @x402/svm 2.0.0 to 2.22.0 accepted a Solana token approval as payment; and the sign-in extension could sign a login for another site. TypeScript packages are fixed in 2.23.0 (current is 2.28.0); the Python and Go clients were fixed in their Aug 18 releases, with exact versions not stated. There is no CVE or GHSA, npm audit does not flag the old releases, and no attacks have been reported. What to do: If your agents pay with x402, move the @x402 packages to 2.23.0 or later (and the Python/Go clients to current releases) and set an explicit per-request spending limit. https://vanemmerik.ai/supply-chain/2026-10-23/#pillow-13-0-0-security-fixes vea-sc-2026-10-23-pillow-13-0-0-security-fixes Sat, 24 Oct 2026 03:05:00 +0000 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. 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. 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.