Malicious packages expose how software trust can fail for $5

At a glance

What this is: Checkmarx shows how a low-cost package hijack can turn software trust into credential theft, with a malicious ctx update used to exfiltrate AWS credentials.

Why it matters: It matters because software supply chain controls, secret handling, and identity governance must assume that trusted packages and maintainers can be compromised without warning.

By the numbers:

• Analysts found that 78% of surveyed organizations reported a breach in the previous year.
• Malicious packages surged 188% year over year, according to Sonatype’s Q2 2025 Open-Source Malware Index cited by Checkmarx.

Context

Software supply chain trust fails when package provenance, maintainer identity, and secret handling are treated as stable by default. In this case, a forgotten domain and a reset maintainer account were enough to turn a legitimate package into a credential-stealing payload.

The identity angle is real because the compromise path ran through account recovery and package publishing trust, not through exploitation of a host or application vulnerability. For IAM and NHI practitioners, this is a lifecycle problem: who can reassert control over a publishing identity, what secrets are exposed during installation, and how quickly malicious artifacts are blocked.

Key questions

Q: What breaks when a package maintainer identity can be recovered through an expired domain?

A: The trust chain breaks at the point where the registry accepts a recovered publishing identity as legitimate. Once an attacker can regain package ownership, they can ship code that consumers will install automatically, so the real failure is governance of publisher identity and recovery paths, not just malware detection after the fact.

Q: Why do malicious packages so often target cloud credentials and secrets?

A: Because installation steps often run in environments where secrets are already present. A malicious package can read environment variables, config files, or CI credentials and exfiltrate them without needing an exploit. That makes secret exposure a supply-chain issue as much as an application security issue.

Q: What are the signs that a dependency compromise may have exposed local secrets?

A: A strong warning sign is a package that runs a preinstall or similar hook and reaches out to an unfamiliar domain. If the package then accesses AWS metadata, reads ~/.aws credentials, inspects .env files, or queries SSH and GitHub state, assume secrets exposure. Unexpected outbound connections during package installation should trigger immediate investigation and containment.

Q: How should teams govern package provenance in software supply chains?

A: Treat publisher identity, recovery controls, and artifact provenance as one control set. Teams should verify who can publish, how ownership can change, and whether the artifact can be traced to that identity before it enters the build path. Checksums alone do not prove trustworthy origin.

Technical breakdown

How package trust breaks during maintainer recovery

Open-source ecosystems often assume that package ownership is durable and that maintainer recovery is an administrative edge case. In practice, package registries rely on identity verification, recovery channels, and ownership metadata that can be reassigned if an attacker regains control of an email domain or account reset path. Once the publishing identity is recovered, the attacker does not need to compromise the codebase itself; they only need to publish a plausible update that consumers will trust. This is why package provenance is an identity problem as much as a code problem.

Practical implication: treat package publisher recovery paths as part of identity governance, not just registry administration.

Why malicious dependencies steal secrets so efficiently

Malicious packages are effective because installation-time execution sits close to developer and CI credentials. Dependency install hooks, post-install scripts, and build steps can inspect environment variables, local config, credential caches, and cloud metadata access paths before defenders have runtime visibility. If AWS credentials, API keys, or tokens are present during install, the package can harvest them immediately and exfiltrate them with little noise. The control gap is not only malware detection, but exposure of secrets to third-party code that runs before trust is validated.

Practical implication: reduce secret availability in build and install paths, and isolate dependency execution from cloud credentials.

What makes software supply chain compromise scale

Package ecosystems amplify small compromises because a single published artifact can propagate through many downstream installs, forks, mirrors, and CI pipelines. That means one hijacked maintainer identity can create a wide blast radius even when each individual consumer has basic scanning in place. The article’s example shows how a cheap domain purchase can become a high-leverage supply chain event when publishing rights, dependency trust, and credential exposure are all weakly governed. In that sense, the real attack surface is the distribution system around the package, not just the package contents.

Practical implication: couple package admission controls with provenance checks and downstream blocking before artifacts reach production.

Threat narrative

Attacker objective: The attacker’s objective was to steal cloud credentials through a trusted package update and gain access to AWS environments.

