What IT managers need to know — and what to do about it
A single stolen developer token can give an attacker full control of your cloud infrastructure in under 72 hours — without triggering a single MFA prompt.
This is not a hypothetical. In its H1 2026 Cloud Threat Horizons Report, Google’s Mandiant team documented a real-world breach in which threat actor group UNC6426 used a compromised developer token to escalate from a poisoned open-source package to full AWS administrator access in less than 72 hours. The victim had no warning. Their cloud logs showed only valid, trusted activity.
This article explains how these attacks work and what your organization needs to do.
The Core Problem: Automated Trust Creates Unintended Pathways
Development teams use CI/CD tools — platforms like GitHub, GitLab, or Azure DevOps — to build and deploy software automatically. These tools connect to cloud platforms such as AWS, Google Cloud, and Azure using a standard called OpenID Connect (OIDC), a protocol for cloud identity federation that allows one trusted system to vouch for another.
The result is a shortcut: when a pipeline runs, the cloud platform sees a valid identity coming from a trusted system and issues cloud credentials automatically — no password, no MFA, no human involved.
When these trust relationships are configured too permissively — as Google’s research finds is common — they become a direct path for attackers. One compromised developer credential becomes a master key to your cloud environment.
In plain terms: a stolen side-door key convinces the security guard to open every door in the building.
A Real Attack: From NPM Package to Cloud Admin in 72 Hours
The Mandiant-investigated UNC6426 case is worth examining in detail because it illustrates exactly how this attack chain plays out in practice.
Phase 1 — Supply Chain Infection
- Attackers injected a credential-stealing script called QUIETVAULT into QUIETVAULT, a popular open-source NPM package used by developers. When developers installed or updated the package, the script ran silently and exfiltrated environment variables — including a GitHub personal access token.
Phase 2 — Token Theft
- QUIETVAULT captured the developer’s GitHub token and sent it to the attackers.
Phase 3 — Abusing OIDC Trust
- The attackers used the stolen GitHub token to trigger a CI/CD pipeline. Because GitHub was a trusted identity source for the victim’s AWS environment via OIDC, AWS automatically issued temporary cloud credentials.
Phase 4 — Privilege Escalation
- The initial cloud role had overly broad permissions. The attackers used it to create a new administrator role for themselves.
Phase 5 — Impact
- Within 72 hours of the initial token theft, the attackers had full AWS admin access. They exfiltrated files from S3 buckets and then destroyed production data.
Source: Google Cloud Threat Horizons Report H1 2026, Mandiant / GTIG (published March 2026)
Two More Common Variations
Scenario 2: Compromised GitLab Account → Google Cloud Access
A GitLab account is compromised via phishing. The attacker triggers a pipeline that automatically requests Google Cloud credentials. Because the pipeline is a trusted identity source, Google Cloud issues access — which the attacker escalates to admin.
In plain terms: the attacker submits a fake work order and the system accepts it because it trusts the machine that sent it.
Scenario 3: Infected Developer Laptop → Azure Control
Malware on a developer’s laptop steals an Azure DevOps token. Azure DevOps uses OIDC to assert a trusted identity to Azure Cloud. Azure issues credentials, and the attacker escalates to full control.
In plain terms: the attacker uses the developer’s ID badge and the cloud accepts it without question.
What IT Managers Need to Know
1. Developers are now your highest-value targets
It is easier to compromise a developer’s laptop or steal a pipeline token than to attack a cloud tenant directly. Developer credentials and pipeline configurations are the fastest route to high-privilege cloud access. Google’s threat research consistently highlights developer endpoints as a primary initial access vector.
2. The risk comes from the entire trust chain, not just the token
A stolen token alone does limited damage. The real danger is the chain of automated trust that connects developer tools to cloud platforms. When that chain is too permissive, attackers can move from a single credential to full admin access in hours.
3. The escalation path is built into your existing workflows
Attackers do not need to break any security controls. They simply activate the automation your organization already uses. The attack looks like normal CI/CD activity.
4. MFA does not protect against this category of attack
By the time a token is in use, authentication has already happened. OIDC trusts the CI/CD tool — not the individual person. Cloud platforms issue temporary credentials without any MFA prompt.
5. Detection is difficult by design
Cloud logs record valid identity usage. OIDC role assumptions are often not monitored. Temporary credentials look identical to legitimate automation. In the UNC6426 case, standard monitoring did not flag the attack.
6. The attack surface grows with every new pipeline
Each new CI/CD workflow creates new tokens, roles, and trust relationships. Google’s threat data shows that software supply chain attacks are increasing in both frequency and impact, a trend expected to continue through 2026.
A Practical Framework for Protection
These are the six steps most likely to reduce your exposure, in priority order.
1. Audit all OIDC trust relationships this week
Most organizations find misconfigured or forgotten trust relationships they did not know existed. Start by mapping every automated identity path between your CI/CD systems and cloud platforms. This is the highest-priority action.
2. Apply least privilege to every automation role
Pipelines should receive only the permissions they absolutely require for their specific task — nothing more. Overly broad roles are what transform a stolen token into an admin compromise.
3. Shorten token and credential lifespans
Use the shortest acceptable validity period for all tokens and temporary credentials. A token that expires in 15 minutes causes far less damage than one that lasts 24 hours.
4. Strengthen developer endpoint security
Since developers are the primary target, endpoint protection, device patching, and identity safeguards on developer machines deserve the same investment as server security.
5. Add monitoring for OIDC and pipeline activity
Set alerts for pipeline triggers outside business hours, unusual OIDC role assumptions, new administrator role creation, and temporary credentials accessing sensitive resources.
6. Conduct regular CI/CD security reviews
Scan periodically for over-permissioned roles, unused trust relationships, and pipeline tokens that are broader in scope than needed. Treat these reviews as routine hygiene, not one-time exercises.
Moving Forward
These attacks succeed because the automated trust relationships that make modern cloud development fast were never designed with today’s threat landscape in mind. The good news is that the fixes are known and achievable — they require prioritization, not new technology.
As Google’s H1 2026 threat data makes clear, the window between a vulnerability being exploited and widespread damage is now measured in hours, not weeks. The organizations that fare best are those that have already hardened their identity infrastructure before an attack occurs — not those scrambling to respond after one.
Start with your OIDC trust relationships. Most organizations find a problem they did not know they had.
Explore Tecnet’s Cybersecurity solutions designed for organizations of all sizes. and learn how we can help you stay protected. Contact us today to book a Tecnet cybersecurity assessment to map your current environment, identify your highest-risk gaps, and get a clear starting point.
References
- Google Cloud Threat Horizons Report H1 2026, Mandiant / Google Threat Intelligence Group (GTIG). Published March 2026. https://cloud.google.com/security/report/resources/cloud-threat-horizons-report-h1-2026
- Google Cloud Threat Horizons Report H2 2025, Google Cloud Office of the CISO / GTIG. https://cloud.google.com/security/report/resources/cloud-threat-horizons-report-h2-2025
- Cloud CISO Perspectives: New Threat Horizons Report Highlights Current Cloud Threats, Google Cloud Blog, March 2026. https://cloud.google.com/blog/products/identity-security/cloud-ciso-perspectives-new-threat-horizons-report-highlights-current-cloud-threats