CVE-2026-17557 in lm-evaluation-harness
Summary
by MITRE • 10/21/2026
A flaw was found in the `lm-evaluation-harness` component of Red Hat OpenShift AI. An authenticated user, able to submit an evaluation job, could exploit this by providing a malicious model URL in the `JobSpec`. This vulnerability allows for the disclosure of the tenant's model authentication secret to an attacker-controlled external listener. Additionally, it enables Server-Side Request Forgery (SSRF) attacks against internal network endpoints reachable from the evaluation job pod.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The identified vulnerability resides within the lm-evaluation-harness component of Red Hat OpenShift AI, representing a significant security risk for multi-tenant machine learning environments. This flaw specifically affects authenticated users who possess the permission to submit evaluation jobs. The core technical issue stems from insufficient input validation and sanitization mechanisms when processing the JobSpec configuration provided by the user. When an attacker submits a job with a maliciously crafted model URL, the system fails to adequately restrict or verify the destination of this request before initiating the download or connection process. This lack of rigorous control allows the underlying infrastructure to act as a proxy for the attacker's intent rather than strictly serving its intended purpose of evaluating machine learning models.
The operational impact of this vulnerability is twofold, involving both credential exposure and network reconnaissance capabilities. First, the flaw enables the disclosure of tenant-specific model authentication secrets. By directing the evaluation job to an external listener controlled by the attacker, sensitive credentials stored within the pod's environment or passed during initialization can be exfiltrated. This compromises the integrity of the machine learning models associated with that tenant, potentially allowing unauthorized access to proprietary algorithms or training data protected by these secrets. Second, the vulnerability facilitates Server-Side Request Forgery attacks against internal network endpoints. Because the evaluation job runs within a pod that typically has access to internal service meshes and cluster-internal APIs, an attacker can leverage this SSRF capability to probe, interact with, or exploit other services residing on the same virtual private cloud or Kubernetes cluster network segment.
From a classification perspective, this vulnerability aligns closely with CWE-918, which describes Server-Side Request Forgery (SSRF). The failure to validate user-supplied URLs before processing them allows an authenticated actor to redirect server-side requests to unintended destinations. Furthermore, the exfiltration of authentication secrets relates directly to CWE-200, concerning Exposure of Sensitive Information to an Unauthorized Actor. In terms of offensive security tactics, this behavior maps to MITRE ATT&CK technique T1598, specifically Phishing for Information within a Multi-Tenant Environment, as well as T1496, Resource Hijacking or Network Service Discovery via SSRF. The attacker leverages the trusted relationship between the application and internal services to bypass perimeter defenses that would otherwise block direct external access to these sensitive resources.
Mitigation strategies must focus on strict input validation and network isolation principles. Developers should implement allow-listing for model URLs, ensuring that only known, safe domains or IP ranges are permitted for evaluation jobs. Additionally, implementing robust SSRF protections such as blocking requests to private IP address ranges (RFC 1918), link-local addresses, and metadata service endpoints is critical. Network policies within the Kubernetes cluster should be tightened to restrict egress traffic from evaluation pods, limiting their ability to communicate with arbitrary external listeners or internal services that do not require access for legitimate model loading operations. Regular security audits of the lm-evaluation-harness component and continuous monitoring for anomalous outbound network connections can further reduce the risk of exploitation in production environments.