UNC6426 Exploits nx npm Supply-Chain Attack to Gain AWS Admin Access in 72 Hours
Summary:
The Google Cloud Threat Horizons Report H1 2026 details a sophisticated supply chain attack that underscores the speed and automation of modern cloud breaches. The incident, attributed to the threat actor UNC6426, began with the distribution of a malicious npm package designed to execute upon installation on a developer's local workstation. Once the developer installed the package, it automatically harvested a GitHub Personal Access Token (PAT) stored in the local environment. Using AI-assisted tools to rapidly parse codebase history and environment variables, the attacker identified a high-value CI/CD pipeline configuration.
The critical pivot occurred when the attacker utilized the stolen GitHub credentials to impersonate the developer and trigger a workflow that leveraged OpenID Connect (OIDC). Because the organization had established a trust relationship between GitHub and their Amazon Web Services (AWS) environment, the attacker was able to exchange a GitHub-issued identity token for short-lived AWS IAM credentials with administrative privileges. This "keyless" authentication, while intended to be more secure than hardcoded keys, was exploited because the trust policy was overly permissive. In less than 72 hours from the initial workstation infection, the attacker performed automated reconnaissance of the cloud environment, identified and exfiltrated terabytes of sensitive data from S3 buckets, and concluded the operation by executing a "scorched earth" script that deleted the organization’s production infrastructure, including compute instances and database backups.
Security Officer Comments:
This case study highlights a fundamental shift in the "blast radius" of a single developer compromise. In traditional environments, a compromised workstation might lead to local data theft; in a modern cloud-native environment, it serves as a direct bridge to the entire production backbone. The speed of this breach (under three days) suggests that threat actors are now using automation and LLM-assisted analysis to bypass the "learning curve" typically required to understand a victim's unique architecture.
The takeaway is that OIDC is not a "set it and forget it" security solution. While it eliminates the risk of leaked static keys, it creates a "transitive trust" risk where a compromise in your CI/CD provider (GitHub/GitLab) is equivalent to a compromise of your Cloud Service Provider (AWS/GCP/Azure). Our members must recognize that identity is the new perimeter, and if the "claims" within an OIDC token are not scoped to specific repositories or branches, any developer with code-push access effectively holds the keys to the kingdom.
Suggested Corrections:
To defend against OIDC-based pivots and supply chain disruptions, organizations should adopt the following technical and procedural safeguards:
Link(s):
https://thehackernews.com/2026/03/unc6426-exploits-nx-npm-supply-chain.html
The Google Cloud Threat Horizons Report H1 2026 details a sophisticated supply chain attack that underscores the speed and automation of modern cloud breaches. The incident, attributed to the threat actor UNC6426, began with the distribution of a malicious npm package designed to execute upon installation on a developer's local workstation. Once the developer installed the package, it automatically harvested a GitHub Personal Access Token (PAT) stored in the local environment. Using AI-assisted tools to rapidly parse codebase history and environment variables, the attacker identified a high-value CI/CD pipeline configuration.
The critical pivot occurred when the attacker utilized the stolen GitHub credentials to impersonate the developer and trigger a workflow that leveraged OpenID Connect (OIDC). Because the organization had established a trust relationship between GitHub and their Amazon Web Services (AWS) environment, the attacker was able to exchange a GitHub-issued identity token for short-lived AWS IAM credentials with administrative privileges. This "keyless" authentication, while intended to be more secure than hardcoded keys, was exploited because the trust policy was overly permissive. In less than 72 hours from the initial workstation infection, the attacker performed automated reconnaissance of the cloud environment, identified and exfiltrated terabytes of sensitive data from S3 buckets, and concluded the operation by executing a "scorched earth" script that deleted the organization’s production infrastructure, including compute instances and database backups.
Security Officer Comments:
This case study highlights a fundamental shift in the "blast radius" of a single developer compromise. In traditional environments, a compromised workstation might lead to local data theft; in a modern cloud-native environment, it serves as a direct bridge to the entire production backbone. The speed of this breach (under three days) suggests that threat actors are now using automation and LLM-assisted analysis to bypass the "learning curve" typically required to understand a victim's unique architecture.
The takeaway is that OIDC is not a "set it and forget it" security solution. While it eliminates the risk of leaked static keys, it creates a "transitive trust" risk where a compromise in your CI/CD provider (GitHub/GitLab) is equivalent to a compromise of your Cloud Service Provider (AWS/GCP/Azure). Our members must recognize that identity is the new perimeter, and if the "claims" within an OIDC token are not scoped to specific repositories or branches, any developer with code-push access effectively holds the keys to the kingdom.
Suggested Corrections:
To defend against OIDC-based pivots and supply chain disruptions, organizations should adopt the following technical and procedural safeguards:
- Restrict OIDC Trust Policies: Do not allow any token from a trusted provider (like GitHub) to assume a role. Use "Conditional Claims" to ensure the token must originate from a specific repository ID, a specific environment, or a specific signed Git tag.
- Software Supply Chain Security: Implement "Dependency Confusion" protection and use private package mirrors (like Artifactory or GitHub Packages) that scan for malicious "postinstall" scripts before allowing a package to be downloaded to a developer's machine.
- Enforce Fine-Grained Tokens: Mandate the use of GitHub Fine-Grained PATs which have expiration dates and are scoped to specific repositories, rather than "Classic" tokens that often grant broad access to an entire organization's source code.
- Implement Cloud "Guardrails": Utilize Service Control Policies (SCPs) or Organization Policy Constraints to prevent the deletion of critical resources (like backups or core networking) without secondary approval or "MFA Delete" requirements, preventing the "scorched earth" scenario seen in this breach.
- Behavioral Monitoring: Configure alerts for "Identity Provider (IdP) pivoting," specifically looking for instances where a CI/CD role performs actions outside of its normal deployment patterns, such as bulk data exfiltration or massive resource deletion.
Link(s):
https://thehackernews.com/2026/03/unc6426-exploits-nx-npm-supply-chain.html