CVE-2026-48032: Hulumi IAM Auth Bypass Vulnerability

CVE-2026-48032 Overview

CVE-2026-48032 affects Hulumi, an open-source toolkit that provisions secure-by-default cloud and platform infrastructure components for Pulumi. Versions prior to 1.4.0 contain a flaw in the Identity and Access Management (IAM) role policy check logic. When a role trusts multiple OpenID Connect (OIDC) providers, the policy validation can be bypassed, allowing untrusted federated identities to assume roles that should be restricted. The maintainers released version 1.4.0 to address the issue.

Critical Impact
Attackers who control a federated identity at a secondary OIDC provider trusted by a Hulumi-provisioned role can bypass policy checks and assume the role, resulting in unauthorized access to cloud resources.

Affected Products

Hulumi versions prior to 1.4.0
Pulumi infrastructure stacks that consume Hulumi IAM-role components
Cloud deployments configured with multi-OIDC-provider trust relationships

Discovery Timeline

2026-07-24 - CVE-2026-48032 published to the National Vulnerability Database (NVD)
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-48032

Vulnerability Analysis

The vulnerability is an authorization bypass rooted in incorrect comparison logic, classified under [CWE-697] Incorrect Comparison. Hulumi's IAM-role components generate trust policies and enforce validation checks against the configured OIDC providers. When a role is declared to trust more than one OIDC provider, the check logic fails to correctly evaluate each trusted issuer against the presented federated token. The result is that a federated principal from one provider can satisfy the check intended for another, effectively bypassing the policy boundary Hulumi is meant to enforce.

Because the flaw resides in the policy-check code path rather than in the underlying cloud provider's IAM engine, cloud-native audit controls may still record the assume-role event as a legitimate federation. This makes downstream detection dependent on identifying anomalous role assumptions rather than on the Hulumi check itself.

Root Cause

The root cause is an incorrect comparison in the multi-provider trust evaluation path. Hulumi validates the presented OIDC token against the set of trusted providers but does not correctly bind provider identity to policy conditions. When multiple providers are trusted by the same role, the check treats them as interchangeable rather than as distinct authorization scopes.

Attack Vector

Exploitation requires an attacker to hold or obtain a valid federated identity at any OIDC provider trusted by the target role. The attacker presents a token from a secondary provider and requests role assumption. The flawed check accepts the token even when the policy intended to restrict role assumption to a different provider. No local access is required; the attack is performed over the network against the cloud provider's federation endpoint.

No verified public exploit code is available. Technical details are documented in the GitHub Security Advisory GHSA-g759-4pxw-6692 and the associated GitHub Pull Request 178.

Detection Methods for CVE-2026-48032

Indicators of Compromise

AssumeRoleWithWebIdentity events where the token issuer does not match the intended OIDC provider for that role
Role assumption events originating from federated identities that have never previously assumed the target role
Cloud API activity from newly assumed roles that deviates from the workload's established baseline

Detection Strategies

Inventory all Hulumi-provisioned IAM roles and flag any role whose trust policy references more than one OIDC provider
Correlate sts:AssumeRoleWithWebIdentity (or equivalent) calls against expected issuer-to-role mappings and alert on mismatches
Compare deployed Hulumi module versions against 1.4.0 across all Pulumi stacks to identify vulnerable infrastructure

Monitoring Recommendations

Enable and centralize cloud provider CloudTrail, Azure Activity Log, or GCP Audit Log ingestion for all federated identity events
Alert on new principals assuming roles that were previously assumed only by a specific OIDC issuer
Track post-assumption API behavior for privilege escalation, data access, or persistence activity

How to Mitigate CVE-2026-48032

Immediate Actions Required

Upgrade all Hulumi installations to version 1.4.0 or later and redeploy affected Pulumi stacks
Audit IAM roles for multi-OIDC-provider trust relationships and remove any provider that is not strictly required
Rotate credentials and review recent role assumption logs for any unexpected federated activity

Patch Information

The issue is fixed in Hulumi version 1.4.0. See the GitHub Release v1.4.0 and the remediation Pull Request 178 for the corrected policy-check logic.

Workarounds

Restructure IAM roles so that each role trusts only a single OIDC provider until the upgrade is complete
Add explicit StringEquals conditions on the token issuer (iss) and subject (sub) claims in trust policies to constrain federation
Apply short session durations and least-privilege permission boundaries to any role trusting multiple OIDC providers

bash

# Configuration example: pin trust policy to a single OIDC issuer and subject
# Replace values with those matching your environment before applying.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Federated": "arn:aws:iam::<account-id>:oidc-provider/<issuer-host>" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<issuer-host>:aud": "<expected-audience>",
          "<issuer-host>:sub": "<expected-subject>"
        }
      }
    }
  ]
}