Which versions of @hulumi/policies are affected by CVE-2026-48032?

A detection bypass in @hulumi/policies prior to version 1.4.0 allows GitHub Actions OIDC roles to ship with overly permissive conditions while the validator falsely reports compliance, potentially…. A patch is available.

How to fix or mitigate CVE-2026-48032?

24 hours: Inventory all deployments of @hulumi/policies and HulumiHardeningPack/HulumiGithubHardeningPack across CI/CD systems. 7 days: Upgrade @hulumi/policies to version 1.4.0 or later and re-validate all GitHub Actions OIDC roles. 30 days: Conduct security audit of all roles previously validated under pre-1.4.0 versions, specifically checking for wildcard sub conditions and administrative access blast-radius.

@hulumi/policies CVE-2026-48032

HIGH

Incorrect Comparison (CWE-697)

2026-06-10 https://github.com/kerberosmansour/hulumi

GHSA-g759-4pxw-6692

Information Disclosure Google

Lifecycle Timeline

Source Code Evidence Fetched

Jun 10, 2026 - 14:14 vuln.today

Analysis Generated

Jun 10, 2026 - 14:14 vuln.today

DescriptionCVE.org

Affected: @hulumi/policies < 1.4.0 - Fixed in: 1.4.0 - Severity: High - CWE-697 (Incorrect Comparison)

Summary

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.

Impact

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.

Patches

Upgrade to @hulumi/policies@1.4.0. 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.

Workarounds

None reliable - upgrade is the fix.

Resources

PR #178 (Cluster A); regression tests at packages/policies/tests/github/{g-oidc-2,github-oidc-issuer}.test.ts.

AnalysisAI

Detection bypass in @hulumi/policies versions prior to 1.4.0 allows IAM trust policies that list multiple OIDC federated providers to evade the G_OIDC_1 and G_OIDC_2 policy checks for GitHub Actions OIDC roles. Consumers of HulumiHardeningPack or HulumiGithubHardeningPack can therefore ship roles with wildcard sub: conditions - assumable by untrusted forked-PR workflows - while the validator falsely reports compliance, including missing the AdministratorAccess blast-radius flag. No public exploit identified at time of analysis, and there is no CISA KEV listing.

Technical ContextAI

The affected component is @hulumi/policies, an npm-distributed policy/linting library (pkg:npm/@hulumi_policies) that evaluates AWS IAM trust policies generated by Pulumi-based Hulumi hardening packs. The root cause is CWE-697 (Incorrect Comparison): when an IAM trust policy's Principal.Federated value is a JSON array (multiple OIDC providers, e.g. GitHub Actions plus Google Workload Identity), the GitHub-OIDC matcher coerced the array into a single comma-joined string and then evaluated only the leading substring, so the GitHub OIDC issuer ARN (token.actions.githubusercontent.com) was not recognised unless it appeared first. As a result, both G_OIDC_1 (wildcard sub: condition detection) and G_OIDC_2 (AdministratorAccess blast-radius check on GitHub-OIDC roles) short-circuited and skipped their substantive checks. The fix in 1.4.0 replaces the string-coerced comparison with an iteration over each element of the providers list.

RemediationAI

Vendor-released patch: @hulumi/policies 1.4.0 - upgrade the npm dependency to 1.4.0 or later (npm install @hulumi/policies@^1.4.0 or equivalent lockfile update), per the GHSA advisory at https://github.com/kerberosmansour/hulumi/security/advisories/GHSA-g759-4pxw-6692 and PR https://github.com/kerberosmansour/hulumi/pull/178. The vendor explicitly states no reliable workaround exists, so if an immediate upgrade is impossible, compensating controls are to manually audit every IAM role trust policy generated or validated by the hardening packs for a Principal.Federated array containing multiple OIDC providers and any wildcard or overly-broad token.actions.githubusercontent.com sub: condition (e.g. repo:*:* or repo:org/*:pull_request), and to tighten the sub: condition to specific repositories, branches, or environments - accepting the operational cost of explicitly enumerating trusted refs. As an additional control, restrict role assumption for forked-PR workflows by gating sensitive workflows behind protected GitHub Environments with required reviewers (the same pattern adopted in the upstream PR).