Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-61808

CVE-2026-61808: LightRAG Information Disclosure Flaw

CVE-2026-61808 is an information disclosure vulnerability in LightRAG that exposes the API server to unauthenticated access, allowing attackers to read documents and modify the knowledge graph. This article covers technical details, affected versions through 1.5.4, impact assessment, and available mitigations including the 1.5.5rc1 patch.

Published:

CVE-2026-61808 Overview

CVE-2026-61808 is a missing authentication vulnerability [CWE-306] in LightRAG, an open-source retrieval-augmented generation framework maintained by HKUDS. Through version 1.5.4, the LightRAG API server binds to all network interfaces (0.0.0.0) with authentication disabled by default. Any unauthenticated attacker with network access to the server can read indexed documents, upload or delete files, modify the knowledge graph, cancel pipelines, clear caches, and consume large language model (LLM) resources. The maintainers addressed the issue in version 1.5.5rc1.

Critical Impact

Unauthenticated network attackers gain full read and write access to indexed documents, the knowledge graph, and backing LLM resources.

Affected Products

  • LightRAG API server versions up to and including 1.5.4
  • Deployments exposing the default HOST=0.0.0.0 binding without LIGHTRAG_API_KEY or AUTH_ACCOUNTS configured
  • Retrieval-augmented generation pipelines that rely on the LightRAG server component

Discovery Timeline

  • 2026-08-07 - CVE-2026-61808 published to the National Vulnerability Database
  • 2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-61808

Vulnerability Analysis

LightRAG ships an API server whose default configuration binds the listener to 0.0.0.0 and disables authentication. The combination exposes every administrative and data endpoint to any host that can reach the process on PORT=9621. Attackers do not need credentials, user interaction, or prior access.

Once reachable, the server accepts requests that read indexed document content, upload new documents, delete existing ones, mutate the knowledge graph, cancel ingestion pipelines, and clear internal caches. Because the server proxies calls to configured LLM backends, an attacker can also drive arbitrary inference traffic and drain paid API quotas.

Root Cause

The root cause is an insecure default configuration [CWE-306]. The shipped env.example set HOST=0.0.0.0 without requiring an API key or account. The auth dependency layer treated missing credentials as permitted, and the WHITELIST_PATHS handling allowed catch-all entries such as /* to silently exempt the Ollama-compatible /api routes.

Attack Vector

An attacker on the same network segment, or anywhere on the internet if the server is exposed, sends direct HTTP requests to the LightRAG endpoints. No authentication header is required. The following patch excerpts show the hardening applied in the fix.

text
 ###########################
 ### Server Configuration
 ###########################
+### HOST binds to all network interfaces (0.0.0.0) by default.
+### SECURITY: only expose 0.0.0.0 together with LIGHTRAG_API_KEY or AUTH_ACCOUNTS
+### (see "Login and API-Key Configuration" below). Without authentication, a
+### server on 0.0.0.0 grants anyone on the network full access to your documents
+### and knowledge graph. Bind to 127.0.0.1 for local-only access.
 HOST=0.0.0.0
 PORT=9621
 WEBUI_TITLE='My Graph KB'

Source: GitHub commit 0bd1024

python
def whitelist_exposes_api_routes(whitelist_paths: str) -> bool:
    """Return True if WHITELIST_PATHS exempts any Ollama-compatible /api route."""
    for entry in whitelist_paths.split(","):
        entry = entry.strip()
        if not entry:
            continue
        if entry.endswith("/*"):
            prefix = entry[:-2]
            if "/api".startswith(prefix) or prefix.startswith("/api/"):
                return True
        else:
            if entry == "/api" or entry.startswith("/api/"):
                return True
    return False

Source: GitHub commit 0bd1024 — lightrag/api/utils_api.py

The new helper detects catch-all whitelist entries so operators cannot inadvertently expose /api/chat and similar endpoints.

Detection Methods for CVE-2026-61808

Indicators of Compromise

  • Unauthenticated HTTP requests to LightRAG endpoints on port 9621, including /documents, /graphs, and /api/chat
  • Unexpected document uploads, deletions, or knowledge graph mutations in LightRAG storage
  • Spikes in outbound LLM API traffic or provider billing tied to the LightRAG service account

Detection Strategies

  • Scan internal and perimeter ranges for TCP 9621 and validate whether the LightRAG server responds without an Authorization header or API key
  • Review LightRAG access logs for successful POST, PUT, and DELETE requests originating from unexpected client addresses
  • Correlate LLM provider usage reports against expected LightRAG workload volume to identify quota abuse

Monitoring Recommendations

  • Alert on any LightRAG process bound to 0.0.0.0 without LIGHTRAG_API_KEY or AUTH_ACCOUNTS set in its environment
  • Monitor for WHITELIST_PATHS values containing /* or other catch-all patterns that expose /api routes
  • Log and review changes to the LightRAG knowledge graph and document index for anomalous automated activity

How to Mitigate CVE-2026-61808

Immediate Actions Required

  • Upgrade LightRAG to version 1.5.5rc1 or later
  • Configure LIGHTRAG_API_KEY or AUTH_ACCOUNTS before exposing the server on any non-loopback interface
  • Restrict inbound access to port 9621 at the network or firewall layer until the upgrade is complete

Patch Information

The fix ships in LightRAG 1.5.5rc1 via GitHub commit 0bd1024. It updates the default configuration guidance, warns operators when 0.0.0.0 is used without authentication, and adds whitelist_exposes_api_routes to detect catch-all whitelist entries that would otherwise expose the Ollama-compatible /api endpoints. Full context is available in the GitHub Security Advisory GHSA-mmg5-8x8q-v934.

Workarounds

  • Bind the server to 127.0.0.1 by setting HOST=127.0.0.1 for local-only deployments
  • Place LightRAG behind a reverse proxy that enforces authentication and IP allowlisting
  • Remove any WHITELIST_PATHS entries such as /* that exempt /api routes from authentication
bash
# Configuration example: secure LightRAG environment
HOST=127.0.0.1
PORT=9621
LIGHTRAG_API_KEY=replace-with-a-long-random-value
# Or, for multi-user deployments:
# AUTH_ACCOUNTS=admin:replace-with-strong-password
# Avoid catch-all whitelist entries such as "/*"
WHITELIST_PATHS=

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.