Vulnerability and malware checks in uv
Get Started
Back to blog
June<br>8,<br>2026
Vulnerability and malware checks in uv
William Woodruff<br>@woodruffw
We're announcing two new security features for uv:
uv audit is a new command that scans your dependencies for known vulnerabilities and "adverse"<br>project statuses (such as being deprecated). It's a uv-native alternative to pip-audit, and is<br>between 4x and 10x1 faster on typical projects.
uv add, uv sync, etc. can now perform a lightweight OSV-based lookup for previously-resolved<br>malware on every sync operation. This feature is not enabled by default, but you can try it by<br>setting UV_MALWARE_CHECK=1.
Both of these features are in preview for now. They're considered unstable and there may be breaking<br>changes as we iterate on their design. We encourage you to read our docs, try these out and share<br>your feedback with us!
Why uv audit? #
Developers are reasonably and rightfully concerned about the security of their dependencies, and<br>expect tooling that helps them address those concerns. This is particularly true with the rise of<br>"supply chain" concerns, including:
Large, complex and/or opaque dependency graphs;
Year-over-year increases in the number of known (i.e. disclosed) vulnerabilities;
Decreases in the cost of discovering vulnerabilities, in part due to recent advances in<br>LLM-guided vulnerability discovery and exploitation.
At the same time, Python packaging already has tools for auditing dependencies, like pip-audit and<br>safety. So why build a new tool? Two big reasons:
A uv-native experience: vulnerability scanning should be a first-class citizen in engineering<br>flows, rather than an afterthought. By building auditing directly into uv, we can ensure that<br>users receive a consistent experience and don't need to integrate a separate tool into their<br>development and testing workflows.
Similarly, we believe that a vulnerability scanning should take full advantage of its surrounding<br>context. In uv's case, that means accelerating audits by leveraging uv's locked resolutions, as<br>well as supporting configuration in uv.toml and pyproject.toml.
Performance: implementing auditing in uv means we can take advantage of performant primitives<br>for networking, caching, package resolution, parsing, etc.
Why malware scanning? #
The dependency risk environment has shifted dramatically over the past few years: remediating normal<br>vulnerabilities continues to be critical, but users are<br>increasingly affected by<br>actively malicious dependencies as well.
The threat of malware in open source dependencies has a subtly different detection and remediation<br>profile than ordinary vulnerabilities:
Ordinary vulnerabilities often require only passive remediation: patching to a non-vulnerable<br>version is often sufficent unless the vulnerability is being actively exploited.
By contrast, malicious dependencies tend to require active remediation: malware frequently<br>steals credentials or other sensitive materials. This means that a malware presence signal<br>requires immediate response.
Malware is remediated in parallel by both users and indices: PyPI, for example, will quarantine<br>known and suspected malware to limit its spread.
This is a critical part of remediation, but it presents a new challenge for locking installers<br>like uv: quarantine status means that the malware gets removed from the index, but a lockfile<br>that points directly to the underlying object storage is still capable of directly installing<br>malicious distributions2.
Together, these differences mean that defending users against malicious packages requires a<br>different approach than a discrete uv audit command.
The approach we're exploring is a lightweight malware check when installing packages: whenever you<br>run uv add or any other command that causes a sync, uv will ask OSV whether it has any MAL<br>advisories for your currently locked resolution. If a package in your lockfile matches any<br>known3 malware advisories, the sync will be terminated before the malicious code has a<br>chance to run.
Malware checks are currently opt-in: you'll need to set UV_MALWARE_CHECK=1 to enable them. We'll<br>evaluate enabling them by default in a future release.
Looking forwards #
The design space for vulnerability and malware scanning and management is large. These new features<br>are in preview to give us the flexibility to iterate on their design.
Some of the things we're evaluating:
Future proofing through further integration: our broader perspective on tooling is that tight<br>integrations between historically devolved features unlock new capabilities that the next<br>generation of developers will take for granted.
At the moment, the typical developer's experiences with vulnerability scanning is either discrete<br>(performing audits as a separate step in CI) or frustratingly integrated (npm install telling<br>you that you have hundreds of vulnerabilities at exactly the moment you don't want to deal with<br>them). But there's a third way: tools that adapt...