Skip to main content

LightRAG EUVDEUVD-2026-84548

| CVE-2026-85734 CRITICAL
Improper Restriction of Excessive Authentication Attempts (CWE-307)
2026-09-22 GitHub_M GHSA-frch-4w6v-q5xx
9.1
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Identify exposed LightRAG /login endpoint
  2. Delivery
    Script high-speed password guesses
  3. Exploit
    No rate limit permits unlimited attempts
  4. Execution
    Recover valid credentials
  5. Impact
    Authenticate 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.

Act Now Prioritize within 24-48h. Why: CRITICAL severity + public POC available.
Patch available 0.6% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

LightRAG < 1.5.5

Affected Packages

pypi lightrag-hku fix: 1.5.5
euvd lightrag fix: 1.5.5

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

Vendor (GitHub_M) PRIMARY 9.1 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
vuln.today AI 7.4 HIGH

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).

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

2
Patch available
Sep 22, 2026 - 17:17 EUVD
CVE Published
Sep 22, 2026 - 16:18 cve.org
CRITICAL 9.1

DescriptionCVE.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.

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

Why It Matters

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.

Business Impact: High
Compensating 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

EPSS Score
0.6%
Top 52% exploitable
Prevalence
Low
self-hosted open-source RAG framework, GitHub-popular but modest production footprint
Threat Intel
1
1 source
Exploit
POC
Public exploit code exists
Data Quality
4 sources
Confidence: Medium
EUVD NVD CVE.org EPSS Vulnrichment GHSA GitHub

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.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC Yes
EPSS 0.6%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity + public POC available
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Total

Priority Score

67
Low Medium High Critical
KEV: 0
EPSS: +1
CVSS: +46
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy