# Red Hat OpenShift AI: an eval job's model URL leaks the tenant's API key

> CVE-2026-17557 lets an OpenShift AI evaluation job send the tenant's model API key to any URL the submitter names.

- **Severity:** Medium: Real and reproducible, but needs unusual setup, user help or a narrow audience. Plan a fix.
- **Category:** Vulnerability
- **Published by:** Red Hat
- **Disclosed:** 2026-10-21
- **CVE:** CVE-2026-17557
- **CVSS:** 6.5
- **Affects:** Red Hat OpenShift AI, lm-evaluation-harness
- **Research by:** Red Hat Product Security
- **Primary source:** https://access.redhat.com/security/cve/CVE-2026-17557
- **Page:** https://theinjection.dev/items/redhat-openshift-ai-eval-job-credential-ssrf/

Red Hat OpenShift AI 3.4 lets any user who can submit an evaluation job send the tenant's model API key to a server the user names. The lm-evaluation-harness adapter never checked the job's model URL. Red Hat fixed it in RHOAI 3.5.

## What happened

Red Hat made CVE-2026-17557 public on 21 October 2026, a flaw in the lm-evaluation-harness component of Red Hat OpenShift AI. A Red Hat Product Security audit found it during an internal review tracked as Glasswing and filed it in the product's bug tracker on 27 July 2026. Red Hat rates the flaw Moderate, with a CVSS base score of 6.5.

## How it works

The EvalHub adapter builds the completions URL from the model.url field of the evaluation job spec, with no allow-list for the host or scheme and no block on internal addresses. Red Hat's job exports the tenant's model API key as OPENAI_API_KEY and sends it to that URL as a Bearer token. A user who can submit a job can therefore point the request at a listener they control and collect the credential, or aim it at internal and link-local endpoints reachable from the evaluation pod for blind server-side request forgery.

## Who is affected

Red Hat states the flaw is specific to Red Hat OpenShift AI 3.4 and its odh-ta-lmes-job-rhel9 package, used with eval-hub. Exploitation needs an authenticated account that is allowed to submit an evaluation job, so the exposure sits with tenants and insiders rather than anonymous callers. Red Hat's record lists the fix state for the 3.4 package itself as deferred.

## What to do

Move to Red Hat OpenShift AI 3.5, which Red Hat says addresses the issue through an architectural change, because its record names no fix for 3.4 and no mitigation. Until that upgrade lands, restrict who may submit evaluation jobs and rotate any model provider key that a 3.4 evaluation job could read.

## Quick facts

- **Affected:** Red Hat OpenShift AI 3.4, lm-evaluation-harness EvalHub adapter, package odh-ta-lmes-job-rhel9
- **Fixed in:** Red Hat OpenShift AI 3.5, by an architectural change; fix deferred for the 3.4 package
- **CVE:** CVE-2026-17557
- **CVSS:** 6.5 (v3.1), Moderate, assigned by Red Hat and marked draft
- **Attack type:** Server-side request forgery with Bearer credential forwarding, CWE-918
- **Found by:** A Red Hat Product Security audit, tracked internally as Glasswing
- **Disclosed:** Filed 27 July 2026, made public 21 October 2026

## Sources

1. [Red Hat Advisory](https://access.redhat.com/security/cve/CVE-2026-17557)
2. [GitHub Advisory](https://github.com/advisories/GHSA-xphj-jg67-vf2w)
3. [Red Hat Bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=2507452)