Red Hat Quay CVE-2026-10078

Exploitation requires two distinct conditions to be simultaneously true. First, the GitLab OAuth integration must be actively configured and validated within Quay 3's config-tool - this feature must be in use; deployments that do not integrate with GitLab are not exposed. Second, the attacker must independently hold read access to at least one of the following: web server access logs, reverse proxy logs, or any monitoring/SIEM system that records full request URIs for the Quay config-tool host. Per the CVSS vector (PR:H), triggering the vulnerable code path itself requires high-privilege access to the Quay config-tool. Exploitation is limited by: the PR:H requirement (restricts who can initiate the credential-leaking request), the need for separate log-read access (the credential is not exposed over the wire to passive network observers), and the narrow scope of impact (only GitLab OAuth client credentials are affected, not Quay user credentials or other secrets).

The CVSS 3.1 base score of 2.7 (Low) reflects a narrow exploitation window: AV:N (network-reachable endpoint) is offset by PR:H (high privileges required to trigger the configuration validation workflow) and C:L (partial confidentiality impact, limited to two OAuth fields). EPSS data was not provided; given the PR:H requirement and absence from CISA KEV, real-world exploitation probability is likely low. There is no public exploit code identified at time of analysis, and the vulnerability is not confirmed actively exploited. The practical risk is further conditioned on whether an attacker already holds high-privilege access to Quay's config-tool and also has separate read access to the target log systems. Despite the low score, the qualitative impact is meaningful: OAuth client_secret compromise can enable persistent unauthorized GitLab API access that outlasts the initial exploitation window, creating a secondary credential-theft risk that CVSS C:L does not fully capture. The low CVSS score appears consistent with the technical facts - this is a real but narrowly scoped credential-hygiene issue rather than a critical or high-priority vulnerability for most deployments.

An administrator with high-privilege access to Quay's config-tool initiates GitLab OAuth configuration validation, unknowingly triggering a POST request that appends client_id and client_secret as plaintext URL query parameters to the GitLab endpoint. A separate attacker - or the same privileged user acting maliciously - queries server access logs, reverse proxy logs, or a SIEM that captures full request URIs and extracts the plaintext credentials. The attacker then uses the harvested client_secret to make authenticated GitLab API calls, gaining unauthorized access to GitLab resources scoped to that OAuth application. No public exploit code exists for this issue.