One Stolen npm Token Gave Hackers Full AWS Admin Access in 72 Hours

From a Package Update to Total Compromise

It started with a routine package update. Somewhere inside a development team, an engineer's code editor refreshed the Nx Console plugin, pulling in what appeared to be a normal update to the widely used Nx build framework. But the update was poisoned. Within 72 hours, the attacker behind that poisoned package had full administrator access to the company's entire AWS environment, had terminated production databases, wiped servers, and made every internal code repository public on GitHub.

The attack, attributed by Google to a threat actor designated UNC6426, is one of the most detailed and alarming supply chain compromises documented in recent years. It demonstrates how a single stolen credential, extracted through a tampered open source dependency, can cascade through layers of trust to produce catastrophic damage.

Stage One: Poisoning the Build Tool

UNC6426 began by exploiting a vulnerable pull_request_target workflow in the Nx npm repository, a technique known as a Pwn Request attack. This gave the attacker elevated privileges within the repository's CI/CD pipeline, which they used to push trojanized versions of Nx packages to the npm registry.

The compromised packages contained a postinstall script that executed a piece of malware called QUIETVAULT. Described by researchers as a JavaScript credential stealer, QUIETVAULT weaponized an existing LLM tool to scan the developer's environment for sensitive data: environment variables, system information, and most critically, GitHub Personal Access Tokens.

Google classified the technique as "AI assisted supply chain abuse," noting that "malicious intent is expressed in natural language prompts rather than explicit network callbacks or hardcoded endpoints, complicating conventional detection approaches."

Stage Two: Extracting CI/CD Secrets

Once QUIETVAULT captured a developer's GitHub PAT, the stolen credentials were uploaded to a public GitHub repository the attacker controlled, named /s1ngularity-repository-1. With the token in hand, UNC6426 deployed Nord Stream, an open source utility designed to extract secrets from CI/CD environments.

Nord Stream allowed the attacker to leak credentials for a GitHub service account with broader access. More importantly, the tool's --aws-role parameter enabled the generation of temporary AWS Security Token Service (STS) tokens by exploiting OpenID Connect trust relationships between GitHub Actions and AWS. This gave UNC6426 access to a role called "Actions-CloudFormation."

Stage Three: Escalation to AWS Admin

The Actions-CloudFormation role was the pivot point. It had been configured with overly permissive privileges, a violation of the principle of least privilege that proved devastating. UNC6426 used the role to deploy a new AWS CloudFormation Stack with both CAPABILITY_NAMED_IAM and CAPABILITY_IAM flags, creating a fresh IAM role attached to the arn:aws:iam::aws:policy/AdministratorAccess managed policy.

The result: full AWS administrator permissions in less than 72 hours, starting from nothing more than a tampered npm package.

The Damage

With administrator access to AWS, UNC6426 moved quickly to inflict maximum damage:

• Terminated production EC2 instances and RDS databases, taking live services offline
• Enumerated and accessed S3 bucket contents, exposing stored data
• Decrypted application keys, compromising the cryptographic integrity of the environment
• Renamed every internal GitHub repository to /s1ngularity-repository-[random] and changed their visibility to public, exposing all proprietary source code

The combination of infrastructure destruction and source code exposure represents a worst case scenario for any engineering organization. Recovery from this kind of incident requires rebuilding infrastructure from scratch, rotating every credential and secret, and conducting a thorough audit of what was exposed.

Why Supply Chain Attacks Keep Working

The UNC6426 attack succeeded because it exploited trust at every layer. Developers trust their package managers. CI/CD systems trust GitHub tokens. AWS trusts OIDC federation with GitHub. CloudFormation trusts the roles that invoke it. Each link in this chain was designed for convenience and automation, and each one became an attack surface.

Three specific failures enabled the escalation:

• Excessive CI/CD permissions: The Actions-CloudFormation role could create IAM roles with administrator access, a privilege that should never exist in an automated pipeline
• No guardrails on CloudFormation: There were no Service Control Policies or permission boundaries preventing the creation of overprivileged roles
• Standing trust relationships: The OIDC federation between GitHub and AWS had no additional verification, allowing any workflow with the right token to assume cloud roles

Lessons for Every Engineering Team

This incident is a blueprint for what modern supply chain attacks look like. They do not require zero days or sophisticated exploits. They require patience, a single weak link, and an environment where automated trust has outpaced automated verification.

Engineering teams should audit their CI/CD to AWS trust relationships immediately. Restrict what IAM roles can be created through automation. Implement permission boundaries on every role that CloudFormation can assume. Monitor for unusual STS token generation. And treat every dependency update as a potential attack vector, because as UNC6426 demonstrated, that is exactly what it can be.

The distance from a single poisoned npm package to total infrastructure compromise was 72 hours. And the problem is getting worse: a recent supply chain attack on the Trivy security scanner deployed a self-replicating worm across 47 npm packages using the same pull_request_target misconfiguration. The question every team should ask is whether their own defenses would have caught it in time.