Attack Chain

1. An attacker hosts a malicious website (e.g., attacker.com) designed to interact with LightRAG.
2. A victim, who is logged into their LightRAG instance, navigates to the attacker's malicious website.
3. Embedded JavaScript on attacker.com sends a cross-origin HTTP request to the LightRAG server (e.g., to the /login endpoint) with the credentials: "include" option.
4. The LightRAG server, due to its misconfigured CORSMiddleware (allow_origins=["*"] and allow_credentials=True), processes the preflight request and responds with Access-Control-Allow-Origin set to attacker.com and Access-Control-Allow-Credentials: true.
5. The victim's browser, observing the permissive CORS headers, allows the malicious script to continue making authenticated requests using the victim's session cookies or authentication tokens.
6. The malicious script then makes subsequent authenticated GET requests to sensitive LightRAG API endpoints (e.g., /documents) to retrieve user data.
7. The LightRAG server responds to these requests as if they were legitimate, returning sensitive information like documents or knowledge graph data.
8. The attacker's website subsequently exfiltrates the retrieved sensitive data or issues commands to perform destructive actions, such as deleting the document store.

Impact

The vulnerability represents a permissive cross-domain policy (CWE-942) that allows any website visited by an authenticated LightRAG user to silently make authenticated API requests. The direct consequence is unauthorized access and manipulation of user data. Attackers can exfiltrate sensitive information, including all documents and knowledge graph data, or perform destructive actions such as deleting the entire document store, without the victim's explicit consent or knowledge. There are no reported numbers of victims or specific sectors targeted, but any organization using vulnerable LightRAG versions is at risk.

Recommendation

• Patch CVE-2026-61736 by upgrading the lightrag-hku package to version 1.5.4 or later immediately.
• Review LightRAG web server access logs for unusual Origin headers combined with requests to sensitive API endpoints, especially those not matching your known allowed origins.
• Ensure that the CORS_ORIGINS configuration for LightRAG is set to specific, trusted domains rather than a wildcard (*) when allow_credentials is True.
• Implement security best practices for web applications, including secure credential handling and strict CORS policies.