Red Hat Quay CVE-2026-74247

Exploitation requires two concurrent conditions: (1) the FEATURE_BUILD_SUPPORT flag must be explicitly enabled in the Quay configuration - installations without this feature active are not vulnerable; and (2) the attacker must hold repository write access within the Quay instance, which constitutes authenticated low-privilege access (CVSS PR:L confirmed). These conditions together limit exploitation to authenticated users in deployments that have opted into build functionality. What limits exploitation further: this is not a zero-credential attack - unauthenticated users cannot trigger the build API; and organizations using Quay purely as a registry without build features enabled face no exposure. The CVSS S:U (unchanged scope) indicates the immediate exploitation impact is contained to the Quay application boundary, though SSRF by nature can bridge to adjacent internal systems.

The CVSS 3.1 base score of 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N) indicates a high-confidentiality-impact network vulnerability exploitable with low privileges and no user interaction, which is a genuine priority in environments where FEATURE_BUILD_SUPPORT is active. However, several signals moderate real-world urgency: EPSS at 0.13% (3rd percentile) indicates this CVE is not being actively scanned or targeted at scale; the vulnerability is not listed in CISA KEV, and no POC or active exploitation has been identified. The PR:L requirement (authenticated write access) materially limits the attacker pool to trusted internal users or compromised accounts with existing write permissions. The I:L component reflects the ability to interact with internal services, but primary risk is reconnaissance and data exfiltration from internal APIs. Organizations that do not enable FEATURE_BUILD_SUPPORT are not affected, which reduces the real-world exposed surface. For those with the feature enabled, this represents a meaningful insider-threat and lateral-movement vector.

An attacker who has obtained repository write access - whether through a compromised developer credential or a malicious insider - submits a Quay build job with a crafted build context URL pointing to an internal metadata service (e.g., a cloud instance metadata endpoint or an internal API gateway). The Quay builder service fetches the URL and returns response content that the attacker can observe, exposing internal credentials, configuration data, or service responses. No public exploit code has been identified at time of analysis, meaning this scenario requires manual crafting of a malicious build request.