CVE-2026-10517: Clair SSRF Vulnerability – Unfiltered HTTP Requests Leak Metadata

Technical summary

The vulnerability exists in Clair's fetcher component, which processes layer descriptors from container image manifests. The fetcher makes outbound HTTP requests to URIs specified in manifest data without implementing IP-based filtering (e.g., blocking private ranges like 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16) or scheme validation. Pre-shared key (PSK) authentication is an optional, opt-in feature and not enforced by default. An unauthenticated attacker can inject a manifest containing a URI pointing to internal services, cloud metadata endpoints (e.g., AWS IMDSv1), or other restricted resources. For non-200 HTTP responses, the fetcher's CheckResponse error handler reflects up to 256 bytes of the response body in error messages, enabling an attacker to exfiltrate sensitive data. CWE-918 (Server-Side Request Forgery) characterizes the flaw. Operator-managed Red Hat Quay installations automatically configure PSK and mitigate the unauthenticated attack path.

Business impact

Organizations running self-managed Clair deployments without PSK authentication face exposure of internal service metadata and cloud credentials. Attackers can probe internal network topology, enumerate cloud metadata services, and extract sensitive information embedded in error responses. In cloud environments, this could lead to credential compromise or lateral movement. The severity is classified as MEDIUM (CVSS 5.8) because the confidentiality impact is limited in scope—only up to 256 bytes leak per request—and the attack requires an attacker to submit a manifest, which may be constrained by access controls in some environments. Red Hat Quay users on operator-managed deployments face no risk from the unauthenticated vector.

Affected systems

Clair instances running without pre-shared key (PSK) authentication enabled are vulnerable to unauthenticated SSRF attacks. This includes standalone Clair deployments and self-managed installations. Operator-managed Red Hat Quay deployments are not affected because PSK is auto-configured. Organizations using Clair as a standalone scanning tool, integrated into CI/CD pipelines, or deployed in air-gapped environments should verify whether PSK is in use. The vulnerability does not depend on a specific Clair version being provided in the ground truth; verify your deployed version against the Red Hat security advisory for patched releases.

Exploitability

Exploitation is straightforward. An attacker must submit a container manifest with a layer descriptor containing a malicious URI. No authentication is required if PSK is disabled (the default configuration). The attack vector is CVSS AV:N (network-accessible), with low complexity (AC:L) and no privileges or user interaction needed (PR:N, UI:N). The impact is limited because data leakage is capped at 256 bytes per error message, and the attacker must interpret fragmented responses. This vulnerability is not tracked in the CISA KEV catalog, indicating it has not been observed in active exploitation campaigns as of the published date.

Remediation

Organizations must enable pre-shared key (PSK) authentication in Clair deployments to restrict fetcher access to trusted clients. Update Clair to a patched version (consult the Red Hat security advisory for exact version numbers). Additionally, implement network segmentation to prevent Clair from reaching internal services or cloud metadata endpoints—use firewall rules, egress policies, or container network policies to block outbound access to private IP ranges and cloud metadata services. Apply defense-in-depth by restricting the sources from which manifests can be submitted (e.g., trusted registries or build systems) and monitoring Clair's outbound connections for anomalous requests.

Patch guidance

Apply the security patch released for Clair as detailed in the Red Hat security advisory (verify against the vendor's official guidance). Enable PSK authentication in Clair's configuration by setting the PSK parameter during deployment. For Red Hat Quay users, ensure you are running an operator-managed deployment or manually configure PSK if using a self-managed instance. Test the patched version in a non-production environment before deploying to production registries, as Clair is often mission-critical to container supply chain security.

Detection guidance

Monitor Clair logs for error messages containing 'CheckResponse' or failed HTTP requests to unexpected destinations. Look for manifests submitted to Clair with URIs pointing to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16, 127.0.0.1) or cloud metadata endpoints (169.254.169.254 for AWS, etc.). Use network monitoring to detect outbound HTTP requests from Clair to internal services or metadata endpoints. Audit manifest sources to identify whether untrusted or unauthenticated users can submit images for scanning. Implement alerting on HTTP error responses from Clair containing extracted credential patterns or configuration snippets.

Why prioritize this

While the CVSS score is MEDIUM (5.8), this vulnerability merits prompt remediation due to its low barrier to exploitation and potential for credential exfiltration in cloud-native environments. Many organizations deploy Clair without PSK because it is not enforced by default, creating a false sense of security. The SSRF can expose AWS IAM credentials, Kubernetes service account tokens, or internal API keys accessible via metadata endpoints. Prioritize patching if Clair is internet-facing, accepts manifests from untrusted sources, or is deployed in cloud environments where metadata services are present. Red Hat Quay users should verify their deployment model; operator-managed instances are protected by default.

Risk score, explained

The CVSS 5.8 MEDIUM score reflects limited confidentiality impact (256-byte leak cap), no integrity or availability impact, and the requirement for an attacker to submit a manifest. However, the risk in practice may be higher because (1) the default configuration leaves systems vulnerable, (2) cloud credentials are often available on metadata endpoints within that 256-byte window, and (3) the attack chain is trivial. The lack of KEV listing indicates no active public exploitation campaigns, further justifying a MEDIUM rather than HIGH rating. Organizations with mature access controls on manifest submission and network segmentation may treat this as a lower priority; those with open Clair instances or in cloud environments should treat it as higher priority.

Frequently asked questions