No Rate Limiting on LightRAG's /login Endpoint Enables Unrestricted Password Brute-Forcing

What Happened

A GitHub Security Advisory (GHSA-frch-4w6v-q5xx) discloses that the POST /login endpoint in lightrag-hku (the LightRAG Python package, HKUDS/LightRAG) implements no rate limiting, account lockout, delay, or CAPTCHA on failed authentication attempts. According to the advisory, the login handler in lightrag/api/lightrag_server.py simply verifies the submitted password and returns a 401 on failure, with no throttling logic anywhere in the codebase — the researchers report that a search for slowapi, rate_limit, lockout, or throttle in the API code returns zero results. A working proof-of-concept demonstrates unauthenticated, unlimited password guessing against the endpoint at full network speed. The advisory tracks this as CVE-2026-85734 with a reported CVSS of 9.1, and a public PoC is available.

Why It Matters

Any network-reachable LightRAG deployment is exposed to credential brute-forcing with no built-in resistance. Per the advisory, successful password recovery grants an attacker full authenticated access to documents, the knowledge graph, and administrative operations — meaning this isn't just an account-takeover risk but a path to complete data and control-plane compromise for organizations running LightRAG-backed RAG pipelines. Because LightRAG is often deployed as an internal or semi-internal service, teams may have under-invested in perimeter controls around it, making default exposure more likely than for a hardened public-facing app.

What Defenders Should Watch For

• Inventory whether LightRAG (lightrag-hku) is deployed anywhere in your environment, and whether its /login endpoint (default port 9621 in the PoC) is reachable from untrusted networks — including internal segments, not just the internet.
• Hunt for bursts of rapid, sequential 401 responses from a single source IP or user-agent against /login in web/proxy logs — a hallmark of unthrottled credential-stuffing or dictionary attacks.
• Until an upstream fix lands, consider compensating controls: a WAF or reverse-proxy rate limit / IP-based throttling in front of the endpoint, network segmentation to restrict who can reach it, and enforcement of strong, unique passwords for any LightRAG accounts.
• Review authentication logs for any successful logins following a high volume of failures from the same source, which would indicate a completed brute-force.

Developing Intel

This is a same-day advisory and details may evolve as the maintainers respond and a patched release becomes available. There is currently no df00tech detection page for this issue. For the full technical writeup and PoC, see the original GitHub Security Advisory: GHSA-frch-4w6v-q5xx.