Microsoft DurableTask Python Package Hit by TeamPCP Supply Chain Attack

Three releases of the durabletask Python package were compromised in a supply chain attack linked to TeamPCP, also tracked in reports around the Mini Shai-Hulud campaign. The affected versions are 1.4.1, 1.4.2, and 1.4.3.

Durabletask is Microsoft’s Python SDK for the Durable Task workflow execution framework. It lets developers define, schedule, and manage durable orchestrations using ordinary Python code.

The malicious releases were published to PyPI on May 19, 2026 and have since been yanked or quarantined. Developers should avoid versions 1.4.1 through 1.4.3 and treat any Linux system that installed and imported them as potentially compromised.

What happened?

Wiz says the compromise followed the same pattern seen in recent TeamPCP supply chain attacks. A compromised GitHub account had access to a repository where a PyPI token was present in GitHub Secrets.

The attacker then used that publishing token to push malicious durabletask releases directly to PyPI. That approach bypassed normal repository review because the poisoned packages did not need to come from a legitimate GitHub release workflow.

Wiz observed attacker activity targeting the microsoft/durabletask-python repository between 15:08 UTC and 15:16 UTC. The attacker copied a recent commit message from the main branch to make the activity look routine.

Compromised durabletask versions at a glance

Package	Compromised versions	Current status	Main risk
durabletask	1.4.1	Yanked from PyPI as compromised	Credential theft and payload execution on Linux
durabletask	1.4.2	Yanked from PyPI as compromised	Credential theft and payload execution on Linux
durabletask	1.4.3	Yanked from PyPI as compromised	Credential theft and payload execution on Linux
durabletask	1.4.0	Listed by PyPI as the latest version	Not listed as one of the compromised releases

What the malware does

The malicious durabletask releases contain a dropper that fetches a second-stage payload called rope.pyz. Wiz describes it as an evolution of the payload used in the earlier guardrails-ai compromise.

The payload targets Linux systems and focuses on credential theft. It searches for secrets across cloud accounts, Kubernetes environments, Vault tokens, password managers, shell history, and local files.

The malware also has worm-like behavior. It can attempt lateral movement through AWS Systems Manager and Kubernetes, spreading to up to five additional targets from each infected host.

What credentials are at risk?

• AWS IAM credentials and related cloud secrets.
• Azure credentials and service account material.
• Google Cloud credentials and service account tokens.
• Kubernetes service account tokens.
• HashiCorp Vault tokens.
• Bitwarden, 1Password, pass, and gopass secrets where accessible.
• Passwords and tokens exposed through environment variables.
• Secrets stored in .bash_history and .zsh_history files.

That broad target list makes the attack especially dangerous in CI/CD environments. Build runners often hold tokens for cloud deployment, package publishing, source control, Kubernetes clusters, and secret stores.

How the malicious package spreads risk

Supply chain attacks become dangerous because developers trust package registries and automation. A poisoned package can enter a build through a lockfile, dependency update, CI job, or cached artifact.

In this case, the malware can execute when the compromised package gets imported. A project does not need to call a suspicious function directly for the initial payload path to matter.

The risk grows when the package runs inside Linux-based automation. Many CI runners, build containers, and deployment workers run on Linux and have access to sensitive environment variables.

Key technical indicators

Indicator type	Indicator	Why it matters
C2 domain	check.git-service[.]com	Primary command-and-control domain
C2 domain	t.m-kosche[.]com	Backup command-and-control domain
Payload file	/tmp/rope-*.pyz	Downloaded second-stage payload
Payload file	/tmp/managed.pyz	Runtime payload indicator listed by Wiz
Marker	~/.cache/.sys-update-check	General infection marker
Marker	~/.cache/.sys-update-check-k8s	Kubernetes-related infection marker
Hash	069ac1dc7f7649b76bc72a11ac700f373804bfd81dab7e561157b703999f44ce	rope.pyz payload hash

Why this attack is linked to TeamPCP

