LightRAG CORS Misconfiguration: Wildcard Origins + Credentials Enable Unauthenticated Cross-Origin API Access

Vulnerability Description

LightRAG implements a CORS policy with two dangerous defaults: CORS_ORIGINS="*" (allow all origins) combined with allow_credentials=True. This combination violates the CORS specification's security model. Starlette's CORSMiddleware contains logic that detects this misconfiguration and responds to preflight requests by echoing the requesting Origin header back in the Access-Control-Allow-Origin response header, rather than returning the literal "*". When credentials are enabled, the middleware also sets Access-Control-Allow-Credentials: true. This allows any origin—including attacker-controlled sites—to make credentialed cross-origin requests (XHR, Fetch with credentials: 'include') to the LightRAG API on behalf of a logged-in user.

PoC Significance

The disclosed PoC demonstrates the attack surface clearly: it shows a cross-origin fetch attempt targeting the LightRAG /login endpoint with credentials: 'include', which would succeed if the victim is already authenticated (session cookie would be sent automatically). The PoC proves that an attacker hosting malicious JavaScript on any website can perform API calls as the victim—reading data, modifying settings, or invoking backend operations—without the victim's knowledge. The attack requires only that the victim visit the attacker's site while logged into LightRAG; no additional social engineering or phishing is needed. The precondition (user session) is highly probable in real deployments.

Detection Guidance

HTTP Response Headers: Monitor for Access-Control-Allow-Origin headers that echo user-supplied Origin values combined with Access-Control-Allow-Credentials: true. Use request/response logging in reverse proxies (nginx, Apache) or WAF rules.

Log Indicators:

• Cross-origin preflight requests (OPTIONS method) from unexpected origins to /api/* endpoints
• POST /login requests with Origin header from third-party domains
• Unusual Referer or Origin headers in API request logs paired with session activity

YARA-style Detection (configuration audit):

rule detect_lightrag_cors_misconfiguration {
  strings:
    $cors_wildcard = "CORS_ORIGINS" nocase
    $creds_true = "allow_credentials" nocase
    $equals_star = "=" "*"
    $equals_true = "=" "True" nocase
  condition:
    ($cors_wildcard and $equals_star) and ($creds_true and $equals_true)
}

Mitigation Steps

1. Immediate Patch: Update LightRAG to a patched version that defaults to allow_credentials=False or restricts CORS_ORIGINS to a whitelist.
2. Configuration Change (if patched version unavailable):
   • Set CORS_ORIGINS to a comma-separated whitelist of trusted domains (never use "*" with credentials).
   • Set allow_credentials=False unless cross-origin authenticated requests are explicitly required.
   • Example: CORS_ORIGINS="https://trusted-domain.com,https://app.internal" and allow_credentials=False.
3. Network Isolation: Restrict LightRAG API access to same-origin requests only using a reverse proxy (nginx if ($http_origin != $scheme://$http_host) block).
4. WAF Rules: Implement rules to block preflight requests with suspicious Origin headers, or reject any OPTIONS request lacking a whitelisted origin.

Risk Assessment

Likelihood: High. The misconfiguration is the default, affecting all deployments that do not explicitly override it. The attack requires no authentication bypass or 0-day; it exploits a configuration logic error.

Threat Actor Interest: High. Session hijacking and cross-origin API abuse are commodity attack techniques. Any attacker operating malicious ad networks, compromised high-traffic websites, or browser extensions could deploy this trivially.

Real-World Impact: Critical. Authenticated users' data can be read, modified, or deleted; backend jobs triggered; credentials exposed; lateral movement into backend systems enabled—all without user interaction beyond visiting a compromised site.