Sub:jugation is a namespace-reuse attack pattern against OIDC federation in CI/CD systems. An attacker reclaims a deleted or renamed namespace, reproduces the expected subject claim, and satisfies an existing cloud trust policy without needing to steal the original token.
What Sub:jugation Means in OIDC Federation
Sub:jugation is a namespace-reuse attack pattern against OIDC federation in CI/CD systems. It works when an attacker can reclaim a deleted or renamed namespace and present the same subject claim that a trust policy already expects.
How Namespace Reuse Breaks Federated Trust
In a healthy OIDC federation design, the cloud side treats the issuer, subject claim, and other claims as a trust boundary. Sub:jugation exploits the fact that a namespace name is often reused as part of the sub value, so the policy can be satisfied by a different actor if the original namespace is no longer exclusively controlled.
This is why the pattern is especially relevant in CI/CD, where namespaces, projects, repositories, or deployment contexts can be deleted, recreated, or transferred. If the trust policy keys too heavily on a stable string rather than on durable ownership or tighter claim conditions, the federation relationship can be inherited by the wrong party.
Why Sub:jugation Matters Operationally
Sub:jugation is not token theft in the usual sense. The attacker does not need to intercept the original token if they can recreate the expected identity context and let the federation system issue fresh access under an old assumption.
That makes the pattern a trust persistence problem as much as an access problem. The security failure is in the lifecycle of the external namespace and the cloud policy that continues to trust it after ownership changes.
Typical Failure Conditions and Defenses
The pattern usually appears when namespace ownership can change faster than federation trust policy updates. Weak claim binding, broad subject patterns, and insufficient lifecycle controls around deleted or renamed projects make it easier for an attacker to reuse a previously trusted subject.
- Tie trust to claims that are harder to impersonate than a reusable namespace label.
- Review federation conditions whenever namespaces, repositories, or tenant names are deleted, renamed, or transferred.
- Prefer explicit issuer and audience constraints, plus narrow subject matching, over generic wildcard trust.
- Validate that cloud trust policies are revoked or updated when the original owning context changes.
Risk and Threat Considerations
Sub:jugation can let an attacker gain federated cloud access without stealing secrets, because the attack abuses a stale trust assumption rather than compromising the original workload. The main exposure is unauthorized issuance of fresh credentials or tokens to an entity that only looks legitimate because it reused the same namespace.
Failure mechanism: A trust policy continues to accept a subject claim after the original namespace is deleted or renamed, and a new actor reclaims that namespace to satisfy the same federation rule.
Impact: Cloud roles, deployment permissions, or automation privileges can be obtained by an unintended party, creating unauthorized code execution, infrastructure changes, or lateral access into CI/CD and connected cloud assets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Federated access depends on managed authentication material and claim-bound trust. |
| AC-2 — Account Management | Namespace reuse is an account and lifecycle governance failure across trusted identities. | |
| AC-6 — Least Privilege | A reused subject should not inherit broad cloud permissions beyond the minimum needed. | |
| Recommendation — Review federation trust conditions when authentication material or subject ownership changes. Revoke or reassess cloud access when the underlying namespace or account lifecycle changes. Limit federated roles so a compromised trust path cannot expand into broad cloud access. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | The attack is an authorization failure where an untrusted actor can reach protected functions. |
| Recommendation — Narrow authorization rules so recreated subjects cannot reach privileged functions. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and Credentials | Federated trust is grounded in identity and credential assurance for access decisions. |
| Recommendation — Map federated subject claims to trusted identity ownership and review them on lifecycle change. | ||
Practitioner Guidance
What to watch for: Treat namespace deletion, rename, transfer, and account or repository recycling as security-relevant events, not just administrative housekeeping. Those events can change who can legitimately present the claim string your trust policy depends on.
Governance implication: Federation policies need lifecycle ownership. The teams managing cloud trust, CI/CD namespaces, and identity boundaries should have a shared review process so that a reusable subject value does not outlive the entity it was meant to represent.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org