GHSA-4QQ2-2J2X-X62C

This class covers overly permissive cloud IAM trust policies that federate with GitHub's OIDC provider (token.actions.githubusercontent.com) but fail to constrain which workload may assume the role. The cloud role validates the OIDC token but checks only the audience claim (for example sts.amazonaws.com) while omitting the token.actions.githubusercontent.com:sub condition, or it uses a broad wildcard such as repo:org/* or a StringLike pattern instead of StringEquals, so any branch, any fork, or even an attacker-owned repository can mint a valid GitHub OIDC token and exchange it for cloud credentials. Because the sub claim encodes repository, branch, tag, and environment, dropping or loosening it removes the only binding between the role and the intended pipeline, yielding full assumption of the trusted role. Tinder Security Labs documented this in their AWS OIDC research, finding multiple real AWS roles assumable from unauthorized repositories due to missing subject validation, with the successful assumptions visible in CloudTrail. GitHub's OIDC support and the configure-aws-credentials path shipped in 2021, making this a long-standing systemic configuration risk.

OpenClaw: Internal/webchat command auth could inherit ownerAllowFrom wildcard state

OpenClaw: Linux and macOS exec allowlists skipped configured argument patterns

OpenClaw: BlueBubbles sender policy could match mutable conversation identifiers

OpenClaw: Shell positional parameters could weaken strict inline-eval checks

opentelemetry-collector-contrib: githubreceiver silently ignores configured required_headers authentication