On this page (7 sections)
The Python package manager uv carries its own bundled list of trusted certificate authorities (CAs). In versions before 0.13.4, that list contains the emSign ECC Root CA - G3 root, and eight eMudhra intermediate certificates chaining to it have compromised private keys. The GitHub advisory GHSA-hq85-5cpj-mr62 rates it Critical, with a CVSS score of 9.1.
If you use uv on servers, CI runners or developer machines, this is worth a quick check. According to the advisory, an attacker holding one of the compromised keys can issue certificates that uv accepts for any hostname, which can be used for man-in-the-middle (MITM) attacks.
What happened
By default, uv validates TLS connections against a vendored copy of the webpki-root-certs bundle. The advisory says versions before 0.13.4 include the emSign ECC Root CA - G3 root, and that the eight eMudhra intermediates under it have compromised private keys. The CA has revoked those intermediates.
uv 0.13.4 removes the root from its vendored bundle, following webpki-root-certs 1.0.10. The advisory's only remediation instruction is to upgrade to 0.13.4 or later.
The advisory also references a disclosure site and a Mozilla dev-security-policy thread about the eMudhra problem. We have not reviewed those, so this article relies on the single GitHub advisory. Only one independent publisher covers the story so far.
Why a compromised intermediate matters
As general background: a TLS client trusts a set of root CAs, roots vouch for intermediates, and intermediates sign website certificates. If an intermediate's private key falls into the wrong hands, certificates signed with it can chain up to a root the client trusts. That is why the advisory says such certificates would be accepted for any hostname.
The advisory's CVSS v4 metrics list network attack vector, high attack complexity, attack requirements present, no privileges and no user interaction. Impact on confidentiality and integrity is rated high, with no availability impact. The advisory does not spell out the attack scenario beyond the MITM description, so treat any more detailed picture as inference.
Where uv commonly runs
The advisory does not list affected environments. As examples of places uv often runs, and therefore worth checking:
- CI/CD runners and build servers that use uv to install dependencies.
- Developer laptops and containers, especially when used on shared or untrusted networks.
- Docker images that pin an older uv version and are rebuilt rarely.
- Deployment or bootstrap scripts that install a fixed uv version.
Websites that never run uv are not affected by this particular issue. It concerns uv's own outbound TLS checks, not visitors loading your pages.
How to check your exposure
Run this on each machine, runner or container to print the installed uv version. Anything below 0.13.4 is affected.
uv --versionIf you installed uv as a Python package, this read-only command shows the version pip sees. Look for 0.13.4 or later.
python -m pip show uvAlso search your repositories for pinned versions, such as Dockerfiles, CI workflow files and requirements files that fix uv to an older release.
What to do now
The advisory says to upgrade to 0.13.4 or later. For uv installed through pip, the standard upgrade command is below. If you installed uv another way, use that method's own update path.
This command upgrades a pip-installed uv and then prints the version. The result should show 0.13.4 or later.
python -m pip install --upgrade uv
uv --version0 of 6 done
Detection and monitoring afterwards
Nothing in the research tells you whether a past connection was intercepted, so treat the exposure window as a reason to review, not as proof of compromise. Compare what recent builds installed against your lock files and look for unexpected version or hash changes.
For the websites you operate, watching certificate changes is good general practice. The free SSL certificate checker shows which CA issued your certificate and when it expires, and certificate and DNS monitoring can alert you to unexpected changes. These cover your public sites, not uv's internal trust store.
If you suspect a build was tampered with, follow website hacked: what to do, rotate secrets the build could access, and rebuild from clean sources.
What we do not know yet
- The research reports no confirmed exploitation of the compromised keys against uv users.
- No CVE identifier appears in the research, only the GitHub advisory ID.
- How the intermediate keys were compromised is described in external references we have not reviewed.
We will update this article if the advisory or its references change.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.