The durabletask PyPI Supply Chain Attack

Updated 5 Oct 2026 · Incident date 19 May 2026 · PyPI

Packagedurabletask 1.4.0 -> 1.4.1, 1.4.2, 1.4.3
Filedurabletask/__init__.py

On 19 May 2026 three malicious versions of the Microsoft durabletask Python package, 1.4.1, 1.4.2 and 1.4.3, were published to PyPI. Phoenix Security reports that all three were published within 35 minutes. The last clean version is 1.4.0.

The code ran when a Linux system imported the package. It fetched a second stage that stole cloud and developer credentials. Security vendors link the campaign to the TeamPCP group.

What happened

An attacker used stolen GitHub credentials to reach the project, took a PyPI token from the repository secrets, and published three poisoned releases. Phoenix Security gives the window as 16:19 to 16:54 UTC on 19 May 2026. PyPI has since yanked the three versions. Phoenix reports about 417,000 monthly downloads for the package.

The dropper runs at import time on Linux. It downloads a second-stage file called rope.pyz and starts it as a detached background process. The second stage collects credentials for AWS, Azure and GCP, Kubernetes secrets, password manager data and the configuration of AI developer tools. StepSecurity counts more than 90 developer tool configurations and says the code skips systems with a Russian locale.

Phoenix reports the worm spreads to other machines through AWS SSM SendCommand and kubectl exec. This attack was one of several in the same days. StepSecurity describes five attacks in 48 hours.

Version 1.4.0 and the three poisoned releases differ in the package code that runs on import. A tool that compares the trusted version with the new one, such as Vigilance, reports that new network and process behaviour.

Affected versions

Version 1.4.0 is the last clean release named by Phoenix Security. Only Linux systems run the dropper according to Phoenix.

Indicators of compromise

These indicators come from Phoenix Security and a search summary of the Wiz and StepSecurity reports. Defang domains before you share them.

The sources list different file hashes for the three versions, so this page gives none. Use the hashes in the vendor reports.

How to check

You can check which durabletask version a Python environment holds without running the package.

pip show durabletask
pip freeze | grep -i durabletask
ls -la /tmp/managed.pyz ~/.cache/.sys-update-check ~/.cache/.sys-update-check-k8s 2>/dev/null

Also search lockfiles in your repositories for the three bad versions, and search egress logs for the two domains.

What to do now

  1. Pin to durabletask==1.4.0 and remove 1.4.1, 1.4.2 and 1.4.3 from every environment and image.
  2. If a bad version was imported, treat the host as compromised and look for the files above.
  3. Rotate cloud credentials, GitHub tokens, SSH keys and Kubernetes secrets that the host could read.
  4. Block the two C2 domains at egress.
  5. Audit AWS SSM and Kubernetes activity for commands you did not run.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

vigi diff --old durabletask-1.4.0 --new durabletask-1.4.1
files scanned: 25

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

CHANGED    durabletask/__init__.py
           It now downloads from the internet and reads saved passwords and access keys. It did not before.

Frequently asked questions

What is the durabletask PyPI compromise?

On 19 May 2026 three malicious versions of the durabletask package, 1.4.1 to 1.4.3, were published to PyPI. They ran a dropper on import that stole credentials. Security vendors link it to TeamPCP.

Which durabletask versions are malicious?

Versions 1.4.1, 1.4.2 and 1.4.3. Version 1.4.0 is the last clean release.

How do I check if I am affected by the durabletask attack?

Run pip show durabletask and look for the bad versions. Then look for /tmp/managed.pyz and the ~/.cache/.sys-update-check marker files.

Sources

  1. phoenix.security/teampcp-github-breach-durabletask-pypi-supply-chain-wave-four-2026/
  2. stepsecurity.io/blog/5-supply-chain-attacks-in-48-hours-why-securing-one-layer-is-not-enough
  3. wiz.io/blog/durabletask-teampcp-supply-chain-attack
  4. venturebeat.com/security/github-confirms-3800-repos-stolen-poisoned-vs-code-extension-supply-chain-worm-microsoft-python-sdk

More supply chain attacks

All 111 attacks in the library · What is a supply chain attack? · How to prevent supply chain attacks

Check the next update before you install it

Vigilance compares the version you trust with the new one. It names the one file that can now do something it could not do before.

Start Free