CVE-2026-108858: 
Linux Red Hat Analyse et atténuation des vulnérabilités

CVE-2026-108858 is a sensitive information exposure vulnerability in Predibase LoRAX (LoRA eXchange), a multi-LoRA inference server for serving fine-tuned LLMs. The flaw causes caller-supplied api_token values from POST /generate request bodies to be written into router logs and OpenTelemetry (OTLP) trace backends via the instrumented GenerateParameters span field, exposing private adapter authentication tokens to anyone with log or telemetry access. All versions through 0.12.1 are affected. The vulnerability was disclosed on October 11, 2026, with a CVSS v3.1 score of 5.5 (Medium) and a CVSS v4.0 score of 6.8 (Medium) (Github Advisory, Red Hat Advisory).

The root cause is classified as CWE-532 (Insertion of Sensitive Information into Log File) and CWE-538 (Insertion of Sensitive Information into Externally-Accessible File or Directory). In router/src/lib.rs (lines 182–188), the GenerateParameters struct includes an api_token field that is passed as part of request parameters. In router/src/server.rs (lines 584–596), the generate handler is decorated with #[instrument(skip_all, fields(parameters = ? req.0.parameters, ...))], which causes the Rust tracing framework to serialize the entire GenerateParameters struct — including the api_token — into structured log spans and any connected OTLP trace backends (LoRAX server.rs, LoRAX lib.rs). Exploitation requires only local access to router log files or read access to an OTLP/distributed tracing backend. A technical write-up is available at https://hackmd.io/@1ExmmukzRMWN7B4gQ4W-4Q/predibase-lorax-generate-api-token-logging (Github Advisory).

Successful exploitation allows a local attacker with read access to router log files or OTLP trace backends to recover private adapter API tokens belonging to other users. These tokens are used for per-request tenant isolation and private adapter authentication, so their compromise could allow an attacker to impersonate other users, access private fine-tuned adapters, and potentially abuse billing or rate-limit quotas. There is no integrity or availability impact; the vulnerability is limited to confidentiality loss of authentication credentials (Github Advisory, Red Hat Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, reflecting very low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained to local attackers with existing read access to log files or telemetry infrastructure, significantly limiting the attack surface (Github Advisory, Red Hat Advisory).

1. Gain local access: Obtain read access to the LoRAX router log files (e.g., via a shared system account, misconfigured file permissions, or access to an OTLP/distributed tracing backend such as Jaeger, Zipkin, or a cloud observability platform).
2. Locate log entries: Search router logs for structured tracing spans associated with the generate handler. These spans include the full GenerateParameters field dump due to the #[instrument(fields(parameters = ? req.0.parameters))] macro.
3. Extract api_token values: Parse the log output or OTLP trace data for the parameters field within GenerateParameters spans. The api_token field will appear in plaintext within these records.
4. Reuse harvested tokens: Use the recovered api_token values in crafted POST /generate requests to authenticate as other users, access their private LoRA adapters, or perform inference under their identity (LoRAX server.rs, Github Advisory).

• Logs: Router log entries containing GenerateParameters span fields with a non-null api_token value in plaintext; search for patterns like api_token: Some("<token_value>") in structured tracing output.
• Logs: Unexpected or repeated access to log files by non-administrative accounts, or unusual queries against OTLP trace backends (e.g., Jaeger, Zipkin) filtering on the generate span.
• Network: Outbound connections from the LoRAX host to external OTLP collectors that were not previously configured, potentially exfiltrating trace data containing tokens.
• File System: Unauthorized read access to LoRAX router log files (e.g., /var/log/lorax/ or application-specific log paths) by non-service accounts, detectable via file access audit logs.

A patch is available; users should upgrade Predibase LoRAX to a version beyond 0.12.1 that addresses this issue (Red Hat Advisory, Red Hat Bugzilla). As an interim workaround, restrict read access to router log files and OTLP trace backends to only authorized administrative accounts using OS-level file permissions and access controls. Additionally, consider configuring log sanitization or redaction middleware to strip sensitive fields such as api_token from structured log output before it is written to disk or forwarded to telemetry backends. Rotating any API tokens that may have been exposed in logs is also recommended.