CVE-2026-48032High▾ Twilight@hulumi/policies bypasses IAM-role policy checks when the role trusts multiple OIDC providers
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 25.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.3%
0.3% → 0.3%
Affected: @hulumi/policies < 1.4.0 — Fixed in: 1.4.0 — Severity: High — CWE-697 (Incorrect Comparison)
AWS IAM trust policies can list more than one federated identity provider — for example, a role that accepts BOTH GitHub Actions OIDC and Google's OIDC. The G_OIDC_1 and G_OIDC_2 policy rules are supposed to flag IAM roles whose GitHub-OIDC trust is too permissive (e.g. wildcard sub: conditions that would let any branch or any pull request assume the role).
The bug: when the role's Principal.Federated field was a JSON array of multiple providers, the rules failed to recognise that GitHub Actions was one of them. The providers list was coerced into a single comma-joined string, the matcher only looked at the start, and the GitHub OIDC hostname was lost in the join. Both rules concluded "this isn't a GitHub-OIDC role" and skipped the wildcard check.
A trust policy that listed the real GitHub OIDC provider ARN alongside any second provider would slip past both detectors. Consumers using HulumiHardeningPack or HulumiGithubHardeningPack could ship an IAM role with wildcard sub: conditions (allowing untrusted PRs from forks to assume the role) while their policy validation reported the stack as compliant. The G_OIDC_2 detector also failed to mark such roles for the cluster-admin / AdministratorAccess blast-radius check.
Upgrade to @hulumi/[email protected]. The shared GitHub-OIDC-provider matcher now correctly walks lists of providers — if any element of the list is the real GitHub OIDC ARN, the role is treated as GitHub-OIDC-assumable and the wildcard / blast-radius checks apply.
None reliable — upgrade is the fix.
packages/policies/tests/github/{g-oidc-2,github-oidc-issuer}.test.ts.@hulumi/policies < 1.4.0Upgrade to a patched release:
@hulumi/policies 1.4.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-48033High@hulumi/policies bypasses policy packs with a forged Pulumi-URN logical name
CVE-2026-48034High@hulumi/policies has a HULUMI-H5 bypass via decoy sibling resources targeting a different bucket
CVE-2026-48035High@hulumi/baseline: AccountFoundation audit-delivery S3 bucket could be silently weakened
CVE-2026-48036High@hulumi/drift: Drift classifier fails open on adapter errors and over-promotes Mixed verdicts
CVE-2026-48037Medium@hulumi/baseline: AccountFoundation reuse paths silently downgrade GuardDuty / Security Hub posture
CVE-2026-50029Medium· 5.3js-toml is a TOML parser for JavaScript, Prior to version 1.1.2, the interpreter checks whether a key already exists in a parser-built container with `if (object[key])` instead of `if (key in object)`