Durabletask supply-chain compromise shows how import-time code becomes execution

At a glance

What this is: Three malicious durabletask PyPI releases used import-time code to download and run a Linux payload that harvested credentials and enabled lateral movement.

Why it matters: This matters to IAM, NHI, and cloud security teams because trusted package imports can expose service accounts, API keys, tokens, and workload secrets before any application control can intervene.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Corgea's analysis of the durabletask supply-chain compromise and NHI exposure

Context

Python package compromise is increasingly an identity problem as much as a software supply-chain problem. When a malicious library runs at import time, it can reach the same secrets, tokens, and workload credentials that an application depends on for cloud access, CI automation, and internal services.

This durabletask incident is especially relevant to non-human identity governance because the payload targeted AWS, Azure, GCP, Kubernetes, Vault, Docker, SSH, npm, and PyPI credentials on Linux hosts. That makes the exposure boundary the host and its inherited privileges, not just the application that imported the package.

Key questions

Q: What breaks when a Python package can run code on import?

A: The trust boundary breaks first. Import-time execution lets untrusted code run before the application establishes its own security checks, so any secrets already present on the host become fair game. In practice, that means cloud keys, SSH material, and service account tokens can be stolen before the workload even reaches its intended business logic.

Q: Why do compromised build and function hosts increase non-human identity risk?

A: Because those systems often hold multiple secret types at once, including service account tokens, cloud credentials, registry logins, and SSH keys. A single compromise can therefore expose both workload identities and the human or developer identities that manage them.

Q: How do security teams know whether a package advisory has created real identity exposure?

A: They should check whether affected build or developer environments stored cloud keys, SSH keys, API tokens, or SaaS access at the time of installation. If those identities were present, the advisory is an authentication event, not just a software update, and revocation becomes mandatory.

Q: Who is accountable when a trusted dependency steals build-time secrets?

A: Accountability is shared across application owners, platform teams, and identity governance. Application teams own dependency review, platform teams own runner hardening, and identity teams own the scope and lifetime of the credentials exposed to those environments. If the same secrets are available everywhere, ownership has not been translated into control.

Technical breakdown

Import-time execution turns package trust into a runtime access path

The key mechanism here is module-scope code execution. In Python, importing a package can execute statements before application logic starts, which means malicious code does not need an installer hook or post-install script. In this case, the package downloaded a second-stage payload from a Linux-specific branch, then launched it in a detached process so the payload could survive the importing session. That pattern defeats controls focused only on build-time scanning or setup.py review because the execution point is the import itself.

Practical implication: inspect imported dependencies as execution surfaces, not just build artefacts, and block unreviewed package promotion into trusted runtimes.

Second-stage payloads can harvest cloud and developer identities at host scope

The second stage behaved like a credential collector rather than a simple downloader. It enumerated cloud provider credentials, Kubernetes config, Vault tokens, SSH keys, registry tokens, shell history, and local configuration files tied to developer tools. That host-scope approach matters because one compromised CI runner or workstation may hold multiple identity types at once, including human credentials, workload credentials, and secrets used by automation. The result is identity sprawl inside a single endpoint rather than a single application.

Practical implication: treat CI runners and developer workstations as high-value identity hosts and reduce readable secret density on each system.

Propagation and persistence extend the blast radius beyond the first host

Public analysis describes follow-on behaviour that uses valid credentials for cloud and Kubernetes movement, then attempts persistence through disguised systemd services. This is a familiar supply-chain pattern: once the payload finds a privileged identity, it can pivot from local exfiltration to broader environment access. The important control gap is not just package verification but the absence of segmentation between package execution environments and the identities those environments can reach.

Practical implication: separate build-time, test-time, and runtime identities so a malicious import cannot reuse broad cloud or cluster privileges.

Threat narrative

Attacker objective: The attacker aimed to harvest high-value identities from trusted Linux hosts and use them to extend access into cloud, container, and software delivery environments.

1. Entry occurred when malicious durabletask releases were published to PyPI and imported by Linux systems using affected versions.
2. Escalation happened as the imported module downloaded a second-stage payload and harvested cloud, registry, SSH, and Kubernetes credentials from the host.
3. Impact followed through credential reuse, cloud and cluster propagation, and persistence mechanisms that could expand compromise across CI, containers, and developer systems.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Import-time package execution is now an identity threat, not just a software integrity issue. The durabletask case shows that a trusted dependency can reach cloud and workload credentials before the application has any chance to constrain access. That collapses the old assumption that package installation is the main trust boundary. For identity teams, the real boundary is whether imported code can inherit secrets and privileges from the host. Practitioners should treat dependency import paths as part of identity governance, not only secure development.

