Summary
LightRAG versions before 1.5.5 do not limit repeated failed authentication attempts at the POST /login endpoint. A network attacker may rapidly guess account passwords, and successful credential recovery could provide access to documents, the knowledge graph, and administrative operations.
Affected context
The issue occurs in LightRAG deployments using the affected login endpoint without controls that restrict repeated authentication failures. It becomes risky when the endpoint is reachable by an attacker who can submit many password guesses and valid accounts rely on passwords that can eventually be discovered through automated attempts.
Exploit preconditions
- Attack surface: The network-accessible POST /login authentication endpoint
- Required access: Network connectivity to the login service; prior account knowledge may improve targeting but is not necessarily required
- Trigger point: Repeated authentication requests containing guessed credentials
- Why exploitation is possible: The endpoint lacks effective rate limiting, lockout, delay, or failed-attempt counters, allowing guesses to be submitted at high speed
Why this happens
The underlying bug is the failure to restrict repeated authentication attempts, mapping to CWE-307: Improper Restriction of Excessive Authentication Attempts.
Authentication logic accepts failed requests without applying a meaningful per-account, per-source, or distributed-attempt control. This permits automated password guessing to continue at near-normal request speed rather than introducing friction, detection, or temporary blocking.
Potential impact
- An attacker may recover a valid account password
- Unauthorized users could access stored documents and knowledge graph data
- Compromised accounts could be used to perform administrative operations
- Attackers could modify application data or configuration, depending on account privileges
- Credential reuse could enable access to other services
General mitigation guidance
Mitigation generally focuses on enforcing layered controls around authentication attempts and reducing reliance on passwords alone.
Common defensive patterns include:
- Applying adaptive rate limits by account, source, client, and authentication session
- Introducing progressive delays or temporary lockouts after repeated failures
- Tracking failed-attempt counters across distributed application instances
- Using multi-factor authentication and phishing-resistant authentication where practical
- Enforcing strong, unique passwords and preventing known-compromised credentials
- Applying least privilege to authenticated accounts and administrative roles
- Protecting the login endpoint with monitoring, abuse detection, and network policy controls
- Returning responses that avoid revealing whether an account exists
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis and authentication-focused security checks for login handlers lacking throttling or failure tracking
- Code review signals such as direct password verification followed by unrestricted responses
- Tests that submit repeated invalid credentials and verify progressive delay, blocking, or challenge behavior
- Monitoring for bursts of failed logins across accounts, sources, and credential pairs
- Policy enforcement requiring rate limiting, lockout controls, and alerting on exposed authentication endpoints
- Neutral automated security review tools that identify missing brute-force protections
