Topic starter
02/06/2026 8:49 pm
TL;DR: Global OIDC issuers in GitHub Actions, GitLab CI, and Terraform Cloud can let attackers reclaim deleted namespaces and assume stale cloud roles, according to Astrix Security, with 14% of discovered AWS namespaces and 24% of Azure namespaces already unregistered. Identity trust should not outlive the namespace that defines it.
Editorial analysis by NHI Mgmt Group, based on content published by Astrix Security: “Sub:jugation – Hijacking Cloud Identities by Recycling Namespaces in Global OIDC Issuers”.
By the numbers:
- In Azure, the percentage jumps to 24%.
- On average a single deleted namespace had more than 12 different NHIs trusting one of its repositories.
Key questions
Q: What breaks when a CI/CD namespace is deleted but its cloud trust remains?
A: The trust relationship outlives the identity source.
Q: Why do reclaimed OIDC subjects create cloud access risk?
A: Because the cloud provider only sees a matching subject claim, not whether the current namespace owner is the same party that originally configured the trust.
Q: How can security teams tell whether CI/CD OIDC trust is becoming stale?
A: Look for deleted, renamed, or abandoned repositories and organizations that still appear inside cloud trust policies.
Practitioner guidance
- Inventory all roles trusting global OIDC issuers Find every cloud role that trusts token.actions.githubusercontent.com, gitlab.com, or app.terraform.io and map each one to the namespace it depends on.
- Validate namespace ownership before renewal Check whether each repository, user, or organization named in a sub claim is still active and under the expected administrative control.
- Offboard cloud roles when projects end Remove or update every cloud trust policy when a repository, team, or namespace is retired so the stale subject cannot be reused.
Bottom line: The core risk is not secret theft but trust reuse, where a cloud role still accepts an OIDC subject tied to a namespace that no longer has the original owner.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
02/06/2026 8:52 pm
Namespace permanence is now a false assumption in CI/CD trust design: Cloud roles that trust OIDC subjects were designed for namespaces that stay bound to the same owner. That assumption fails when repository names, usernames, or organisations can be released and reclaimed by someone else. The implication is that trust policies built on stable naming alone are already brittle.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should happen when a repository or organization is retired?
A: Every cloud role that trusts that namespace should be reviewed and either removed, retargeted, or revalidated against the new owner. The goal is to prevent a trusted subject from becoming a phantom cloud identity after offboarding.
👉 Read our full editorial: Sub:jugation exposes phantom cloud identities in CI/CD OIDC trust
This post was modified 1 day ago by NHI Mgmt Group