CVE-2026-61736: LightRAG CSRF Vulnerability

CVE-2026-61736 Overview

CVE-2026-61736 is a critical Cross-Origin Resource Sharing (CORS) misconfiguration in LightRAG, an open-source retrieval-augmented generation server maintained by HKUDS. Versions prior to 1.5.4 ship with CORS_ORIGINS=* combined with allow_credentials=True in lightrag/api/lightrag_server.py. This pairing causes Starlette's CORSMiddleware to effectively whitelist every origin for credentialed cross-origin requests. Any malicious website visited by an authenticated LightRAG user can silently issue authenticated API calls, exfiltrating documents and knowledge graph data or performing destructive actions such as deleting the document store. The issue is classified under CWE-942: Permissive Cross-domain Policy with Untrusted Domains and is fixed in version 1.5.4.

Critical Impact
Authenticated LightRAG users visiting attacker-controlled websites risk silent exfiltration of ingested documents and knowledge graphs, as well as destructive API actions performed under their session credentials.

Affected Products

LightRAG server versions prior to 1.5.4
lightrag/api/lightrag_server.py deployments using the default CORS_ORIGINS=* configuration
Docker Compose deployments derived from the bundled env.docker-compose-full template

Discovery Timeline

2026-07-15 - CVE-2026-61736 published to NVD
2026-07-15 - Last updated in NVD database
2026-07-15 - GitHub Security Advisory GHSA-6x6h-qqr7-855w published alongside LightRAG v1.5.4

Technical Details for CVE-2026-61736

Vulnerability Analysis

LightRAG exposes an HTTP API used by an in-browser WebUI and by external clients. The server initializes Starlette's CORSMiddleware with allow_origins derived from the CORS_ORIGINS environment variable and allow_credentials=True. When CORS_ORIGINS is unset, the helper get_cors_origins() defaults to ["*"].

Starlette's middleware, when given a wildcard alongside credentialed requests, reflects the requesting origin in Access-Control-Allow-Origin and returns Access-Control-Allow-Credentials: true. Browsers accept this response for any origin, allowing cookies and authorization headers to accompany the request. The result is functionally equivalent to disabling the same-origin policy for authenticated LightRAG sessions.

Root Cause

The root cause is an insecure default combined with a middleware configuration that violates the CORS specification's prohibition against pairing wildcard origins with credentials. The get_cors_origins() function returned ["*"] for the default deployment, and the middleware was instantiated with allow_credentials=True unconditionally.

Attack Vector

An attacker hosts a malicious page and lures an authenticated LightRAG user to visit it. The page issues cross-origin fetch calls to the victim's LightRAG server with credentials: 'include'. Because the server accepts any origin for credentialed requests, the browser transmits the user's session cookies. The attacker can enumerate documents, download knowledge graph exports, or invoke destructive endpoints such as document deletion.

python

    def get_cors_origins():
        """Get allowed origins from global_args.

        Returns a list of allowed origins. The wildcard default ["*"] applies
        only when CORS_ORIGINS is unset (config defaults the value to "*"). An
        explicitly empty or origin-less value (e.g. CORS_ORIGINS= or a stray
        comma) fails closed, returning an empty list so that no cross-origin
        browser access is granted rather than silently widening to "*". Empty
        entries (e.g. from a trailing comma) are dropped.
        """
        origins_str = global_args.cors_origins
        if origins_str == "*":
            return ["*"]
        return [origin.strip() for origin in origins_str.split(",") if origin.strip()]

Source: GitHub Commit ebba6548. The patched helper fails closed on explicitly empty CORS_ORIGINS values, and companion commits ensure the middleware never pairs the * wildcard with allow_credentials=True.

Detection Methods for CVE-2026-61736

Indicators of Compromise

HTTP responses from LightRAG containing Access-Control-Allow-Origin values that reflect arbitrary third-party origins alongside Access-Control-Allow-Credentials: true
Unexpected Origin headers on authenticated LightRAG API calls, particularly against document, query, and knowledge graph endpoints
Bulk document read, export, or delete API calls that originate from browser sessions rather than the bundled WebUI

Detection Strategies

Inspect running LightRAG configurations for CORS_ORIGINS=* or an unset value combined with any authentication middleware
Review reverse proxy and application logs for OPTIONS preflight requests carrying Origin values that do not match approved WebUI hostnames
Correlate authenticated API requests with browser Referer and Origin headers to identify cross-origin activity not initiated by the trusted WebUI

Monitoring Recommendations

Alert on any LightRAG API response advertising credentialed CORS access to non-allowlisted origins
Track spikes in document deletion or bulk export endpoints called from browser user agents
Maintain audit logging for authenticated session activity and forward events to a centralized analytics platform for anomaly review

How to Mitigate CVE-2026-61736

Immediate Actions Required

Upgrade LightRAG to version 1.5.4 or later, which contains the CORS middleware fixes referenced in pull request #3317
Replace any CORS_ORIGINS=* setting with an explicit allowlist of trusted origins before restarting the service
Invalidate existing sessions and rotate API credentials after upgrading, in case they were exposed via cross-origin abuse

Patch Information

The fix ships in LightRAG v1.5.4. Key commits include df68d75f, which changes wildcard detection to membership-based logic, and ebba6548, which fails closed when CORS_ORIGINS is explicitly empty. Commit 09567a4c documents the new configuration guidance in env.docker-compose-full and env.example.

Workarounds

Set CORS_ORIGINS to an explicit comma-separated allowlist matching only trusted WebUI or client hostnames
Front LightRAG with a reverse proxy that strips or rewrites Access-Control-Allow-Origin and Access-Control-Allow-Credentials headers for untrusted origins
Restrict network access to LightRAG so that only same-origin WebUI traffic can reach authenticated endpoints until the upgrade is applied

bash

# Configuration example from env.example (v1.5.4)
### CORS allowed origins for browser cross-origin requests. Defaults to "*"
### (any origin). The bundled WebUI is served same-origin and does not need
### this; set an explicit allowlist only when a different-origin web app calls
### the API from a browser. Credentialed (cookie) cross-origin requests are
### only enabled for an explicit allowlist, never for the "*" wildcard.
CORS_ORIGINS=http://localhost:3000,http://localhost:8080

Source: GitHub Commit 09567a4c.