Wiz tied the durabletask compromise to the same broader campaign that hit the @antv npm ecosystem. The connection comes from overlapping tactics, infrastructure, and the compromised account activity that linked the repository access to the previous wave.

The payload also resembles malware used in the earlier guardrails-ai incident. The durabletask version adds improvements such as domain-based command infrastructure, SSL verification, AWS SSM propagation, Kubernetes movement, and password manager brute-force attempts.

The pattern shows how TeamPCP has moved across ecosystems. Recent reporting has linked the group to npm, PyPI, GitHub Actions, developer tooling, and cloud credential theft.

Why developers should take this seriously

Durabletask is not a random typosquat. It is a Microsoft-maintained package associated with a legitimate workflow orchestration framework. That makes the compromise more concerning because developers may have trusted it automatically.

PyPI also lists the microsoft account as a verified maintainer for the package. That does not make the malicious releases safe, but it explains why teams may have allowed the dependency into trusted environments.

The incident shows that verified maintainers and legitimate project names do not remove supply chain risk when publishing credentials are exposed.

What security teams should check now

• Search dependency files for durabletask 1.4.1, 1.4.2, or 1.4.3.
• Review CI logs for installs of the compromised versions on May 19 or later.
• Check Linux hosts for /tmp/rope-*.pyz and /tmp/managed.pyz.
• Look for ~/.cache/.sys-update-check and ~/.cache/.sys-update-check-k8s.
• Search process lists for unexpected python3 payload execution.
• Review DNS and proxy logs for check.git-service[.]com and t.m-kosche[.]com.
• Block the listed C2 domains and related exfiltration paths.
• Audit AWS SSM and Kubernetes activity for unusual lateral movement.

Credential rotation should be broad

If a Linux host installed and imported one of the compromised versions, teams should assume credentials reachable from that environment may have been exposed.

That includes cloud provider keys, Kubernetes tokens, Vault tokens, package registry tokens, Git credentials, SSH keys, and passwords stored in developer tooling or shell history.

Credential rotation should happen from a clean machine. Teams should also review whether the compromised environment had access to production clusters, deployment keys, package publishing rights, or private source code.

Recommended response plan

Step	Action
1	Identify all projects and hosts that installed durabletask 1.4.1, 1.4.2, or 1.4.3.
2	Downgrade or pin to a known safe version while reviewing official package guidance.
3	Rebuild affected applications from clean CI runners.
4	Rotate all secrets available to affected hosts.
5	Audit cloud, Kubernetes, Vault, and source control activity after the exposure window.
6	Block C2 domains and review outbound traffic for exfiltration indicators.

What cloud teams should audit

In AWS, teams should review CloudTrail for SSM:SendCommand and SSM:DescribeInstanceInformation activity from potentially compromised instances. These calls can indicate attempts to discover or move across managed EC2 systems.

In Kubernetes, teams should check audit logs for unexpected kubectl exec behavior, unusual service account use, suspicious pod access, and activity from CI service accounts.

Teams using password manager CLIs should review Bitwarden and 1Password activity. Wiz says the payload attempts to unlock stored secrets using harvested passwords from the environment and shell history.

How to reduce future package compromise risk

This attack shows why organizations need controls around dependency updates. A package can become malicious even when the project name and maintainer look legitimate.

Security teams should consider cooldown windows for new package releases, strict allowlists for production builds, and automated scanning of dependency changes before deployment.

CI/CD environments should also use short-lived credentials, scoped tokens, and secretless authentication where possible. A stolen PyPI token or GitHub secret should not give attackers broad publishing or deployment power.

The bigger supply chain lesson

The durabletask compromise is part of a wider trend in which attackers target the software build process instead of only targeting production systems. Package registries, GitHub Secrets, CI runners, and developer machines now sit directly in the attack path.

For defenders, the lesson is direct. Dependency trust must include registry monitoring, token hygiene, build isolation, and rapid secret rotation after any suspected exposure.

Teams that installed the affected durabletask versions should not wait for visible signs of compromise. The safest approach is to investigate, rebuild, rotate credentials, and tighten package publishing controls.

FAQ