GHSA-frch-4w6v-q5xx: Critical severity pip/lightrag-hku vulnerability
Summary The POST /login endpoint has no rate limiting, account lockout, or delay on failed attempts. An attacker can submit unlimited password guesses at full network speed.
Details
python lightrag/api/lightragserver.py:2161 @app.post("/login") async def login(formdata: OAuth2PasswordRequestForm = Depends()): if not authhandler.verifypassword(username, formdata.password): raise HTTPException(statuscode=401, detail="Incorrect credentials") # No: rate limit / lockout / backoff / CAPTCHA / attempt counter
A search for slowapi, ratelimit, lockout, or throttle in lightrag/api/ returns zero results.
PoC
bash Brute-force /login with a wordlist, no throttling while IFS= read -r pass; do code=$(curl -s -o /dev/null -w "%{httpcode}" \ -X POST http://<TARGET>:9621/login \ -d "username=admin&password=${pass}") [ "$code" = "200" ] && echo "[FOUND] $pass" && break done < /usr/share/wordlists/rockyou.txt
Impact Improper restriction of authentication attempts. Any network-reachable attacker can brute-force user passwords without restriction. Once credentials are recovered, the attacker gains full authenticated access to all documents, knowledge graph, and administrative operations.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/lightrag-hkuto a version that resolves this vulnerability.Fixed in 1.5.5
Event History
Frequently Asked Questions
Who can exploit this issue?
Any attacker that can reach the application's POST /login endpoint over the network can submit password guesses. No existing account or other privileges are required.
What makes exploitation possible?
The login endpoint accepts unlimited failed authentication attempts without rate limiting, account lockout, delays, CAPTCHA, or attempt counters. An attacker needs a target username and password guesses, such as a wordlist.
Are deployments affected by default?
The provided endpoint implementation contains no authentication-attempt restrictions, and the reported search found no rate-limiting, lockout, or throttling support under lightrag/api/. Deployments exposing this login endpoint should be treated as susceptible unless compensating controls restrict attempts.
What can be done before a patch is available?
Restrict network access to the login endpoint and apply compensating controls that limit repeated authentication attempts, such as rate limiting, throttling, backoff, or account lockout. Use strong passwords to reduce the likelihood that password guessing succeeds.
How would an attacker know that guessing succeeded?
The supplied proof of concept identifies a successful guess when POST /login returns HTTP 200. Failed credential attempts return HTTP 401 with an "Incorrect credentials" message.