Vulnerabilidades do Hkuds Lightrag
🔔 Criar alerta RSS Verificador de versão
CVEs publicadas que afetam Hkuds Lightrag: 3 registro(s), com versões afetadas e correções.cpe:2.3:a:hkuds:lightrag
CVE-2026-61740
Crítica · 9.3
CWE-287 15/07/2026
LightRAG: Authentication bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.4, when LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset, X-API-Key protection can be bypassed because lightrag/api/auth.py falls back to a hardcoded DEFAULT_TOKEN_SECRET, /auth-status and /login can mint guest JWTs, and combined_dependency in lightrag/api/utils_api.py accepts a valid guest token before checking the API key. A remote unauthenticated attacker can call endpoints guarded by combined_auth, including document read, upload, deletion, graph mutation, and query endpoints. This vulnerability is fixed in 1.5.4.
CVE-2026-61736
Crítica · 9.3
CWE-942 15/07/2026
LightRAG: CORS Wildcard + Credentials Enables Any-Origin Credentialed Requests
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.4, the server defaults to CORS_ORIGINS=* combined with allow_credentials=True in lightrag/api/lightrag_server.py, causing Starlette CORSMiddleware to effectively whitelist every origin for credentialed cross-origin requests. Any malicious website visited by an authenticated LightRAG user can silently make authenticated API requests, exfiltrating documents and knowledge graph data or performing destructive actions such as deleting the document store. This vulnerability is fixed in 1.5.4.
CVE-2026-39413
Média · 6.5
CWE-347 08/04/2026
LightRAG has a JWT Algorithm Confusion Vulnerability in LightRAG API
LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.4.14, 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. This vulnerability is fixed in 1.4.14.