uv 0.13.5 drops the compromised root and moves managed CPython onto three security patches

uv 0.13.5 shipped on October 21, and it only makes sense together with the release before it:

• 0.13.4: remove the compromised eMudhra / emSign root from uv’s own certificate store;
• 0.13.5: move all managed CPython builds to python-build-standalone 20261021, including the 3.15.1, 3.14.9 and 3.13.17 security patch releases, with pip 26.2.2 and certifi 2026.10.19.

Why a package manager ships its own root store

This is where many people learn the fact: uv does not use the system trust store when it downloads.

The reasoning is practical. Relying on the system store means handling the macOS keychain, Windows CryptoAPI, and whatever each Linux distribution packages as CA certificates — and a stale or missing system store breaks installs outright. So Go, parts of Rust and Node tooling, and uv all bundle their own root certificates.

The price: when a CA incident happens, every tool that bundles a store has to cut its own release. That is why eMudhra shows up in the release notes of Deno 2.9.8, uv 0.13.4 and CPython within the same week.

The managed interpreters need it too

The second layer is subtler. uv can download and manage CPython interpreters (uv python install 3.13), and those are prebuilt python-build-standalone artifacts. They carry their own pieces:

Component	Why it is certificate-related
certifi	the Python ecosystem’s root bundle, independent of the system store
pip	installs over HTTPS, using certifi
ensurepip	the pip that lands in a new venv comes from here

So “the system store dropped eMudhra” does not mean “Python’s certifi dropped eMudhra” — that needs a new certifi (2026.10.19) and then a new uv-managed CPython build containing it.

The step that is easy to miss: uv python upgrade

One line in the release notes must be read:

After upgrading uv, run uv python upgrade to install the updated builds. Virtual environments pinned to an older Python patch version do not switch to the updated interpreter.

Which means:

# 1) upgrade uv itself
uv self update

# 2) upgrade the managed interpreters too
uv python upgrade

# 3) verify
uv python list --only-installed

And existing venvs pinned to an older patch do not move. That is deliberate: a venv records a concrete interpreter path, and swapping the interpreter swaps the runtime, which can break binary extensions in your dependencies.

The real-world consequence: you upgrade uv, run uv python upgrade, new venvs use the new interpreter — and old projects keep the old interpreter and the old trust store. To be clean, rebuild the venv:

# rebuild (reinstalls dependencies; fine for CI and containers)
rm -rf .venv
uv venv && uv sync

My take

There is no vulnerability being fixed here (the eMudhra removal happened in 0.13.4); 0.13.5 propagates that fix into every managed runtime. It shows uv’s release model: tool and runtimes are managed separately but shipped together.

Practical advice:

1. Pin uv in CI, and after moving to 0.13.5 rebuild caches and venvs; do not expect in-place effect;
2. In production images, run uv python upgrade explicitly, or the old interpreter stays baked in;
3. If you pin certificate chains (for example talking to an internal service that trusts a specific root), this upgrade changes the trust set — test before shipping.

One more note

More projects distribute runtimes now: uv manages CPython, Bun manages a Node-compatible layer, Deno manages its own runtime. The benefit is controlled versions; the cost is that trust stores, CAs and TLS become each tool’s private problem.

As someone who regularly explains why upgrading a package manager can affect HTTPS, this line is worth writing down: a tool that bundles a trust store must be able to ship often, or one CA incident drags on for months.