On May 19, 2026, three malicious versions of Microsoft's official durabletask Python SDK shipped to PyPI inside a 35-minute window. Versions 1.4.1, 1.4.2, and 1.4.3 all carried the same payload: a 28KB credential stealer targeting cloud secrets, password-manager exports, and configuration data from more than 90 developer tools. The package is the official SDK for Azure Durable Functions. It pulls more than 400,000 monthly downloads. Microsoft owns it. And TeamPCP shipped to it directly, bypassing Microsoft's CI/CD pipeline entirely.
The attribution and the technical write-up come from StepSecurity, Wiz, and SafeDep, each with primary research published within hours of the malicious versions going live. The campaign continues the Mini Shai-Hulud thread that hit @tanstack, Mistral AI, UiPath, OpenSearch, and Guardrails AI starting May 11. Same operator, same payload family, same target class: popular packages that thousands of other packages depend on.
How the attacker got in
The mechanism is the consequential bit, and it is not a CVE. The attacker compromised a GitHub account belonging to someone with PyPI publishing rights for durabletask. From that account, the attacker pulled secrets out of an accessible repository, which included the PyPI publishing token. With the token in hand, the attacker uploaded 1.4.1, 1.4.2, and 1.4.3 to PyPI directly, no CI/CD involved, no Microsoft pipeline traversed, no internal review.
The defense Microsoft had built around the durabletask source code, branch protections, signed commits, required reviewers, was completely irrelevant because the attacker never touched the source code. They shipped poisoned binaries straight to the registry.
This is the same structural failure mode as the node-ipc maintainer hijack from May 14, where the attacker re-registered the maintainer's expired recovery domain and walked through npm's password reset flow. Different attack, same pattern: the credential that authorises a registry push is now the high-value target, not the source code.
What the payload does
The 28KB payload is straightforward and effective. It enumerates environment variables and configuration files for AWS, Azure, GCP, Kubernetes (kubeconfig, in-cluster service-account tokens), and SSH (private keys, known_hosts). It scrapes password managers, 1Password and Bitwarden export caches if present. It pulls configuration data from more than 90 developer tools, the kind of secrets people leave in dotfiles: GitHub personal access tokens, npm publish tokens, PyPI tokens, CI runner state, Docker registry credentials, Jenkins API keys.
Once collected, the payload attempts lateral movement through cloud infrastructure using the harvested tokens. If the host has IAM permissions that allow it, the payload pivots: it harvests tokens from cloud secret managers, walks the developer's organisation membership graph, and tries to spread.
There is one detail worth flagging: the payload aborts on systems with a Russian locale. If LANG=ru_* is set, the credential stealer exits cleanly without firing. This is a hallmark of Eastern European cybercrime crews and has been consistent across the Mini Shai-Hulud campaign. Wiz and SafeDep both call it out as the attribution hook.
What to do today
If your CI/CD pipeline or any developer workstation pulled durabletask between roughly 01:30 and 02:30 UTC on May 19, 2026, treat that host as compromised. The window when the malicious versions were live on PyPI was narrow, but anything pulled during that window has the credential stealer running.
The remediation order:
- Pin durabletask to 1.4.0. That version is the last clean release before the malicious 1.4.1.
- Rotate every cloud token referenced anywhere in the call chain. AWS, Azure, GCP, Kubernetes service accounts, secret-manager keys, anything the affected host could reach.
- Rotate every developer-tool token. GitHub PATs, npm publish tokens, PyPI tokens, CI runner credentials, Docker registry creds. If a host pulled the bad version, assume every credential in scope is exposed.
- Audit your own organisation's PyPI and npm publish tokens. If your team ships packages that others consume, those tokens are now a target. Store them in hardware-key-protected secret vaults, require manual approval on every publish, and rotate any token whose creator is not currently on the team.
- Audit recovery-email-domain expiry. Walk every maintainer account on packages your org owns. Any account whose recovery email lives on a domain registered more than five years ago is a candidate for the node-ipc-style takeover. The fix is moving recovery to an organisation-controlled domain with active monitoring.
The structural read
The May 2026 supply-chain rhythm is now legible. The entry point is not novel typosquats or dependency confusion. The entry point is the credential that authorises a registry push: maintainer account passwords with stale recovery flows, publishing tokens stored as ordinary repository secrets, GitHub accounts without hardware-key MFA.
Microsoft is not careless. They have one of the most mature engineering security programs in the industry. The fact that TeamPCP could chain a GitHub compromise into a PyPI publish-token theft and ship straight to durabletask means the publishing-token threat model is structurally under-protected across the ecosystem. If Microsoft's controls were not enough, smaller maintainers have no chance.
The defender posture has to shift accordingly. Treat publishing tokens as production secrets, not CI conveniences. Move them to hardware-key-protected stores. Require manual human approval on every package publish, not just on first-time releases. And if you consume packages that thousands of other packages depend on, you now have to assume that registry-published versions can carry payloads, and that "the package is legitimate" is no longer a sufficient trust signal.
The 2026 supply chain looks a lot like the 2018-era npm worm era, except the operators are better funded, the payloads are cloud-aware, and the targets are popular and trusted. Treat every transitive dependency with the same scrutiny you'd apply to a piece of unsigned code from a stranger, because that is what it has become.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if your team needs help auditing publish-token hygiene or building a maintainer-account threat model.