Predibase LoRAX EUVD-2026-97009

Exploitation requires (1) a LoRAX router (≤0.12.1) that logs requests and/or exports traces via OTLP with the GenerateParameters span instrumentation active - the default instrumented code path that writes the api_token field; (2) clients actually sending an api_token in POST /generate bodies, which happens when private/gated adapters are used; and (3) the attacker having read access to those router logs or the OTLP trace backend. Limiting factors that reduce real-world risk: the attacker must already hold log-store or tracing-backend access (PR:L, AV:L - not a raw network exploit against the API), only tokens for users who invoked private adapters are exposed, and deployments that disable request/trace logging or redact the field are not affected.

This is a CWE-532 sensitive-information-in-logs issue in Predibase LoRAX (through 0.12.1), and the signals are internally consistent and point to a moderate, not critical, priority. The supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) scores 6.8 and correctly models the ACTUAL attack: a low-privileged party who already has read access to router logs or the OTLP trace backend passively harvests api_tokens - hence local vector (AV:L), low privileges (PR:L), high confidentiality impact (VC:H) and no integrity/availability impact. No EPSS score was provided, there is no CISA KEV listing, and no proof-of-concept is flagged in the input, so exploitation is not demonstrated: no public exploit identified at time of analysis. The honest read is that the raw secret (api_token) is written server-side the moment any client calls POST /generate, but turning that into a compromise requires the attacker to first reach the log store or tracing backend - so real-world risk is gated almost entirely by how exposed those logging pipelines are, not by the LoRAX network surface. Note a nuance to verify: the token is captured from a network request body, but recovery requires local/log-backend access, so defenders focused only on network ACLs may misjudge exposure. Missing data: no EPSS, no KEV, no vendor-confirmed fixed version in the input (references cite VulnCheck and a hackmd writeup plus source lines, not a patched release).

A LoRAX deployment logs every POST /generate request, and the instrumented GenerateParameters span records the caller-supplied api_token used to access private adapters. An insider, a compromised log-aggregation account, or anyone with read access to the OTLP trace backend browses the collected router logs/traces and extracts other tenants' private-adapter tokens, then reuses them to access those users' private adapters. No proof-of-concept exploit is referenced in the input.