CVE-2026-85734 in LightRAG
Summary
by MITRE • 09/22/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in LightRAG versions prior to 1.5.5 represents a critical failure in authentication security controls within its API server component. Specifically, the POST /login endpoint lacks essential mechanisms designed to prevent brute-force attacks against user credentials. In a secure system design, any service accepting password-based authentication must implement rate limiting, account lockout policies, or progressive delays to mitigate automated guessing attempts. The absence of these safeguards allows an external network attacker to submit login requests at maximum throughput without encountering throttling or temporary bans after repeated failures. This architectural oversight effectively removes the primary defense against offline-style credential stuffing and brute-force attacks that are typically conducted over a live API interface.
From a technical perspective, this flaw aligns with CWE-307 Improper Restriction of Excessive Authentication Attempts. By not enforcing any counter for failed authentication attempts or introducing delays between requests, the application allows an attacker to iterate through large dictionaries of common passwords rapidly. The operational impact is severe because LightRAG serves as a retrieval-augmented generation system that manages sensitive data structures including proprietary documents and complex knowledge graphs. Successful exploitation results in full authenticated access to these resources. An adversary who compromises valid credentials gains not only the ability to read confidential information but also potentially executes administrative operations depending on the compromised account's privilege level, leading to potential data exfiltration, intellectual property theft, or manipulation of the underlying AI model context through knowledge graph tampering.
This vulnerability is further contextualized by MITRE ATT&CK technique T1110 Brute Force and specifically sub-technique T1110.001 Password Guessing if performed with a dictionary, or T1110.004 Credential Stuffing if automated credentials from other breaches are used. The lack of detection mechanisms also relates to CWE-798 Use of Hard-coded Credentials if default accounts exist without change, though the primary issue here is the procedural failure in access control enforcement rather than static configuration errors. Attackers can leverage standard HTTP clients or custom scripts to automate this process, making it highly scalable and difficult for defenders to detect via traditional volume-based alerts since each individual request appears as a legitimate login attempt until thresholds are breached, which never happens due to the missing logic.
To mitigate this risk, organizations running LightRAG must immediately upgrade to version 1.5.5 or later where these security controls have been implemented. For environments that cannot update immediately, compensating controls should be deployed at the network perimeter using a Web Application Firewall or reverse proxy such as Nginx or Apache. These tools can enforce rate limiting rules on the /login endpoint by restricting the number of requests per IP address within a specific time window. Additionally, implementing CAPTCHA challenges after a small number of failed attempts can significantly slow down automated attacks without impacting legitimate user experience. It is also critical to ensure that all service accounts use strong, randomly generated passwords and that multi-factor authentication is enabled if supported by the platform's future versions or custom integrations, adding an additional layer of security beyond simple password verification.