Introduction
A missing JWT signature verification in AWS Ops Wheel's v2 API means that any unauthenticated attacker who can reach the API Gateway endpoint can forge a token and gain full administrative control over the application, including cross tenant data access and Cognito user management. With a CVSS score of 9.8 and trivial exploitation requirements, this is one of the more straightforward authentication bypasses we have seen in an AWS maintained open source project.
AWS Ops Wheel is an open source tool for conducting random selections (a "wheel of names" style application) that is deployed via AWS CloudFormation. It provisions an API Gateway, Lambda functions, DynamoDB tables, and an Amazon Cognito User Pool as part of its stack. While it is not a core AWS service, its deployment pattern using Cognito and API Gateway is representative of many serverless applications in the AWS ecosystem, making this vulnerability instructive beyond its immediate blast radius.
Technical Information
The root cause of CVE-2026-6911 is classified under CWE-347: Improper Verification of Cryptographic Signature. In the v2 API of AWS Ops Wheel, the application accepted JWT tokens by simply base64 decoding the payload section without ever verifying the cryptographic signature. Two functions were responsible for this insecure behavior: decode_jwt_payload_only() and validate_token_basic(). Neither function validated that the token was actually signed by the Amazon Cognito User Pool's RSA key.
JWTs consist of three parts: a header, a payload, and a signature. The signature is what binds the claims in the payload to a trusted issuer. Without signature verification, the header and payload can contain any arbitrary claims, and the application will trust them unconditionally. This is not a subtle cryptographic weakness; it is a complete absence of the verification step.
Attack Flow
The exploitation path is straightforward:
- An attacker identifies the API Gateway endpoint for an AWS Ops Wheel v2 deployment. This endpoint is typically publicly accessible unless additional network controls have been applied.
- The attacker constructs a JWT with a header specifying the RS256 algorithm and a payload containing administrative claims, including any desired tenant identifier and administrative role.
- The signature portion of the JWT can be any value, or even empty, since the application never checks it.
- The attacker sends this crafted JWT in the Authorization header to the API Gateway endpoint.
- The v2 API accepts the token, extracts the claims from the base64 decoded payload, and grants the attacker full administrative access.
- With administrative access, the attacker can read, modify, and delete all application data across all tenants. The attacker can also manage Amazon Cognito user accounts within the deployment's User Pool, enabling persistent access or denial of service against legitimate users.
The attack vector is network based. It requires no prior authentication, no user interaction, and the complexity is low. An attacker needs only the ability to send HTTP requests to the API Gateway endpoint.
Scope of Impact
The impact spans all three pillars of the CIA triad. Confidentiality is fully compromised because the attacker can read all data across tenants. Integrity is fully compromised because the attacker can modify or delete any data. Availability is impacted through the ability to delete data and manipulate Cognito user accounts. The cross tenant nature of the access means that a single exploited deployment exposes every tenant configured within that instance.
Affected Systems and Versions
The vulnerability specifically impacts the v2 API of AWS Ops Wheel. The v1 API is unaffected.
| Component | Vulnerability Status |
|---|---|
| AWS Ops Wheel v1 API | Unaffected |
| AWS Ops Wheel v2 (PR 147 through PR 163) | Affected |
| AWS Ops Wheel v2 (PR 164 and later) | Fixed |
Deployments built from Pull Request 147 through Pull Request 163 of the aws/aws-ops-wheel repository are vulnerable. Any forks or derivative codebases that incorporated the v2 API code from this range without the fix from PR 164 are also affected.
