Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as repository administrator
-
DeliveryConfigure webhook with blacklist-bypassing URL
-
ExploitTrigger notification event
-
ExecutionQuay sends server-side request to internal resource
-
ImpactDisclose metadata/internal service response
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to hold an authenticated repository administrator role in Quay (PR:L) and to use Quay's webhook notification feature, supplying a target URL specifically crafted to bypass the hostname blacklist control. Realistic impact further depends on reachable internal endpoints from the Quay application - e.g., an accessible cloud metadata service (such as IMDSv1) or other in-cluster services - so deployments that restrict egress from the Quay pod or enforce IMDSv2 significantly limit the disclosure impact. Limiting factors: requires a privileged in-application role (not anonymous/unauthenticated), requires the webhook feature to be used, and value is bounded by what internal services expose. |
| Impact | This is a moderate-severity SSRF (CWE-918) with CVSS 6.4. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) indicates network-reachable, low-complexity exploitation, but it requires privileges (PR:L) - specifically, the attacker must already be an authenticated repository administrator, which materially narrows the threat population to users who already hold a trusted role within Quay. The scope-change (S:C) and CWE-918 are meaningful: a successful bypass lets Quay reach internal/cluster resources (e.g., cloud metadata endpoints), so the real impact depends on what those internal services expose. Confidentiality and integrity impacts are rated Low, with no availability impact. No EPSS score, KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. On balance this is a real but privilege-gated hardening issue rather than a mass-exploitation emergency; prioritize it in environments where many users can hold repo-admin roles or where cloud metadata services (e.g., IMDSv1) are reachable from the Quay pod. No conflicting signals were found, but the absence of EPSS/KEV/POC data means exploitation likelihood is inferred from the vector alone, not measured. |
| Exploit ScenarioDerived | An authenticated repository administrator in Red Hat Quay configures a repository webhook notification whose target URL is crafted to evade the hostname blacklist, pointing at an internal address such as a cloud metadata endpoint or an in-cluster service. When the notification fires, Quay issues the server-side request on the attacker's behalf and returns or exposes the response, disclosing sensitive internal data (e.g., instance credentials or service details). No public exploit code was identified in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Server-side request forgery in Red Hat Quay allows an authenticated repository administrator to bypass the hostname blacklist enforced by the webhook notification feature, causing the Quay application to issue HTTP requests to attacker-chosen internal destinations such as cloud metadata endpoints or in-cluster services. Successful exploitation can disclose sensitive information returned by those internal services, though the CVSS 3.1 score of 6.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) reflects a moderate impact: the attacker must already hold a privileged in-application role, must use the webhook functionality, and the yield is bounded by which internal endpoints the Quay pod can actually reach. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the flaw is tracked by Red Hat under CVE-2026-85471 with all Quay 3 and Mirror Registry offerings listed as affected via wildcarded CPEs.
RemediationAI
No vendor-released patch identified at time of analysis; the supplied references point only to Red Hat's CVE tracking page (https://access.redhat.com/security/cve/CVE-2026-85471) and Bugzilla entry (https://bugzilla.redhat.com/show_bug.cgi?id=2528221), with no fixed version, errata, or upstream commit specified, so administrators should monitor those pages for an errata that names the exact Quay and Mirror Registry release to upgrade to and apply it as soon as it is published. Until then, the most effective compensating control is to constrain where the Quay pod can send outbound traffic: apply OpenShift egress NetworkPolicies or an egress firewall so Quay can reach only the specific external webhook destinations and registry endpoints it legitimately needs, which directly denies the forged requests - the trade-off is that legitimate webhooks or mirroring to newly added endpoints will fail until explicitly allowlisted. Harden cloud metadata access by requiring IMDSv2 and disabling IMDSv1 and by blocking the link-local range from the Quay pod, which neutralizes the highest-value SSRF target but may impact other pods that still rely on IMDSv1. Reduce the attack surface by limiting who holds the repository administrator role and by auditing or temporarily disabling webhook notifications (or restricting them to vetted destinations) - this removes the vector entirely at the cost of losing event-driven integrations. Where webhooks must remain enabled, force outbound requests through a validating forward proxy that resolves and allowlists destination IPs after redirects rather than relying on the hostname blacklist, and log and alert on Quay egress to unexpected internal addresses.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability is a classic CWE-918 server-side request forgery rooted in insufficient validation of a user-supplied URL. Red Hat Quay's webhook notification subsystem lets repository administrators register a destination URL that Quay later calls on repository events; the product attempts to constrain this with a hostname blacklist intended to prevent requests to internal or loopback addresses. Because the blacklist is a name-based denylist rather than a resolved-address allowlist enforced at request time, it can be bypassed through techniques such as alternative hostname encodings, redirects, DNS rebinding, or equivalent names that still resolve to internal IP space. Once bypassed, the Quay server itself becomes the request originator, which is why the CVSS vector is scope-changed (S:C) - the vulnerable component is Quay, but the impacted component becomes whatever internal service the forged request reaches. In container-platform deployments this is especially relevant, since the Quay pod may sit on a network with access to cloud instance metadata services (for example the link-local IMDSv1 endpoint) or to Kubernetes/OpenShift cluster services that are not intended to be reachable from user-controlled input. The disclosure impact (C:L) is limited rather than total because it depends on what those internal services return and whether the environment enforces egress restrictions or metadata hardening. The CPE data identifies Red Hat Quay 3, Mirror Registry for Red Hat OpenShift, and Mirror Registry for Red Hat OpenShift 2 as the affected product families, with version fields wildcarded.
Know when Mirror Registry For Red Hat Openshift gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Network-reachable webhook config with low complexity, but requires authenticated repo-admin (PR:L); SSRF reaches internal services so scope changes (S:C), with limited confidentiality/integrity and no availability impact.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
A flaw was found in Quay. An authenticated repository administrator could bypass the hostname blacklist in webhook notifications, leading to a Server-Side Request Forgery (SSRF) vulnerability. This allows the Quay application to be tricked into sending requests to internal network resources, such as cloud metadata services or other services within the cluster. Consequently, this could lead to the disclosure of sensitive information from these internal services.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
Affected Products (CPE)CVE.org
Authenticated remote code execution in Red Hat Quay 3 and Mirror Registry for Red Hat OpenShift arises from unsafe deser
Red Hat Quay's container image upload mechanism allows authenticated users with push privileges to interfere with concur
Server-side request forgery (SSRF) in Red Hat Mirror Registry and Red Hat Quay 3.x allows authenticated users to conduct
Server-Side Request Forgery (SSRF) in Red Hat Quay's Proxy Cache configuration allows authenticated organization adminis
OpenShift Mirror Registry leaks valid usernames and email addresses through inconsistent error messages during authentic
EUVD-2026-97776
GHSA-f2g8-c8v2-qmmr
NVD
CVE.org
EPSS
Exploit-DB