GPU VulnDB

Database/AI/ML frameworks & serving

vLLM orchestrator gateway: bearer tokens and full chat payloads written to persistent logs

CVSS 7.5CVE-2026-15574AI/ML frameworks & servingcurated

Impact

The production binary of the vllm-orchestrator-gateway logged every incoming Authorization header and the full chat payload to persistent logs. Anyone who can read those logs - and on a Kubernetes fleet that is a much wider group than the inference team, covering cluster log aggregation, SRE dashboards and anyone with pod log access in the namespace - can harvest valid bearer tokens and replay them against the inference endpoint, and can read the prompt and response content of every tenant that went through the gateway. For a GPU operator running shared inference, that is simultaneously a credential leak and a disclosure of customer prompt data, and the logs may already be sitting in a long-retention store.

Who can reach it

Any party with read access to the gateway's logs or to the log aggregation pipeline, which on OpenShift includes namespace pod-log readers and the cluster logging stack. The leak needs no attack against the gateway itself - callers of the API populate the logs in normal operation.

What to do

Apply the Red Hat errata for your channel - RHSA-2026:84734 or RHSA-2026:87410 for Red Hat OpenShift AI 2.25 and 3.4 - which updates the component and restarts the gateway pods; no node drain. Patching stops new leakage but does not undo it: treat every bearer token that transited the gateway as exposed and rotate it, and purge or restrict the retained logs and any backups or SIEM copies of them.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.