DependencyWatch.io
FeedSolutionsSubmitScan your lockfile
pipPyPI

Check requirements.txt for malicious PyPI packages

requirements.txt is the most common way Python projects declare dependencies, and how precise an answer we can give depends entirely on whether you pinned versions. Exact pins give a confirmed answer; unpinned entries give an advisory.

We check it against 374 compromised PyPI packages drawn from 35 tracked incidents. Everything runs in your browser - your requirements.txt never leaves your machine.

Parsed locally in your browser. Nothing leaves your device, no logging, no network round-trip.

What we read from your requirements.txt

  • exact pins - mistralai==2.4.6
  • ranges and compatible-release specifiers - urllib3>=1.26,<2.0, numpy~=1.26.0
  • extras and environment markers - requests[security]==2.31.0, black; sys_platform == "darwin"
  • bare entries with no version, reported as advisories rather than findings

Confirmed matches

Entries pinned with `==` give a confirmed answer. Entries with a range, or with no version at all, are reported separately as advisories - we can tell you the package has had compromised releases, but not whether you installed one.

Things worth knowing about requirements.txt

Unpinned dependencies cannot be confirmed

A bare aioquic line tells pip to install whatever is newest at the time. We cannot know which version landed on your machine, so we surface it as an advisory: this package has had malicious releases, go and check what you actually have installed with pip show.

Install-time execution is the norm on PyPI

A large share of the PyPI incidents we track execute during installation via setup.py or a build hook, rather than waiting to be imported. pip install is enough to detonate them, which means a failed or cancelled install still counts as exposure.

Name collisions across ecosystems are real

Some names exist on both npm and PyPI - mistralai is a live example in our own database. We match strictly within the PyPI ecosystem for this file, so a compromised npm package of the same name will not produce a false positive here.

Recent PyPI compromises we check for

The most recent of 35 tracked incidents affecting this ecosystem.

See all 35 incidents

requirements.txt security questions

What if my requirements.txt has no pinned versions?
We still check it, but the result is an advisory rather than a confirmed finding - we can tell you a package has had malicious releases without knowing which version you installed. Run pip freeze > requirements-lock.txt and paste that instead for a definitive answer.
Does this check Poetry, Pipenv, or uv lockfiles?
Not yet - today we read requirements.txt and the npm-ecosystem lockfiles. The practical workaround is to export: poetry export -f requirements.txt, pipenv requirements, or uv export --format requirements-txt, then paste the result.
Does `pip-audit` or Safety already cover this?
They mostly cover known vulnerabilities in legitimate packages, drawing on advisory databases. Deliberately malicious packages are usually yanked from PyPI within hours of discovery, and after that a vulnerability lookup often returns nothing while the malicious version is still pinned in your file and cached in your internal mirror. We match the malicious releases directly.
I installed one of these. Is uninstalling enough?
No. Assume anything readable by that process was taken - environment variables, API tokens, SSH keys, cloud credentials. Rotate them from a different machine, then uninstall and clear your pip cache and any internal mirror that may still be serving the yanked release.

Check another file

We only list package versions named by the original advisory - we don't infer compromises. Spotted one we're missing? Send it in.