Python Virtual Environments Cheat Sheet

A virtual environment is a self-contained Python install — its own site-packages, isolated from the system Python and from any other venv — created with the standard library's own venv module, no separate install required. On this site it's the fix for pip install failing with error: externally-managed-environment on Kali and every other modern Debian-based distro, which several CVE labs run into the moment they clone a public exploit's requirements.txt. For everything else python3 is used for on an engagement — reverse shells, TTY upgrades, running the exploit script this venv is isolating — see the python3 cheat sheet.

Red Team / Offensive Use

Two unrelated public exploit scripts pinning incompatible versions of the same library — one needs requests==2.28, the other needs requests>=2.31 — is a routine annoyance on a real engagement toolbox that's accumulated a year of one-off PoCs. A venv per tool sidesteps the conflict entirely instead of fighting it with pip install --force. It's also basic hygiene on a shared or team-provisioned attack box: a one-off exploit's dependencies live in its own venv/ folder and get deleted with it, instead of permanently altering the box's global Python for everyone who uses it after you. And since PEP 668 (Debian Bookworm, Kali rolling, Ubuntu 23.04+), it's not optional at all — pip install against system Python is blocked by default, full stop.

Worth being precise about what a venv actually isolates, though: it's dependency isolation, not a security sandbox. It doesn't restrict what a script can do once it's running — a malicious or booby-trapped PoC has the same filesystem and network access inside a venv as outside one. If you don't trust a PoC's code, run it in a disposable container or VM (see the Docker cheatsheet), not just a venv.

Established Cheatsheet

Python docs: venv — the official standard-library reference.

PWNMI's Top 7 Use Cases

• python3 -m venv venv — create a new virtual environment in a venv/ folder; the fix for externally-managed-environment on Kali and any modern Debian-based distro
• source venv/bin/activate — activate it in the current shell; every pip install and python3 after this point runs inside the isolated environment, not system Python
• pip install -r requirements.txt — install a PoC or tool's exact pinned dependencies into the active venv, isolated from every other tool's requirements
• deactivate — leave the environment, back to system Python, without deleting anything
• venv/bin/python3 exploit.py — run a script inside the venv without activating first, useful in a one-liner or a non-interactive script
• pip freeze > requirements.txt — snapshot exactly what's installed; useful for reproducing a specific tool's working state later or documenting exact versions used in a report
• python3 -m venv --system-site-packages venv — create a venv that still sees system-wide packages, useful when a tool needs something heavy already installed via apt (impacket, for example) alongside its own pinned extras

Next step

To see this used as part of a real exploit chain, see CVE-2026-65008 (Grav CMS), CVE-2025-54068 (Laravel Livewire), or CVE-2025-68613 (n8n) — all three clone a public PoC with its own requirements.txt. For isolating a tool you don't trust at all, not just its dependencies, see Docker for Security Labs.