- The Mess: A vulnerability in Hulumi’s
@hulumi/policiespackage mishandles AWS IAM condition operators when generating GitHub OIDC trust policies. A policy that looks restrictive can end up granting trust more broadly than intended. - The Damage: An attacker who can influence a GitHub Actions workflow or repository context could potentially abuse the incorrectly generated IAM trust relationship to obtain AWS credentials.
- The Fix: Upgrade the affected Hulumi policy package and manually review GitHub OIDC trust policies generated for AWS roles.
Your GitHub workflow doesn’t need an AWS password.
It can get credentials through OIDC.
That’s the good news.
The bad news is that one incorrect IAM condition can turn that security model into a much bigger trust relationship than the developer intended.
That’s the problem behind CVE-2026-82856, affecting Hulumi’s @hulumi/policies package.
GitHub Can Become the AWS Identity Provider
GitHub Actions can authenticate to AWS using OpenID Connect.
Instead of storing a long-lived AWS access key inside GitHub Secrets, a workflow requests a short-lived identity token.
AWS then checks the token against an IAM trust policy.
If the claims match, AWS issues temporary credentials.
The security model depends on those claims being validated correctly.
That’s where the bug enters.
The Condition Operator Matters
AWS IAM policies contain condition operators that determine exactly how claims are evaluated.
Things like:
StringEqualsStringLikeStringNotEqualsStringNotLike
A developer may intend:
“Only this repository can assume the role.”
The generated policy needs to enforce exactly that.
If the operator is mishandled, the resulting trust relationship can be broader than expected.
And an overly broad GitHub OIDC trust policy is essentially an invitation to request AWS credentials from the wrong workflow.
The Dangerous Part Is the Generated Policy
Hulumi is infrastructure tooling.
That means developers may not manually write every IAM policy.
They define infrastructure.
The framework generates the underlying AWS configuration.
That’s convenient until the abstraction gets security-sensitive logic wrong.
The developer sees:
secure infrastructure code
AWS receives:
an IAM trust policy
Those two things need to mean exactly the same thing.
GitHub Actions Is a Popular Attack Target
CI/CD systems are valuable because they often have access to production infrastructure.
A GitHub Actions runner may have permissions to:
- deploy applications
- access S3
- modify Lambda
- push container images
- update infrastructure
- read cloud secrets
If an attacker can obtain AWS credentials through a misconfigured trust relationship, the compromise can jump directly from source control into the cloud.
No phishing required.
No stolen developer password required.
Just an identity policy that trusts the wrong workflow.
This Is a Supply-Chain Problem
The vulnerable component sits between developers and AWS.
That’s what makes this more interesting than a normal library bug.
The chain is:
developer code → Hulumi → IAM policy → GitHub OIDC → AWS credentials
A defect in the middle can silently weaken the security model.
The infrastructure may deploy successfully.
The application may work perfectly.
There may be no obvious error.
The vulnerability is in what the policy actually allows.
Why OIDC Is Worth Protecting
OIDC was introduced partly to eliminate long-lived cloud credentials from CI/CD systems.
That’s a major improvement.
But short-lived credentials don’t help if an attacker can convince AWS that their workflow is trusted.
The identity token can be perfectly valid.
The signature can be perfectly valid.
The problem is simply:
AWS trusted the wrong identity.
That’s why IAM trust policies deserve the same attention as application authentication.
Review Existing Roles
Updating the package is the obvious first step.
But organizations should also inspect existing AWS roles used by GitHub Actions.
Look for:
- wildcard repository conditions
- overly broad
subclaims - incorrect
StringLikeorStringEqualsusage - roles trusted by unexpected repositories
- unnecessary production permissions
The safest GitHub OIDC policy should identify exactly which repositories, branches or environments are allowed to assume the role.
The Blast Radius Can Be Huge
The vulnerability itself doesn’t automatically mean an attacker gets administrator access.
The impact depends on the permissions attached to the affected AWS role.
A role that can only deploy a static website is one thing.
A role with access to:
S3 + Secrets Manager + Lambda + IAM
is another.
The trust policy determines who can enter.
The role policy determines what they can do once inside.
Both matter.
Bugstoday Opinion
Cloud security loves abstractions.
Developers write a few lines.
The framework generates dozens of resources.
AWS handles the authentication.
Everything looks clean.
Until one condition operator changes the meaning of the trust relationship.
Then the entire security model becomes:
“AWS, please trust whoever this policy accidentally trusts.”
That’s not a theoretical problem.
CI/CD credentials are among the most valuable credentials in modern infrastructure.
Bugstoday verdict: OIDC removes the need to store permanent cloud keys in GitHub, but it doesn’t remove the need to get IAM trust policies exactly right. A short-lived credential issued to the wrong workload is still a credential issued to the attacker.
Today’s Bugs. Tomorrow’s Breaches.
