Red Hat Quay CVE-2026-74240

Exploitation requires that the attacker already possess a validly-signed JWT issued by the same identity provider that is configured in the target Red Hat Quay instance - tokens from unrelated or untrusted IdPs are not usable. The flaw is specific to federated robot account authentication and SSO authentication flows; deployments using only local Quay username/password credentials are not exposed to this vulnerability. The CVSS PR:L metric confirms that some level of existing IdP-level access (i.e., the ability to obtain a legitimately-signed token) is a hard prerequisite. Exploitation is further limited by the requirement that the target Quay instance and the attacker's IdP relationship overlap; an external attacker with no connection to the configured identity provider cannot exploit this flaw.

The CVSS 5.4 Medium rating reflects the genuine but bounded nature of the risk: the attack vector is network-accessible (AV:N), complexity is low (AC:L), but low-privilege access is required (PR:L), meaning an attacker must already hold a valid token issued by the same IdP. There is no scope change (S:U) and impacts are partial on confidentiality and integrity with no availability effect, consistent with unauthorized lateral access rather than full system takeover. EPSS data is not present in the provided intelligence, and the CVE is absent from the CISA KEV catalog, so no confirmed in-the-wild exploitation can be asserted. The real-world risk is meaningfully elevated in multi-tenant or multi-team Quay deployments where several principals share a common identity provider - a scenario common in enterprise and government environments, where even a mid-sized municipal IT team in koszalin running on-premises Quay with enterprise SSO integration should treat this as a priority patch given the insider-threat and token-theft dimensions. Environments using only local Quay credentials are not affected, which substantially limits the overall attack surface.

An attacker who has obtained a valid JWT from the same identity provider integrated with the target Quay instance - whether through credential theft, insider access, or control of a lower-privileged account - submits a token to the Quay API with aud, azp, or sub values targeting a higher-privileged robot account or another user's SSO session. Because Quay fails to enforce these claims strictly, the token is accepted and the attacker gains read or write access to container image repositories they are not authorized to access. No public proof-of-concept code has been identified at time of analysis.