@hulumi/policies CVE-2026-48032

Exploitation requires a specific combination: (1) the victim uses @hulumi/policies < 1.4.0 as its IAM-policy validator, (2) the victim's IAM role trust policy specifies Principal.Federated as a JSON array containing the GitHub Actions OIDC provider ARN alongside at least one other federated provider, (3) the same trust policy contains a permissive wildcard sub: condition (e.g. matching any branch, any PR, or any repository) such that an untrusted GitHub Actions workflow run would satisfy it, and (4) the victim ships the role to production based on the false-clean policy report. The bug does not affect roles whose Federated principal is a single string, nor roles whose sub: condition is already tightly scoped; exploitation is also limited by the attacker's ability to trigger a workflow that runs against the affected role - typically via a fork PR or other untrusted workflow_run context in the victim's repository.

No CVSS vector was published, so attack-vector, complexity, and privilege metrics cannot be quoted directly; the GitHub advisory rates this High. EPSS, KEV, and SSVC data were not provided, indicating no public exploit identified at time of analysis and no confirmed in-the-wild use. The realistic risk is indirect but meaningful: the bug does not itself grant access - it causes a security-validation tool to under-report risky IAM trust policies, so its impact depends on whether downstream consumers (a) actually configure roles that trust multiple OIDC providers and (b) rely on @hulumi/policies as their gating control. Where both conditions hold, a wildcard sub: condition on a GitHub-OIDC-assumable role can be silently shipped, letting any forked-PR workflow assume the role - potentially with AdministratorAccess. Defenders should treat this as a control-failure / detection-gap issue rather than a direct exploitable vulnerability, prioritise upgrade in CI/CD policy pipelines, and audit existing IAM trust policies for multi-provider Federated arrays with wildcard sub: conditions.

An engineer authors an IAM role whose trust policy federates to both the GitHub Actions OIDC provider and a second provider (e.g. Google), with a wildcard sub: condition such as repo:org/*:pull_request; @hulumi/policies < 1.4.0 fails to recognise the role as GitHub-OIDC-assumable and reports the stack as compliant, including missing the AdministratorAccess blast-radius warning. An external contributor then opens a pull request from a fork that triggers a workflow which calls aws-actions/configure-aws-credentials against the role, receives a valid OIDC token matching the wildcard sub:, and assumes the role - gaining whatever permissions (potentially AdministratorAccess) it grants in the target AWS account. No public exploit code is identified at time of analysis, but the technique (forked-PR OIDC abuse against permissive sub: conditions) is well-documented in AWS/GitHub OIDC hardening guidance.