EUVD-2026-33599
GHSA-698x-9w2p-7vvp
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
1DescriptionCVE.org
A flaw was found in Clair. The fetcher component makes outbound HTTP requests to attacker-supplied URIs from manifest layer descriptors without IP or scheme filtering. When PSK authentication is not configured (opt-in, not enforced by default), an unauthenticated attacker can submit a manifest with a URI pointing to internal services or cloud metadata endpoints. The SSRF is reflective for non-200 responses, leaking up to 256 bytes of error body content via CheckResponse error messages. Operator-managed Red Hat Quay deployments auto-configure PSK and are not exposed to the unauthenticated attack vector.
AnalysisAI
Server-Side Request Forgery in Clair's fetcher component exposes internal network services and cloud metadata endpoints to unauthenticated remote attackers who can submit container image manifests with crafted layer descriptor URIs. Affected deployments are those where PSK (Pre-Shared Key) authentication is not configured - an opt-in control that is not enforced by default - meaning standalone or custom Clair installations without PSK are directly exploitable over the network with no credentials. Reflective SSRF behavior leaks up to 256 bytes of internal error body content per request via CheckResponse error messages, enabling network reconnaissance; no public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.
Technical ContextAI
Clair is an open-source container image static analysis and vulnerability scanner, commonly deployed as the backend vulnerability engine for Red Hat Quay container registries. Its fetcher component processes manifest layer descriptors - attacker-controlled input - and issues outbound HTTP requests to retrieve layer content. The root cause (CWE-918: Server-Side Request Forgery) is the complete absence of URI validation on these attacker-supplied endpoints: no IP allowlist/blocklist filters (e.g., RFC-1918 ranges, link-local 169.254.0.0/16), and no scheme restriction to prevent non-HTTP(S) schemes. This allows the Clair server to be weaponized as an HTTP proxy to reach services inaccessible directly to the attacker, including cloud instance metadata services (AWS IMDSv1 at 169.254.169.254), internal Kubernetes API servers, or other private network endpoints. The CVSS Changed Scope (S:C) reflects that the impact extends beyond Clair itself to these internal systems. The 256-byte leak is bounded by what is exposed in CheckResponse error message formatting, making this a partial-read reflective SSRF rather than a full-response proxy.
Affected ProductsAI
Clair instances where PSK authentication has not been configured are affected. The vulnerability is specifically not present in operator-managed Red Hat Quay deployments, which auto-configure PSK and are explicitly excluded from the unauthenticated attack vector per the Red Hat Security advisory. Standalone Clair deployments - including those integrated with non-Quay registries or deployed in custom configurations without PSK - are vulnerable when reachable over a network. Exact affected version ranges and CPE strings were not provided in the available data and should be confirmed via the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-10517.
RemediationAI
The primary fix is to enable PSK (Pre-Shared Key) authentication on the Clair instance, which eliminates the unauthenticated attack vector entirely by requiring clients to authenticate before submitting manifests. For Red Hat Quay operator-managed deployments, PSK is auto-configured and no additional action is required. For standalone or custom Clair deployments, consult the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-10517 for the patched version and PSK configuration instructions. As a compensating control where immediate PSK configuration is not feasible, implement host-level or network-level egress filtering on the Clair server to block outbound HTTP requests to RFC-1918 private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local ranges (169.254.0.0/16) used by cloud metadata services - note this may interfere with legitimate layer fetching if internal container registries are hosted on private networks, so an allowlist-based approach targeting known registry IPs is preferable to a blanket block. Additionally, restricting network-level access to the Clair API to trusted clients only (e.g., registry components) reduces exposure without affecting functionality. An exact patched version number was not confirmed in the available data; verify the specific fix version against the Red Hat advisory before deployment.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today