CVE-2026-74240 in OpenShift Update Service
Summary
by MITRE • 08/15/2026
A flaw was found in Red Hat Quay's JWT (JSON Web Token) validation for federated robot accounts and single sign-on (SSO) authentication. Multiple issues related to audience verification and the enforcement of `azp` and `sub` claims were identified. These flaws could allow an attacker with a validly-signed token from the same identity provider to bypass configured security restrictions. This bypass could lead to unauthorized access by circumventing intended audience, subject, or authorized-client limitations.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability resides within Red Hat Quay's authentication infrastructure where JSON Web Token validation mechanisms fail to properly enforce critical security parameters for federated robot accounts and single sign-on operations. The flaw manifests through inadequate verification of audience claims and insufficient enforcement of authorization parameters that should restrict token usage to specific applications or services. When identity providers issue tokens with valid signatures, attackers can exploit these validation gaps to manipulate token attributes and gain access beyond their intended scope.
The technical implementation suffers from multiple weaknesses in the JWT processing pipeline where the system does not adequately validate the aud (audience) parameter against configured allowed audiences for federated accounts. Additionally, the system fails to properly enforce the azp (authorized party) claim which should identify the client application authorized to use the token, and the sub (subject) claim which identifies the principal entity. These failures create a pathway where an attacker with a legitimate token from the same identity provider can manipulate token attributes to bypass access controls that should restrict usage to specific authorized clients or user accounts.
The operational impact of this vulnerability extends beyond simple authentication bypasses as it fundamentally undermines the security model for federated identity management within Red Hat Quay. Attackers could potentially access systems or resources that should be restricted to specific client applications, thereby compromising the principle of least privilege and enabling unauthorized data access or system manipulation. This vulnerability particularly affects environments where multiple applications or services share the same identity provider infrastructure, creating a broader attack surface that could be exploited across various system components.
Security controls for this vulnerability align with several CWE categories including CWE-287 for improper authentication and CWE-345 for insufficient verification of data integrity. The flaw also maps to ATT&CK techniques such as T1078 for valid accounts and T1566 for credential harvesting, as attackers could exploit the token manipulation to gain unauthorized access through legitimate authentication paths. Organizations should implement immediate mitigations including stricter JWT validation policies, enhanced audience claim verification, and enforcement of proper azp and sub claim validation. Additional defensive measures include implementing token revocation mechanisms, monitoring for unusual access patterns, and ensuring that identity providers properly configure token issuance with appropriate scope limitations.
The root cause demonstrates inadequate security configuration in the authentication layer where trust relationships between identity providers and service applications are not properly enforced through cryptographic verification of token attributes. This vulnerability type represents a common pattern in federated identity systems where the complexity of cross-domain trust relationships creates opportunities for attackers to exploit inconsistencies in token validation logic. Organizations should also consider implementing additional security controls such as token binding, enhanced logging and monitoring, and regular security assessments of their identity federation configurations to prevent similar vulnerabilities from emerging in other components of their authentication infrastructure.