Host-level secret density creates a non-human identity exposure multiplier. The payload targeted AWS, Azure, GCP, Kubernetes, Vault, Docker, SSH, npm, and PyPI access from one Linux machine, which is exactly how machine identities accumulate risk in CI and developer workflows. This is where OWASP NHI concerns about secret sprawl and overprivilege become operational, because one compromised workload host can surface many identity classes at once. The practitioner takeaway is simple: reduce secret concentration before you reduce package risk.

Package publishing compromise now sits in the same threat model as credential theft. The malicious release bypassed normal source integrity expectations by using a compromised PyPI token and directly uploaded artifacts. That means publishing identity, not just code review, is part of the control plane. Frameworks such as NIST SP 800-53 and OWASP NHI matter here because authenticator management, least privilege, and secret lifecycle controls all shape whether a compromised publish token becomes an enterprise breach.

Ephemeral execution environments still need durable identity controls. CI jobs, Azure Functions hosts, containers, and short-lived build runners are often treated as disposable, but the identities they can reach are not disposable. Once a short-lived runtime inherits broad access, the attacker gains a durable path even if the host disappears. Teams should therefore align ephemeral compute with ephemeral privilege, not with broad inherited secrets.

Named concept: import-time credential harvesting. This incident illustrates a specific failure mode where malicious dependency code executes during import and immediately searches for host-accessible identities. That concept is more precise than generic supply-chain risk because it captures the timing, scope, and identity impact of the compromise. Practitioners should use it to separate package provenance controls from runtime secret containment decisions.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• From our research: 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to The 2024 Non-Human Identity Security Report.
• This pattern makes the Secret Sprawl Challenge more relevant, because exposed package imports can reveal far more secrets than teams expect.

What this signals

Import-time execution creates a control gap between software supply-chain assurance and identity containment. Teams that only verify package provenance are missing the more important question: what identities can the runtime inherit if a dependency turns malicious? That is why controls aligned to OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls need to be considered together.

The practical signal for practitioners is a shift from secrets inventory to secrets containment. If build agents, containers, or function hosts can read multiple credential stores, the programme is already operating with excessive blast radius. The next maturity step is to tie workload identity to execution context so imported code cannot reach unrelated secrets.

Import-time credential harvesting is a useful concept for threat modelling because it captures the exact moment when trusted code becomes a secret discovery tool. Once teams name that failure mode, they can test for it explicitly in Python, container, and CI environments rather than treating all dependency compromise as the same class of event.

For practitioners

• Audit dependency import paths in high-trust Python environments Review code that imports third-party packages inside CI runners, build agents, Azure Functions, and internal services. Focus on packages that execute module-scope logic or touch the filesystem, network, or subprocess APIs during import.
• Reduce secret density on Linux build hosts Remove readable AWS, Azure, GCP, Vault, SSH, registry, and Kubernetes credentials from hosts that execute untrusted or semi-trusted Python code. Use short-lived identities and host-specific access boundaries so one import cannot expose multiple identity domains.
• Enforce provenance and pinning for Python packages Require hash-pinned dependencies, trusted publishing controls, and review gates for new versions before promotion to production or shared CI. Package installation alone is not a sufficient trust signal when malicious code can execute at import time.
• Separate build identities from runtime identities Use different service principals, workload identities, or tokens for build, test, and production execution. If a build host is compromised, the attacker should not inherit the same permissions that production workloads use to reach cloud or cluster resources.
• Hunt for import-time compromise indicators Search for the affected durabletask versions, detached python3 processes, /tmp/managed.pyz, unexpected systemd services, and outbound connections to the listed C2 domains. On Linux hosts where the package was imported, rotate any reachable secrets from a known-clean machine.

Key takeaways

• This compromise shows that a trusted Python dependency can become an execution path for secret theft the moment it is imported.
• The exposed blast radius spans cloud, Kubernetes, registry, SSH, and developer-tool identities, which is why host-level containment matters.
• The decisive control is not only package verification but short-lived, segmented access that prevents imported code from inheriting broad secrets.

Key terms

• Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
• Host-Scope Secret Exposure: The condition where a compromise can access every readable secret on a machine, not just one application’s credential set. This matters for CI runners, containers, and developer workstations because identity sprawl often concentrates many tokens and keys on a single host.
• Publishing Identity: The account, token, or credential set that authorises changes to a software package distribution channel. It is a privileged non-human identity because it can affect many downstream systems at once, so compromise of this identity can become an ecosystem-wide security event.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Package indicators, artifact hashes, and runtime IOCs for durabletask 1.4.1 through 1.4.3
• The full Linux-only payload behaviour, including anti-analysis checks and download chain
• Provider-specific credential harvesting paths across AWS, Azure, GCP, Kubernetes, and Vault
• Concrete remediation steps for CI runners, developer workstations, and container images

👉 Corgea's full post covers the import-time kill chain, credential scope, and remediation workflow in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity practitioners align runtime access with the controls that reduce secret exposure and lateral movement.