CVE-2026-108858 in LoRAX
Summary
by MITRE • 10/11/2026
Predibase LoRAX through 0.12.1 contains a sensitive information exposure vulnerability that writes the caller-supplied api_token from POST /generate request bodies into router logs. Attackers with access to router logs or OTLP trace backends can recover other users' private-adapter tokens recorded through the instrumented GenerateParameters span field.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in Predibase LoRAX versions up to 0.12.1 represents a critical failure in input sanitization and logging hygiene, specifically categorized under CWE-532 as Information Exposure Through Log Files. This flaw arises from the application's practice of writing caller-supplied data directly into operational logs without adequate filtering or masking. In this specific instance, the POST /generate endpoint accepts an api_token parameter within its request body, which is intended for authenticating access to private adapters. Instead of treating this token as sensitive credential material that requires protection during transit and storage, the system instruments the GenerateParameters span field in a manner that captures and persists the raw value into router logs and OpenTelemetry Protocol backends. This behavior transforms what should be ephemeral authentication data into persistent records accessible to anyone with read access to these logging infrastructure components.
The operational impact of this vulnerability is severe due to the nature of the exposed data. Private-adapter tokens are essentially high-value credentials that grant unauthorized users access to proprietary machine learning models or sensitive inference endpoints within the Predibase ecosystem. An attacker who gains access to router logs, whether through misconfigured log aggregation services, insufficiently restricted database permissions on logging databases, or compromised observability backends such as OpenTelemetry collectors, can extract these tokens in plaintext. Once obtained, these tokens allow the attacker to impersonate legitimate users, bypassing authentication controls entirely. This leads directly to unauthorized access to sensitive data processed by the affected models and potentially allows for further lateral movement within the organization's infrastructure if those adapters have permissions to interact with other internal systems or databases.
From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability facilitates Credential Access via Unsecured Logs (T1530) and can be leveraged for Initial Access through Compromised Credentials (T1078). The attacker does not need to exploit a complex code execution flaw or bypass network controls; they simply need access to the logging pipeline. This highlights a common but often overlooked risk in modern microservices architectures where observability tools are granted broad permissions and logs contain unmasked sensitive payloads. The persistence of these tokens in log files means that even if immediate access is revoked, historical data remains exposed indefinitely unless specific remediation steps are taken to purge or redact the affected records.
Mitigation requires a multi-layered approach focusing on both immediate containment and long-term architectural changes. Immediately, administrators should audit their logging configurations for LoRAX instances running version 0.12.1 or earlier to identify if sensitive fields like api_token are being logged in plaintext. It is critical to rotate all potentially compromised private-adapter tokens immediately, as any token recorded in logs prior to remediation must be considered breached. Furthermore, organizations should implement strict log sanitization policies that automatically mask or redact authentication headers and request body parameters containing secrets before they reach the logging subsystem. Upgrading to a patched version of LoRAX where this instrumentation behavior is corrected is essential for long-term security posture. Additionally, access controls on logging backends must be reviewed to ensure that only authorized personnel with specific need-to-know can view raw logs, reducing the blast radius if such exposure occurs in other contexts.