What should teams do first when a PyPI package is compromised?

Containment comes before cleanup in a PyPI compromise

The first move is to stop further execution and further spread. If the package was installed in build pipelines, developer workstations, or production hosts, treat each of those environments as potentially exposed until you know which ones pulled the compromised version and what the package did at install time.

Isolate the affected hosts or runners, prevent new installs of the compromised release, and preserve the state of the machine before any remediation changes the evidence. In package incidents, the install script, import path, or post-install behaviour can matter as much as the package contents themselves, so the response has to start with containment and preservation, not deletion.

For broader handling of poisoned open source dependencies, the Malicious Open Source Package Response Playbook gives a practical sequence for isolating hosts, finding affected lockfiles and images, and rotating exposed credentials.

A supply-chain incident like this can also hide in more than one layer. The same compromised package may be present in a CI job, a local virtual environment, and a shipped container image, so the initial response should assume multiple execution surfaces until inventory proves otherwise.

What teams need to check next

Once execution is contained, identify every environment that installed the package and determine whether it ran during build, test, deploy, or runtime. That distinction matters because install-time code may have touched developer tokens, CI secrets, cloud credentials, or outbound network paths even if the package was never imported by the application.

Revoke any secrets that could have been exposed through installation or post-install activity, then rebuild from trusted artefacts rather than trying to “clean” a potentially tainted environment in place. For a PyPI compromise, the key question is not only whether the package was present, but whether it had an opportunity to execute with access to credentials, signing material, or other sensitive environment data.

The Open source package compromise guide covers the same decision point from a consumer-response angle, including exposure confirmation, host containment, and credential rotation. For examples where a PyPI package was used to steal secrets or publish malicious releases, LiteLLM PyPI package breach and PyTorch torchtriton supply chain attack 2022 show why rebuilds and secret revocation have to be treated as first-order response steps.

If install or post-install activity reached build infrastructure, review lockfiles, wheels, cached layers, and package mirrors before you trust any later build output. The fastest way to miss compromise is to assume the latest successful build is clean simply because the malware is no longer present on disk.

How to verify the blast radius is actually closed

Verification should answer three questions: what ran, where it ran, and what it could reach. That means checking package install logs, process creation history, outbound connections, container layer history, and any CI job records that show the compromised version entering the environment.

If the package had access to signing keys, deployment tokens, registry credentials, or cloud API keys, treat those as compromised until rotated and validated. Teams often focus on the package itself and underweight the identity material it may have touched, but that is usually what expands a software supply-chain incident into a wider incident.

The most useful evidence is the evidence that lets you prove scope: a preserved disk image, process tree, network telemetry, package manager logs, and the list of systems that consumed the package. Once that is collected, rebuild from trusted sources and only then reintroduce the application into service.

Miasma and Hades Supply Chain Worms and Ultralytics PyPI compromise 2024 are useful references because they show how package compromise can cross from registry exposure into credential theft and CI abuse.

Risk and Threat Considerations

A compromised PyPI package is risky because installation itself may be the attack moment. Even if the package is later removed or replaced, the install event can already have exposed secrets, altered build outputs, or given an attacker a foothold in a pipeline or workstation.

Failure mechanism: Malicious package code executes during install, import, or post-install steps, then exfiltrates credentials, tampers with build artefacts, or persists through cached layers and reused environments.

Impact: The blast radius can extend beyond a single application to CI systems, developer accounts, registry credentials, and downstream releases built from contaminated artefacts.

Practitioner Guidance

What to prioritise: Treat containment and evidence preservation as the first decision, not a follow-up. If the package executed anywhere with access to secrets or signing material, rotate those secrets before you trust any rebuilt artefact.

What to verify: Confirm the package version, every environment that consumed it, and whether install scripts or import-time code ran. If you cannot prove an environment never executed the package, assume it was exposed.

Practitioner takeaway: The correct first response is to freeze execution, preserve proof, and narrow the blast radius before cleanup, because in package compromise the most damaging action is often what the package already did during installation.

Related resources from NHI Mgmt Group

• What fails first when a malicious PyPI package executes at import time?
• What is the first thing to do when a compromised npm package may have run during installation?
• Why do SaaS supply chain incidents spread beyond the first compromised app?
• Should organisations prioritize vaulting or rotation first for compromised secrets?