LightRAG's API Surface Is Small Enough for Direct Authentication Evidence
AI knowledge-base services are often deployed internally with a simple API key. That makes them easy to overlook in external inventory even though they can ingest, query and delete important data.
ZoomEye count-only queries were run with sub_type=all, page 1 and page size 1 on 2026-11-13 between 07:40 and 07:43 Asia/Shanghai.
| Query | Matching assets |
|---|---|
app="LightRAG" |
114 |
title="LightRAG" |
150 |
The numbers are close and modest. They identify a candidate pool, not a list of vulnerable knowledge bases.
The authentication path
GHSA-f4vv-55c2-5789 describes LightRAG versions through 1.4.15 with no patched version listed. When LIGHTRAG_API_KEY is set but AUTH_ACCOUNTS is unset, the service can fall back to a hardcoded default JWT secret.
The public /auth-status and /login endpoints can mint guest tokens. The combined authorization dependency accepts a guest token before the API-key comparison. An attacker can then reach document upload, query and deletion routes.
The flaw is configuration-sensitive. The external query cannot see the environment variables or the authorization code path. Owners need to inspect the deployed process and test a forged guest token.
A practical review
Match the app and title candidates to known LightRAG hosts and internal documentation systems. Record the configured authentication mode, API exposure and token secret source.
Check whether /auth-status or /login is reachable without a gateway. Test a forged guest JWT with no X-API-Key in a non-production environment. A correct deployment should reject it before the document handler runs.
Review document changes and queries for activity that did not come from a known agent or user. Preserve uploaded source files and index state before remediation.
Reduce exposure
Put the API behind a trusted reverse proxy with authentication, disable the API-key-only mode and configure AUTH_ACCOUNTS with a unique TOKEN_SECRET where supported.
Rotate the API key, token secret and service credentials. Rebuild an index from trusted documents if an attacker could modify its contents.
Evidence
Store the dorks, counts and collection time with the host inventory. Keep the external candidate list separate from the internal configuration result. The small ZoomEye footprint helps prioritize ownership outreach; it does not replace request-level verification.
Top comments (0)