CVE-2026-85725: Observable Timing Side-Channel Vulnerability in HKUDS LightRAG

HKUDS LightRAG is an open-source framework designed for fast, retrieval-augmented generation (RAG) using large language models. To restrict access to administrative functions, the application exposes API endpoints protected by basic token authentication. The credentials are defined using the AUTH_ACCOUNTS configuration parameter.

Prior to version 1.5.5, the authentication mechanism exposed two major security weaknesses. The primary weakness (CWE-208) resides in the password verification routines, which compare plaintext administrative password strings without a constant-time algorithm. A secondary weakness allows an external attacker to reliably determine valid usernames by analyzing the processing time of authentication requests, bypass the primary layer, and recover plaintext credentials.

The vulnerability stems from two independent implementation details within the authentication layer. First, lightrag/api/passwords.py relies on Python's default equality operator (==) to match supplied passwords against stored plaintext values.

Python's string and byte equality checks optimize comparison performance using two techniques:

1. Length Verification: If the lengths of the two strings differ, the execution returns False immediately.
2. Short-Circuit Comparison: If the lengths match, the interpreter iterates sequentially through characters. When the first mismatching character is identified, it ceases processing and yields False.

Because of this short-circuiting behavior, the execution latency is directly proportional to the number of matching characters in the user's input. A guess that matches the first three characters of a password will take slightly longer to fail than a guess that mismatch on the first character.

Second, the authentication handler in lightrag/api/auth.py evaluates whether the user exists prior to executing password checking. When bcrypt hashing is enabled, verifying a valid user triggers bcrypt.checkpw, which executes in roughly 100 milliseconds. If the username does not exist, the routine returns False immediately in microseconds. This large difference in latency allows external observers to enumerate valid usernames.

In the vulnerable version of the codebase, password verification was implemented as a direct equality operation:

# Vulnerable implementation in lightrag/api/passwords.py
def verify_password(plain_password: str, stored_password: str) -> bool:
    # ...
    return stored_password == plain_password

This behavior is fixed in the patch by utilizing Python's hmac.compare_digest function. The corrected implementation enforces constant-time byte comparisons by processing the full length of the byte strings:

# Patched implementation in lightrag/api/passwords.py
import hmac
 
def verify_password(plain_password: str, stored_password: str) -> bool:
    # ...
    return hmac.compare_digest(
        stored_password.encode("utf-8"), plain_password.encode("utf-8")
    )

Additionally, the username enumeration side-channel was resolved in lightrag/api/auth.py by integrating a dummy verification mechanism. If a username does not exist in the store, the application executes a verification pass against a static, synthetic bcrypt hash (_DUMMY_VERIFY_SPEC). This forces the server to spend identical computational time on invalid accounts:

# Patched implementation in lightrag/api/auth.py
_DUMMY_VERIFY_SPEC = (
    BCRYPT_PASSWORD_PREFIX
    + "$2b$12$ilI0sY2jGfy4h0AVtn6WuutU6BFwzZq5MVvrQYY9fbyQ59NI2NBKa"
)
 
def verify_password(self, username: str, plain_password: str) -> bool:
    stored_password = self.accounts.get(username)
    if stored_password is None:
        # Execute dummy verification to equalize execution time
        verify_password(plain_password, _DUMMY_VERIFY_SPEC)
        return False
 
    return verify_password(plain_password, stored_password)

To exploit these vulnerabilities, an attacker needs a network path with minimal jitter, such as co-location inside the same cloud region or container infrastructure. The attack is carried out in two distinct phases:

Phase 1: Username Enumeration

An attacker sends repetitive requests containing different candidate usernames to the /login endpoint. By sorting the returned network latencies, usernames that delay response times by roughly 100 milliseconds are marked as valid administrative accounts on systems configured with bcrypt.

Phase 2: Password Extraction

Once a username is validated, the attacker attacks the plaintext comparison routine:

1. The attacker determines the password length by testing arbitrary inputs of increasing sizes. The input length matching the target password exhibits a statistically higher response time due to the subsequent character comparisons.
2. The attacker iterates through characters for each index position. If the password is admin123 and the attacker sends aaaa, it fails immediately at index 0. Sending axxx fails at index 1, which requires slightly more time. Analyzing the latency distributions over a high number of requests isolates the correct character prefix, eventually reconstructing the credential.

A successful attack compromises the confidentiality of administrative credentials for the LightRAG framework. This vulnerability possesses a CVSS 3.1 rating of 5.9 (Medium) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N.

The attack complexity is designated as High (AC:H) because measuring sub-millisecond differences over a network requires precise statistical analysis, filtering algorithms, and low network latency. However, in containerized or shared network architectures, these requirements are met. Compromise of administrative passwords grants attackers write and read capabilities over the retrieval-augmented generation engine, including the ability to manipulate indexed documentation, execute prompt injections, and poison generative AI outputs.

The primary resolution is to upgrade HKUDS LightRAG to version 1.5.5 or higher, which integrates the constant-time comparisons and the dummy bcrypt executions.

Additionally, administrators must configure their deployment's passwords securely. When storing accounts in the AUTH_ACCOUNTS configurations, passwords must be formatted using cryptographic bcrypt hashes prefixed with the {bcrypt} tag. Plaintext values are discouraged, as any deployment storing unhashed passwords remains vulnerable to local configuration leakage and other password-recovery mechanisms.