Listen to this Post
The vulnerability resides in how `@hulumi/policies` versions below 1.4.0 parse IAM trust policies that list multiple federated identity providers.
AWS IAM roles can trust several OIDC providers simultaneously – for example, both `arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com` (GitHub Actions) and a Google OIDC provider.
Two policy rules, `G_OIDC_1` and G_OIDC_2, are designed to detect overly permissive GitHub‑OIDC trust configurations, such as a `StringLike` condition with `sub: ` that would allow any GitHub branch or pull request to assume the role.
The bug triggers when the role’s `Principal.Federated` field is a JSON array containing multiple provider ARNs.
In this scenario, the parsing logic incorrectly coerces the entire array into a single comma‑joined string (e.g., "arn:aws:iam::...:oidc-provider/token.actions.githubusercontent.com,arn:aws:iam::...:oidc-provider/accounts.google.com").
The matcher then only inspects the beginning of this concatenated string, looking for the GitHub OIDC hostname.
Because the GitHub ARN appears only at the start before the comma, the check succeeds superficially – but the matcher does not walk through each element of the original array.
More critically, when the GitHub provider is the second element in the array, the joined string no longer starts with the GitHub ARN; the matcher sees a different provider at the beginning and concludes that GitHub OIDC is not present.
As a result, both `G_OIDC_1` and `G_OIDC_2` silently skip their wildcard and blast‑radius checks for any role that includes the real GitHub OIDC provider alongside any additional provider.
An attacker who can influence the trust policy (e.g., through a pull request from a fork) could exploit this to assume an IAM role with `sub: ` conditions, bypassing the intended validation.
The impact is high: consumers using `HulumiHardeningPack` or `HulumiGithubHardeningPack` might deploy non‑compliant roles while their policy validation reports full compliance.
The `G_OIDC_2` detector also fails to flag such roles for the cluster‑admin / `AdministratorAccess` blast‑radius check, widening the potential damage.
The fix in version 1.4.0 replaces the broken string coercion with proper iteration over the `Principal.Federated` array – if any element matches the real GitHub OIDC ARN, the role is correctly treated as GitHub‑OIDC‑assumable.
No reliable workaround exists; upgrading to 1.4.0 is the only complete mitigation.
DailyCVE Form:
Platform: AWS IAM
Version: <1.4.0
Vulnerability: Incorrect comparison
Severity: High
date: 2026-06-10
Prediction: 2026-06-20
What Undercode Say:
Check installed version
npm list @hulumi/policies
Simulate the bug with a multi-provider trust policy
cat > multi-provider-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Federated": [
"arn:aws:iam::111111111111:oidc-provider/accounts.google.com",
"arn:aws:iam::111111111111:oidc-provider/token.actions.githubusercontent.com"
]
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:sub": ""
}
}
}]
}
EOF
Run vulnerable policy check (pre-1.4.0)
npx hulumi-policies validate --policy multi-provider-policy.json
Expected (bug): passes even though wildcard sub is present
Exploit:
1. Craft an IAM trust policy listing a second OIDC provider (e.g., Google) before the GitHub OIDC provider ARN.
2. Include a wildcard `sub` condition for `token.actions.githubusercontent.com:sub`.
- Deploy the role using a vulnerable `@hulumi/policies` version (<1.4.0) for validation.
- The validation incorrectly skips the GitHub‑OIDC check, allowing the role to be created.
- An attacker with GitHub Actions access can assume the role from any branch or PR (including forks) due to the wildcard
sub.
Protection:
– Upgrade immediately to `@hulumi/[email protected]` or later.
– If upgrade is impossible, manually audit any IAM role that has `Principal.Federated` arrays – ensure GitHub OIDC ARN is never paired with another provider unless explicitly intended.
– Use AWS IAM policy simulators or alternative validation tools that correctly parse multi‑provider arrays.
– Enforce CI/CD checks that reject any trust policy containing both “ in `sub` conditions and a GitHub OIDC provider, regardless of array ordering.
Impact:
- Security bypass – Roles with overly permissive GitHub OIDC trust (
sub:) can be deployed undetected. - Privilege escalation – Untrusted GitHub forks or any branch can assume the role, potentially gaining `AdministratorAccess` if the role has high privileges.
- Compliance failure – Hardening packs (
HulumiHardeningPack,HulumiGithubHardeningPack) report false negatives. - Blast radius – `G_OIDC_2` detector does not flag cluster‑admin roles, allowing identity federation risks in production clusters.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
