CVE-2026-85725 in LightRAG
Summary
by MITRE • 09/22/2026
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, verify_password in lightrag/api/passwords.py compares plaintext AUTH_ACCOUNTS password values with Python's == operator. The comparison can return after the first mismatching byte, creating response-time differences based on password length and matching prefixes. A network attacker with sufficiently low-latency access can repeatedly query the /login endpoint and use the timing oracle to recover a plaintext-configured password character by character. Deployments using bcrypt-prefixed password values are not affected by this comparison path. This issue is fixed in version 1.5.5.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in LightRAG versions prior to 1.5.5 constitutes a critical timing side-channel attack vector within the authentication mechanism of its API service. The core technical flaw resides in the verify_password function located in lightrag/api/passwords.py, which utilizes Python's standard equality operator for comparing user-supplied credentials against stored password values. This implementation fails to employ constant-time comparison algorithms, thereby introducing a measurable discrepancy in response latency that correlates directly with the number of matching characters between the input and the secret value. In typical string comparison implementations, the evaluation process terminates immediately upon encountering the first byte mismatch. Consequently, if an attacker provides a username associated with a plaintext password configuration, they can exploit this behavior by submitting various candidate passwords and meticulously measuring the server's response time for each attempt.
This timing oracle allows a network attacker to reconstruct the secret password character by character through statistical analysis of latency data. By sending repeated queries to the /login endpoint from a location with sufficiently low-latency access relative to the target server, an adversary can determine which candidate characters result in longer processing times, indicating that more bytes matched before the comparison failed. This method is particularly effective against short or moderately complex passwords where the cumulative timing differences are statistically significant above network jitter and background noise. The attack does not require authentication itself but relies on the ability to send multiple requests to the login endpoint, making it feasible for remote attackers who can maintain a stable connection with low round-trip times to the vulnerable service.
The operational impact of this vulnerability is severe, as it effectively bypasses the intended security controls protecting user accounts configured with plaintext passwords in the AUTH_ACCOUNTS configuration. An attacker gaining access to these credentials could potentially compromise sensitive data processed by LightRAG or escalate privileges within the system depending on the permissions associated with those accounts. It is important to note that this specific timing attack path does not affect deployments utilizing bcrypt-prefixed password values, as such implementations typically involve computationally expensive hashing operations where the time taken for verification remains constant regardless of input similarity, thus neutralizing the side-channel advantage. However, any deployment relying on simple string comparison for plaintext credentials is exposed to this risk until an upgrade or mitigation is applied.
To mitigate this vulnerability, organizations must immediately update LightRAG to version 1.5.5 or later, where the developers have implemented fixes to prevent timing-based reconstruction of passwords. For environments that cannot be updated instantly, a temporary workaround involves ensuring that all password values in AUTH_ACCOUNTS are stored using bcrypt hashing rather than plaintext storage. This approach inherently prevents the use of the vulnerable comparison path and aligns with industry best practices for credential management. From a standards perspective, this flaw is categorized under CWE-208 as an Observable Timing Discrepancy and falls within the ATT&CK framework's T1596 category regarding Probe Behavioral Security Features. Adhering to these remediation steps ensures that authentication mechanisms remain robust against sophisticated side-channel attacks designed to extract secrets through subtle performance variations.