Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify exposed LightRAG /login endpoint
-
DeliveryScript high-speed password guesses
-
ExploitNo rate limit permits unlimited attempts
-
ExecutionRecover valid credentials
-
ImpactAuthenticate to documents, knowledge graph, and admin operations
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Brute-force prevention, rate limiting
|
| Exploitation Conditions | Requires the LightRAG API server (POST /login in lightrag/api/lightrag_server.py) to be network-reachable by the attacker and configured with authentication enabled so credentials exist to guess; no valid account, user interaction, or prior authentication is needed to launch guesses. Exploitation is LIMITED primarily by password strength - a strong, non-default password makes brute-force recovery impractical - and by any upstream reverse-proxy or WAF rate limiting, which the vendor explicitly recommends since the in-process limiter is per-worker (effective limit N× the configured value under gunicorn with N workers). Affects versions prior to 1.5.5. |
| Impact | Signals conflict on whether this is a top priority. The vendor CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N) treats unauthenticated network brute-forcing as low-complexity, but AC:L is optimistic: successful credential recovery is entirely gated on password guessability - a strong password makes exploitation impractical, which argues for AC:H and a real-world score closer to 7.2. There is no EPSS score, no CISA KEV listing, and no public POC provided, so this is 'no public exploit identified at time of analysis' rather than confirmed exploitation. The high C:H/I:H reflect the CONSEQUENCE of a guessed credential (full access to documents, knowledge graph, and admin operations), not the ease of the brute-force itself. The absence of any rate limit is a genuine and confirmed weakness (fixed in v1.5.5), but realistic risk is dominated by deployment factors the CVSS ignores: password strength and whether an upstream reverse-proxy/WAF already imposes rate limiting. Net: a legitimate hardening priority for any internet-exposed LightRAG instance with weak/default credentials, but not a drop-everything emergency absent evidence of active exploitation. |
| Exploit ScenarioDerived | An attacker locates an internet-exposed LightRAG API server and scripts automated password guesses against POST /login, which imposes no lockout, delay, or counter, allowing attempts at full request speed. Once a valid password is recovered, the attacker authenticates and gains access to indexed documents, the knowledge graph, and administrative operations. No public POC is provided, and success depends on the target account using a weak or guessable password. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 22, 2026
Unthrottled password guessing against the LightRAG POST /login endpoint allows an unauthenticated remote attacker to submit credential attempts at full request speed until a valid account password is recovered, after which the attacker gains authenticated access to documents, the knowledge graph, and administrative operations. Versions prior to 1.5.5 shipped no rate limit, lockout, delay, or failure counter for authentication attempts (CWE-307). Real-world exploitability is bounded by password strength - the independent assessment rates the vector AC:H for exactly this reason - and no public exploit code or confirmed active exploitation was identified at time of analysis; the vendor added an in-process sliding-window limiter in 1.5.5.
RemediationAI
Vendor-released patch: upgrade LightRAG to version 1.5.5 or later (release: https://github.com/HKUDS/LightRAG/releases/tag/v1.5.5; advisory: https://github.com/HKUDS/LightRAG/security/advisories/GHSA-frch-4w6v-q5xx; fix PR: https://github.com/HKUDS/LightRAG/pull/3424, commit 135bc9056e9ecd800c1abe2f2ce24d1a86622a54). The fix introduces two environment knobs - LOGIN_MAX_FAILED_ATTEMPTS (default 5) and LOGIN_LOCKOUT_WINDOW_SECONDS (default 300) - that reject further attempts with HTTP 429 and a Retry-After header once a client-IP plus username key exceeds the threshold; note the trade-off that setting LOGIN_MAX_FAILED_ATTEMPTS=0 disables the protection entirely, and that counters are held in memory per server process, so under gunicorn with N workers the effective limit is N times the configured value. For strict enforcement (and for deployments that cannot upgrade immediately), put the API behind a reverse proxy or WAF rate limit on the login path - for example nginx limit_req/limit_conn or a cloud WAF rule - accepting that IP-keyed proxy limits can transiently affect legitimate users sharing a NAT egress, and that the vendor deliberately does not trust X-Forwarded-For for bucket keying. As the primary pre-patch compensating control, enforce long, strong, non-default account passwords, which is what makes brute-force recovery impractical given the assessed AC:H rating, and add fail2ban or equivalent alerting on repeated HTTP 401/429 responses from a single source. Finally, reduce exposure by binding the LightRAG API to localhost or a private interface and requiring VPN, SSH tunnel, or mutual TLS for remote access instead of publishing /login to the internet; disabling authentication outright is not an acceptable workaround because it removes all access control on documents, the knowledge graph, and administrative endpoints.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in pypi, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
LightRAG (HKUDS) is a Python retrieval-augmented generation framework whose API server is built on FastAPI; the affected component is the POST /login endpoint defined in lightrag/api/lightrag_server.py, which consumes an OAuth2PasswordRequestForm and validates credentials through auth_handler.verify_password (bcrypt). The root-cause class is CWE-307, Improper Restriction of Excessive Authentication Attempts: the endpoint performed a bcrypt verification and, on mismatch, simply returned HTTP 401, with no per-identity failure accounting, so an attacker could iterate guesses indefinitely. The upstream fix in v1.5.5 introduces lightrag/api/login_rate_limit.py, a sliding-window LoginRateLimiter keyed by client IP plus username. Notable design details from the patch: the limiter is consulted before the bcrypt call so a locked key is rejected without paying hashing cost; attempts are pre-reserved before the awaited bcrypt work to close a TOCTOU window in which many concurrent requests could all pass the check before any resolved; 'confirmed' (wrong-password) and 'pending' (in-flight) state are tracked separately so a concurrent correct login does not emit a false account-locked alert; X-Forwarded-For is deliberately not trusted because it is spoofable, and buckets are separated by username so all clients sharing a reverse-proxy IP cannot lock each other out. Password verification already ran in a worker thread to avoid event-loop starvation, and the CPE cpe:2.3:a:hkuds:lightrag:*:*:*:*:*:*:*:* confirms the wildcard covers all releases before 1.5.5. Because the limiter is in-memory and per server process, its effective threshold under gunicorn with N workers is N times the configured value - an important caveat for the fix itself.
Know when Lightrag gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Unauthenticated network vector (PR:N, AV:N), but success is contingent on guessing a weak password so AC:H; a recovered credential yields full read/write and admin access (C:H/I:H, A:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.5, the POST /login endpoint in lightrag/api/lightrag_server.py does not impose a rate limit, account lockout, delay, or counter for failed authentication attempts. A network attacker can submit password guesses at full request speed until a valid account password is found. Successful credential recovery grants authenticated access to documents, the knowledge graph, and administrative operations. This issue is fixed in version 1.5.5.
Articles & Coverage 1
Technical POC Analysis
CWE-307: Improper Restriction of Excessive Authentication Attempts.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Internet-reachable LightRAG deployments running versions before 1.5.5 accept login attempts with no rate limit, lockout, delay, or failure counter, so an attacker can guess account passwords at full request speed and, on success, reach stored documents, the knowledge graph, and administrative functions. Practical exposure hinges on credential strength - the vector is rated AC:H for that reason - so the organizations most at risk are those running weak, reused, or default passwords on exposed instances. Leadership should treat a single compromised account as a full compromise of the indexed knowledge base and its administrative controls.
No vendor-released patch identified at time of analysis per the record's patch field; interim mitigations include fronting LightRAG with a reverse proxy or WAF that enforces per-IP login rate limiting and lockout, network-restricting or VPN-gating the /login endpoint, enforcing strong unique passwords and MFA, and alerting on high-volume authentication failures. Upgrading to 1.5.5, which introduces an in-process sliding-window limiter, is the vendor-documented remediation. Exploitation status: no public exploit identified at time of analysis.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Cross-origin data theft in LightRAG server versions prior to 1.5.4 allows any malicious website to make authenticated, c
Server-side request forgery (CWE-918) in LightRAG before 1.5.5 lets an authenticated caller who can upload a Markdown or
Password recovery via a timing oracle in LightRAG's /login endpoint lets remote, unauthenticated attackers (CVSS PR:N/UI
Authentication bypass in HKUDS LightRAG before 1.5.4 lets a remote unauthenticated attacker defeat X-API-Key protection
Stored cross-site scripting (CWE-79) in the LightRAG WebUI prior to 1.5.5 lets an attacker who can ingest a document per
LightRAG API server versions prior to 1.5.5 return raw Python exception text to network clients through error handlers i
EUVD-2026-84548
GHSA-frch-4w6v-q5xx
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB