CVE-2026-85734: Brute-Force and CPU-Exhaustion DoS in LightRAG API /login Endpoint

LightRAG is an open-source framework designed for retrieval-augmented generation. It exposes a web-based API endpoint at /login inside the lightrag/api/lightrag_server.py component to handle administrative and user authentication.

Prior to version 1.5.5, this authentication endpoint operated without any rate-limiting controls, failure counters, or account lockout mechanisms. The lack of throttling exposes the system's entry point to automated high-frequency brute-force attacks.

An unauthenticated remote attacker can exploit this design flaw to systematically guess passwords at maximum network speed. Successful credential recovery exposes the private data stored within LightRAG, including the internal knowledge graph, vector store indexes, and primary administrative configurations.

The fundamental flaw resides within lightrag/api/lightrag_server.py under the handler for the POST /login endpoint. The server parsed incoming authentication credentials and invoked the verify_password function without performing any intermediate state validation on the origin IP address or the requested username.

This behavior classifies as CWE-307: Improper Restriction of Excessive Authentication Attempts. Because the endpoint lacked a stateful history of failed attempts, it immediately processed every authentication request, verifying credentials against the stored password hashes.

Additionally, the verification process utilizes the CPU-bound bcrypt hashing function. In asynchronous Python frameworks such as FastAPI and Uvicorn, CPU-intensive operations executed synchronously inside the main event loop block the single thread. An attacker sending concurrent login requests forces the server to spend excessive clock cycles on bcrypt computations, starving the event loop and preventing the application from serving legitimate traffic.

Before the remediation in version 1.5.5, the /login route directly called the blocking verification helper in the main thread without checking any rate-limiting state:

# Vulnerable Implementation
@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    # Blocking bcrypt execution in the main async thread
    password_ok = auth_handler.verify_password(form_data.username, form_data.password)
    if not password_ok:
        raise HTTPException(status_code=401, detail="Incorrect credentials")
    # Generate token...

The patch introduced in version 1.5.5 resolves both the lack of brute-force protection and the event-loop blocking issue. First, it implements a sliding-window memory tracker LoginRateLimiter that maintains failures per unique IP and username. Second, it shifts the CPU-bound bcrypt verification to a separate worker thread using asyncio.to_thread:

# Patched Implementation inside lightrag/api/lightrag_server.py
client_ip = request.client.host if request.client else "unknown"
rate_limit_key = f"{client_ip}:{username}"
 
# Pre-flight rate limit check
retry_after = login_rate_limiter.retry_after(rate_limit_key)
if retry_after is not None:
    raise HTTPException(
        status_code=429,
        detail="Too many failed login attempts. Please try again later.",
        headers={"Retry-After": str(int(retry_after) + 1)},
    )
 
# Non-blocking CPU execution on an auxiliary worker thread
password_ok = await asyncio.to_thread(
    auth_handler.verify_password, username, form_data.password
)
if not password_ok:
    login_rate_limiter.record_failure(rate_limit_key)
    raise HTTPException(status_code=401, detail="Incorrect credentials")

By checking the rate limiter before executing asyncio.to_thread, the application avoids the computational cost of bcrypt for blacklisted clients. This effectively mitigates the CPU-exhaustion denial-of-service vector.

An attacker can exploit this vulnerability using programmatic automated tools. The attack relies on sending repeated POST HTTP requests to the /login endpoint containing targeted username guesses and a credential dictionary.

The following simple proof-of-concept Python script demonstrates the lack of throttling on vulnerable targets:

import requests
import time
 
target_url = "http://localhost:8020/login"
credentials = {"username": "admin", "password": "wrong_password_attempt"}
 
for attempt in range(1, 20):
    start_time = time.time()
    response = requests.post(target_url, data=credentials)
    duration = time.time() - start_time
    print(f"Attempt {attempt}: Status {response.status_code} in {duration:.2f}s")

On a vulnerable host, all 20 requests return HTTP status 401 Unauthorized without any delay or lockouts. On a patched instance, attempts beyond the 5-request limit return HTTP status 429 Too Many Requests.

The impact of successful exploitation is critical. By successfully brute-forcing administrative credentials, an attacker obtains a valid JWT authorization token.

This token grants administrative access to LightRAG's central functionalities. Attackers can read sensitive internal corporate documents parsed by the engine, query the proprietary global knowledge graph, and perform arbitrary document uploads or deletions.

Furthermore, the accompanying availability impact is highly practical. Because the system can be forced to run intensive bcrypt operations continuously, an unauthenticated attacker can effectively lock the application server in a perpetual busy-loop, rendering the RAG platform completely unresponsive to integration workflows.

To resolve this vulnerability, organizations must upgrade LightRAG to version 1.5.5 or higher. The patch introduces configurable parameters to adjust the login lockout thresholds:

• LOGIN_MAX_FAILED_ATTEMPTS (Default: 5)
• LOGIN_LOCKOUT_WINDOW_SECONDS (Default: 300.0)

While the sliding-window memory check resolves direct single-IP attacks, security teams must recognize its architectural limitations. Because the tracking dictionary is kept strictly in volatile RAM, restarting the container clears all lockouts. Additionally, in multi-process setups (such as Gunicorn running multiple Uvicorn workers), each worker maintains a separate state, multiplying the effective threshold by the worker count.

Furthermore, attackers operating from distributed botnets or rotating IP proxies can bypass the per-IP constraints. To completely secure the platform, deploy LightRAG behind a dedicated reverse proxy or Web Application Firewall (WAF) such as Nginx or Cloudflare. Configure rate-limiting rules directly at the proxy tier on the /login path to apply unified, persistent blocking policies.