What Happened
In August 2025, threat actor UNC6426 compromised the nx npm package, gaining full AWS administrator access within 72 hours. The attack began with a vulnerable pull_request_target workflow in the nx repository, allowing the attacker to steal GitHub tokens. UNC6426 exploited OIDC trust relationships between GitHub Actions and AWS to create new administrator roles, exfiltrate data, and destroy evidence.
This attack was not a sophisticated zero-day exploit but a methodical exploitation of overly permissive IAM configurations and weak CI/CD security controls.
Timeline
Hour 0-24: The attacker exploited the vulnerable GitHub Actions workflow to steal authentication tokens with write access to the nx repository.
Hour 24-48: Using stolen tokens, UNC6426 exploited the existing OIDC trust configuration between GitHub Actions and AWS. This trust relationship allowed any workflow in the repository to assume AWS roles without additional authentication.
Hour 48-72: The attacker created new IAM roles with administrator privileges, moved laterally across the AWS environment, exfiltrated sensitive data, and began destroying logs and resources to cover their tracks.
Which Controls Failed or Were Missing
Overly Permissive OIDC Trust Policies
The OIDC trust relationship allowed any GitHub Actions workflow from the repository to assume AWS roles. There were no conditions limiting which specific workflows, branches, or events could trigger the assumption. Properly scoped trust policies would have restricted role assumption to specific workflow files running on protected branches.
No Least Privilege Enforcement
The roles that GitHub Actions could assume had permissions far beyond what CI/CD workflows needed. Instead of read-only access to specific S3 buckets or limited deployment permissions, the configuration allowed role creation and privilege escalation.
Missing Anomaly Detection
The creation of new administrator roles within 72 hours of initial access should have triggered immediate alerts. No monitoring was in place to detect unusual IAM activity patterns, such as role creation from unfamiliar sources or privilege escalation outside normal change windows.
Vulnerable CI/CD Configuration
The pull_request_target workflow trigger is dangerous because it runs in the context of the base branch with access to repository secrets, even when triggered by external contributors. The nx repository used this trigger without additional security controls to validate the source of pull requests.
What the Relevant Standards Require
NIST 800-53 Rev 5 AC-6 (Least Privilege)
This control requires organizations to employ the principle of least privilege, allowing only authorized accesses necessary to accomplish assigned tasks. The AWS roles in this incident violated AC-6 by granting broad administrative permissions to automated workflows that only needed narrow deployment capabilities.
ISO/IEC 27001:2022 A.9.2.3 (Management of Privileged Access Rights)
This control mandates that allocation and use of privileged access rights be restricted and controlled. Creating new administrator roles should require approval workflows, time-bound access, and immediate notification to security teams. None of these controls were present.
NIST CSF v2.0 PR.AC-4
Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties. The OIDC trust configuration failed this requirement by not implementing conditions that would restrict which workflows could assume which roles.
PCI DSS v4.0.1 Requirement 7.2.2
Access is assigned based on job classification and function, and least privilege is applied. While this requirement targets payment environments specifically, the principle applies to any privileged access management. The GitHub Actions workflows had access to create administrator roles—a capability completely outside their job function of running CI/CD tasks.
Lessons and Action Items for Your Team
Scope Your OIDC Trust Policies
Review every OIDC trust relationship between your CI/CD platform and cloud provider. Add conditions that restrict role assumption to specific workflow files, branches, and event types. For GitHub Actions to AWS, your trust policy should include conditions like:
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
}
This prevents any workflow outside your main branch from assuming the role.
Audit Role Permissions Against Actual Usage
Map what your CI/CD workflows actually do, then reduce role permissions to match. If a deployment workflow only writes to three S3 buckets and updates two Lambda functions, the role should have s3:PutObject on those specific buckets and lambda:UpdateFunctionCode on those specific functions—nothing more. Remove all iam:* permissions from automation roles unless you have a documented reason for workflows to manage IAM.
Implement IAM Activity Monitoring
Set up CloudWatch or equivalent monitoring to alert on:
- New IAM role or user creation
- Changes to role trust policies
- Assumption of roles from unexpected sources
- Any IAM action taken by service accounts outside their normal pattern
These alerts should trigger within minutes, not hours.
Harden Your GitHub Actions Workflows
Never use pull_request_target unless you absolutely need to run untrusted code with access to secrets. If you must use it, add explicit checks that validate the pull request source before running any sensitive operations. Better: use pull_request for external contributions and keep secrets out of those workflows entirely.
Require Approval for Privileged Changes
Configure your cloud environment to require manual approval for any IAM change that creates new roles, modifies trust policies, or grants administrator permissions. This won't stop a determined attacker who already has admin access, but it creates a checkpoint before automated processes can escalate privileges.
The 72-hour window in this attack wasn't inevitable. Each phase depended on controls that should have been in place but weren't. Fix your OIDC trust policies this week. Audit your automation role permissions next week. Implement IAM monitoring the week after. The attacker moved fast because nothing slowed them down.
