<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
  <title>Supply Chain Watch · crates.io</title>
  <link>https://vanemmerik.ai/supply-chain/</link>
  <description>Supply Chain Watch entries: crates.io.</description>
  <language>en</language>
  <item>
    <title>[High] Wasmtime sandbox escape on aarch64 via huge br_table (CVSS 9.9); fixed in 36.0.19, 48.0.7, 49.0.4</title>
    <link>https://vanemmerik.ai/supply-chain/2026-10-25/#wasmtime-aarch64-br-table-sandbox-escape</link>
    <guid isPermaLink="false">vea-sc-2026-10-25-wasmtime-aarch64-br-table-sandbox-escape</guid>
    <pubDate>Sun, 25 Oct 2026 16:05:00 +0000</pubDate>
    <description>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. 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.</description>
  </item>
  <item>
    <title>[High] eMudhra CA key compromise: certifi, pip, uv, Node.js, Go and Rust trust stores need updating, not just browsers</title>
    <link>https://vanemmerik.ai/supply-chain/2026-10-24/#emudhra-trust-store-updates</link>
    <guid isPermaLink="false">vea-sc-2026-10-24-emudhra-trust-store-updates</guid>
    <pubDate>Sat, 24 Oct 2026 21:53:00 +0000</pubDate>
    <description>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&#x27;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.</description>
  </item>
  <item>
    <title>[Medium] tokio 1.54.0 timer race can corrupt memory in safe Rust; fixed in 1.54.1</title>
    <link>https://vanemmerik.ai/supply-chain/2026-10-23/#tokio-1-54-0-interval-uaf</link>
    <guid isPermaLink="false">vea-sc-2026-10-23-tokio-1-54-0-interval-uaf</guid>
    <pubDate>Sat, 24 Oct 2026 02:45:00 +0000</pubDate>
    <description>A race between Interval ticking and the multi-threaded runtime&#x27;s time driver could drop a timer entry while it was firing, causing a use-after-free. Symptoms range from assertion panics to heap corruption. Only 1.54.0 is affected; local, high-complexity, CVSS 5.8. What to do: If Cargo.lock pins tokio 1.54.0, run cargo update -p tokio to reach 1.54.1 or later.</description>
  </item>
</channel>
</rss>
