A critical flaw in the @hulumi/policies npm package lets wildcard GitHub Actions OIDC subject conditions slip past security guardrails through the use of set-qualified AWS IAM condition operators.
What Is It
Versions of @hulumi/policies before 1.3.2 fail to properly validate set-qualified AWS IAM condition operators in GitHub OIDC trust policies. A ForAnyValue:StringLike operator can conceal wildcard GitHub Actions OIDC subject conditions from the package's security guardrails; the policy passes review while, in practice, permitting far broader OIDC subjects than intended.
Exploitation is not remote in the ordinary sense. The attack path requires that someone author or influence the trust policy that the package validates; for example, through commit or pull-request access to the infrastructure-as-code repository where the policy is defined, or by supplying policy content that a pipeline feeds to the validator. The bypass is what allows that policy to survive review; it does not by itself grant an outside party a way to reach the validator.
The issue is classified as CWE-284 (Improper Access Control). It carries a CVSS v3.1 base score of 9.8 (CRITICAL) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and a CVSS v4.0 score of 9.3 (CRITICAL). The CVE was published 2026-08-31 by VulnCheck as the assigning source. Note that the PR:N and AV:N metrics sit uneasily with the precondition described above; the scoring is likely more severe than the realistic access requirements warrant.
Why It Matters
Guardrails intended to catch overly permissive OIDC trust relationships can be defeated by operator choice alone. A trust policy that appears constrained to a specific repository or branch may in fact match a much wider set of GitHub Actions workflows. Because these guardrails exist specifically to prevent unauthorized assumption of AWS roles from CI, a bypass undermines the control at exactly the point it is relied upon, and it does so quietly, since the reviewed artifact looks correct.
The realistic threat model is an insider or a contributor whose change reaches the policy definition, or a compromised upstream that supplies policy content. Organizations that treat validator approval as the sole gate on OIDC trust configuration should assume that gate was not enforcing what they believed.
CISA KEV does not list this CVE. There is no confirmation of active exploitation and no KEV-mandated remediation deadline.
What's Vulnerable
- Vendor: hulumi
- Product:
policies(pkg:npm/hulumi/policies) - Affected: all versions before 1.3.2 (semver)
- Unaffected: 1.3.2 and later
No CPE entries were listed in the NVD record at time of writing. NVD status is "Received," meaning the record has not yet completed analysis.
Patch Status
Version 1.3.2 is marked unaffected. Upgrading @hulumi/policies to 1.3.2 or later is the remediation indicated by the vendor data. Consult the linked GitHub Security Advisory and VulnCheck advisory for vendor guidance.
Because the flaw permits previously-approved policies to carry conditions the validator never actually enforced, upgrading alone is insufficient. Audit existing IAM trust policies for ForAnyValue: and ForAllValues: qualifiers on GitHub OIDC subject conditions, and confirm that the effective subject match is as narrow as intended.
Sources
- NVD, CVE-2026-82856: https://nvd.nist.gov/vuln/detail/CVE-2026-82856
- GitHub Security Advisory GHSA-q2f7-m237-v562: https://github.com/kerberosmansour/hulumi/security/advisories/GHSA-q2f7-m237-v562
- VulnCheck Advisory: https://www.vulncheck.com/advisories/hulumi-policies-before-1.3.2-oidc-trust-policy-bypass
- CISA Known Exploited Vulnerabilities Catalog (searchable; no entry for CVE-2026-82856): https://www.cisa.gov/known-exploited-vulnerabilities-catalog