CVE-2026-108754 in GPT-Load
Summary
by MITRE • 10/11/2026
GPT-Load through 1.4.11 contains a cleartext logging vulnerability that exposes client proxy keys because the Gin Logger middleware records the raw query string before extractAuthKey strips the key parameter. Attackers with read access to console logs or ./data/logs/app.log can recover proxy keys from Gemini-style requests and use them against the corresponding group.
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 GPT-Load versions through 1.4.11 represents a critical information disclosure flaw rooted in improper logging practices within the application's middleware layer. Specifically, the Gin Logger middleware is configured to record HTTP request details for debugging and monitoring purposes. However, this implementation fails to sanitize sensitive authentication data before persisting it to log files. The core technical failure occurs because the logger intercepts the raw query string of incoming requests prior to the execution of the extractAuthKey function, which is responsible for stripping or masking the client proxy key parameter. Consequently, when a request containing a Gemini-style API call with an embedded authentication token reaches the server, the logging mechanism captures and writes the unmasked, cleartext version of that key directly into the application logs.
This architectural oversight creates a significant security risk by exposing credentials to any entity or process capable of reading the log files. The vulnerability affects both console output and persistent storage located at ./data/logs/app.log. In many deployment scenarios, particularly in containerized environments or shared hosting setups, access control mechanisms for these directories may be insufficiently restrictive. If an attacker gains read access to these logs through local privilege escalation, misconfigured file permissions, or by exploiting a separate vulnerability that allows log injection or reading, they can extract the cleartext proxy keys. This scenario is particularly dangerous because API keys often serve as the primary authentication mechanism for cloud services and third-party integrations, making them high-value targets for malicious actors seeking to impersonate legitimate users or abuse service quotas.
The operational impact of this vulnerability extends beyond simple credential theft. Once an attacker recovers a valid proxy key from the logs, they can use it against the corresponding group associated with that key in the Gemini API ecosystem. This allows unauthorized access to protected resources, potential data exfiltration, and the ability to perform actions on behalf of the compromised account. Furthermore, because the keys are logged in cleartext, there is no cryptographic barrier preventing their immediate reuse by attackers who gain log access. The persistence of these credentials in historical logs means that even if a key is rotated after discovery, previously leaked keys may remain valid for an extended period depending on the service provider's token expiration policies, thereby prolonging the window of exposure and potential damage.
To mitigate this vulnerability, immediate remediation should focus on updating GPT-Load to version 1.4.12 or later where the logging middleware has been patched to exclude sensitive parameters from log output. In environments where upgrading is not immediately feasible, a temporary workaround involves manually configuring the Gin logger to mask query string values that match known patterns for authentication keys. Additionally, organizations should enforce strict file system permissions on all log directories to ensure that only authorized service accounts can read them. Implementing centralized logging solutions with built-in data loss prevention features can also help by automatically detecting and redacting sensitive information before it is stored or transmitted. Regular audits of application logs are recommended to identify any instances where credentials may have already been exposed, followed by immediate rotation of all affected API keys to invalidate the compromised secrets.