Red Hat OpenShift AI CVE-2026-17557

Requires an authenticated user with authorization to submit an evaluation job to the lm-evaluation-harness component of Red Hat OpenShift AI (PR:L), who then supplies an attacker-controlled model URL in the JobSpec. The exploitation-enabling condition is that the evaluation job pod dereferences the user-supplied model URL and attaches the tenant's model authentication secret when doing so, and that the pod has network reachability to the targeted internal endpoints for the SSRF leg. Limiting factors: valid tenant job-submission credentials are mandatory (no anonymous/unauthenticated path), no privilege escalation or availability impact is involved, and the internal-SSRF reach is constrained to endpoints routable from the evaluation pod's network namespace. No end-user interaction is required.

This is a moderate, authentication-gated SSRF (CWE-918) with real but bounded risk. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) is internally consistent with the description: network-reachable, low complexity, requires low privileges (PR:L - an authenticated user who can submit evaluation jobs), and delivers a high confidentiality impact (disclosure of the tenant's model authentication secret) with no integrity or availability impact. No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the signals are not conflicting, they are simply absent, which is consistent with a recently reported vendor-disclosed flaw rather than a widely weaponized one. The practical risk is driven by the fact that exploitation requires a legitimate authenticated tenant able to submit jobs, which limits the attacker population to insiders or anyone who has already obtained tenant-level job-submission credentials; against that bar, the secret-exfiltration and internal-SSRF primitives are serious in a multi-tenant OpenShift AI environment. Net: a credible priority for RHOAI operators to patch, but not an emergency mass-exploitation scenario.

An authenticated tenant user with permission to submit evaluation jobs crafts a JobSpec whose model URL points to an attacker-controlled external listener; when the lm-evaluation-harness evaluation pod fetches that URL it forwards the tenant's model authentication secret, leaking it to the attacker. The same primitive can be aimed at internal addresses (e.g. cloud metadata or internal services) reachable from the evaluation pod to perform SSRF. No public exploit code was identified at time of analysis, and exploitation requires valid low-privilege credentials rather than user interaction.