In 2017 and 2018 there were these infamous stories about malicious packages being uploaded to the PyPI (Python Package Index) which tried to do all sorts of things (collecting and sending data, reverse shells etc) during installation as pip and setuptools would execute setup.py install automatically when setting up a new package.

Would it be possible to block or at least warn about any network requests going to non-PyPI servers that happen during a package installation? Is it a good counter-measure for this kind of a situation?

  • 2
    That depends on what measures you're willing to take. There are a number of ways to do this, from mandatory access controls to seccomp brokers or patches to netfilter. The simplest way would be to run the installer under a specific group, and have netfilter deny network access to any IP but whitelisted ones.
    – forest
    Commented Dec 27, 2018 at 4:59

2 Answers 2


Is it a good counter-measure for this kind of a situation?

No. Unfortunately what you're planning to do won't address this specific threat. Here, the attackers compromised the package on PyPI itself, hence it was downloaded from the original source, so limiting downloads only to PyPI would have no effect.

In most cases, these compromised packages come in two flavours:

  • Attackers gain control of a legitimate package and inject malicious code into it. e.g. NPM event-stream
  • Attackers create a malicious package that looks similar to the legitimate package (jeIlyfish vs. jellyfish) -- the form uses the upper-case 'i' instead of 'l'.

It's hard to address this without some tooling, ultimately it's nice to be able to build everything yourself, but sooner or later you're going to need external packages -- and sometimes those external packages get compromised. Even without attackers, legitimate CVEs are found in commonly used package and require upgrades on your part to protect your application.

For this you need a tool, that scans your requirements.txt file and validates against a list of known vulnerable packages (either through this type of compromise or something else). Of course this is more post-build rather than pre-build, but you can incorporate into your build pipeline if required (validate requirements.txt before building).

If you publish your code on Github, it automatically is scanned by Github against known vulnerable packages and warns you via email and on the repo homepage. There are other tools like pyup, synk, etc that do exactly the same thing.


One of the requirements of Pypi is that the URI contains "api/pypi" on the path, so with a good firewall you can put a rule that only allows your domain that you trust pip and you can reject the rest with a regular expression that contains the api/pypi.

  • 1
    You can accomplish this with setting up a Pi-Hole that proxies all of our DNS requests and then just write a regex blocking rule that blocks 'api/pyp' in the URL Commented Dec 10, 2019 at 18:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .