Critical bug in obscure npm tool could let wildcard logins sneak past AWS security checks

A flaw in a niche policy-checking package let attackers hide dangerous wildcard rules from GitHub's cloud login guardrails — but only a small slice of DevOps setups will ever encounter it.

MacBook Pro showing programming language
Photo · Emile Perron / Unsplash

A newly catalogued vulnerability, CVE-2026-82856, has been rated critical by security tracker VulnCheck — but before anyone panics, it’s worth being clear about exactly what it touches and what it doesn’t.

The flaw sits in @hulumi/policies, an npm package used by teams writing AWS security policies as code. Specifically, it affects how the tool checks trust policies that let GitHub Actions workflows log into AWS using OpenID Connect (OIDC), a common way of avoiding long-lived cloud credentials in automated pipelines.

What the bug actually does

According to the GitHub security advisory, versions of @hulumi/policies before 1.3.2 only scanned for exact AWS IAM condition operators — things like StringLike or StringEquals — when checking whether a trust policy safely restricted which GitHub repositories could assume an AWS role.

The problem is that AWS also supports “set-qualified” variants of those operators, such as ForAnyValue:StringLike. Because the older code didn’t recognise these variants, someone could write a trust policy using ForAnyValue:StringLike with a wildcard GitHub Actions “subject” condition, and the tool’s guardrail would simply wave it through as safe. In practice, that could let a far broader set of GitHub repositories or workflows than intended assume a sensitive AWS role.

VulnCheck’s advisory puts a CVSS score of 9.3 on the issue — critical, but not the 9.8 some trackers have quoted — and classifies it under CWE-284, “improper access control.” The fix, released as version 1.3.2, makes the trust-policy inspector properly evaluate set-qualified operators and reject unsafe conditions.

So who is actually at risk

This is not a bug in AWS itself, GitHub itself, or OIDC as a protocol. It’s a bug in one specific open-source linting-style tool that some organisations use to validate their own IAM trust policies before deploying them. If your team has never heard of @hulumi/policies, this doesn’t touch you.

Even among users of the package, the real-world impact depends on whether anyone actually wrote a trust policy using the ForAnyValue:StringLike operator with a wildcard subject — something that requires a specific (if plausible) misconfiguration to have already crept in before the checker was supposed to catch it. There’s no indication in either advisory that this is being actively exploited in the wild, and no install figures have been published to suggest how widely the package is used.

What to do about it

If your infrastructure pipeline uses @hulumi/policies to validate AWS IAM trust policies for GitHub OIDC, the fix is straightforward: upgrade to version 1.3.2 or later, where the patched inspector correctly flags set-qualified wildcard conditions. It’s also worth manually auditing any existing GitHub OIDC trust policies for ForAnyValue:StringLike clauses that might have slipped through unnoticed while the tool wasn’t looking properly.

For everyone else, this is a useful reminder rather than a red alert: automated security tooling is only as thorough as the edge cases its authors thought to test for, and a “critical” score on a narrow, low-profile package doesn’t automatically mean widespread danger. Check whether the tool in question is actually part of your stack — and if it isn’t, there’s nothing to do here.

Sources