1. Entry occurred when the attacker bought an expired domain tied to the package maintainer and used it to regain control of the maintainer account on PyPI.
2. Credential access followed when the malicious ctx package was uploaded and executed during installation, allowing it to collect AWS credentials from victim systems.
3. Impact was credential theft that could expose AWS environments and enable follow-on access across downstream cloud resources.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Software trust is now an identity governance problem, not only an AppSec problem. The ctx incident shows that package risk starts with who can assert publishing authority, who can recover it, and what trust the registry grants by default. When maintainer identity can be re-established through an expired domain, the registry becomes a credentialed control plane. Practitioners should treat package publisher lifecycle, not just package scanning, as the primary governance boundary.

Package provenance is the named failure mode here: provenance without verified publisher continuity is brittle. A package can look legitimate while its control of origin has already failed. That means attestations, repository metadata, and update history matter, but only when paired with strong publisher identity and recovery controls. For supply chain governance, the practitioner conclusion is simple: provenance is only as strong as the identity that vouches for it.

Secret exposure windows are the practical attack surface exposed by malicious packages. The package did not need a zero-day because many environments still hand secrets to code during install and build. This is where identity and supply chain controls meet: cloud credentials, tokens, and API keys should not be reachable by untrusted dependency execution. The control priority is to collapse the window in which third-party code can see live secrets.

Open-source scale makes one weak maintainer account a many-to-many risk. A single compromised publishing identity can propagate through countless downstream pipelines, which is why scanning after ingestion is insufficient on its own. The field needs stronger publisher governance, not just faster malware signatures. Practitioners should assume that dependency trust must be continuously re-earned rather than permanently granted.

Malicious package handling should be aligned to NIST CSF and SLSA-style provenance thinking. This is not only about detecting bad code after import, but about controlling how software reaches the build and runtime boundary in the first place. Supply chain integrity and identity assurance are converging concerns, and teams that separate them will keep missing the same attack path. Practitioners should unify publisher identity, provenance, and secret isolation in one control model.

From our research library:

• Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Package provenance now sits inside the identity security problem space. When a maintainer account can be regained through an expired domain, the issue is not just malicious code. It is the governance of who can publish, recover, and reassert control over software that downstream systems trust. Practitioners should harden publishing identity and treat registry ownership changes as security events.

Dependency installs remain one of the easiest places for secrets to leak. The attack works because third-party code often executes before teams have validated it or removed access to live credentials. That means build pipelines need secret minimisation, environment isolation, and stronger controls around where cloud tokens are exposed. Teams that still treat package installation as low risk are preserving the attacker’s easiest path.

Software trust is collapsing into a provenance trust gap. In a supply chain full of forks, mirrors, and automated updates, the real control question is whether an artifact can be tied to a publisher identity that has not been silently re-claimed. Provenance trust gap: a state where software appears legitimate, but the identity backing it is no longer reliably governed. Practitioners should align provenance verification with publisher lifecycle controls, not use it as a standalone gate.

For practitioners

• Strengthen package maintainer recovery controls Require multi-factor recovery, domain-change review, and manual approval for publishing identity changes that affect package ownership or release rights.
• Remove live cloud secrets from install paths Keep AWS credentials, tokens, and API keys out of developer workstations, dependency install contexts, and CI steps that execute third-party code.
• Block untrusted package execution before install Use admission controls and sandboxing so suspicious packages are detonated away from production credentials and network access.
• Verify package provenance beyond checksum matching Require provenance signals that tie artifacts to a trusted publisher identity, not just a name, version, or hash.
• Monitor for secret leakage after dependency updates Add detection for unexpected cloud auth events, new tokens, and post-install network callbacks immediately after package refreshes.

Key takeaways

• A cheap domain purchase and account reset can be enough to turn a trusted package into a credential-stealing payload.
• Malicious packages exploit the moment when install-time code can still reach live cloud secrets and tokens.
• The control boundary is publisher identity, provenance, and secret isolation before dependency execution, not malware detection alone.

Key terms

• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
• 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.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.
• Malicious Package: A malicious package is software published into a legitimate repository but designed to execute harmful code when installed. It abuses normal dependency workflows so that the attacker’s code reaches the environment through trust in the package ecosystem, not through a traditional exploit.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a common framework for controlling trust, issuance, and lifecycle risk.