Loading story…
A critical missing-authentication flaw tracked as CVE-2026-61808 affects LightRAG through version 1.5.4, leaving its API server exposed in the default configuration by binding to 0.0.0.0 with authentication disabled. The issue allows unauthenticated remote attackers to reach sensitive API functions over the network and perform actions including reading indexed document content, uploading or deleting documents, modifying the knowledge graph, canceling pipelines, clearing caches, and consuming LLM resources. The vulnerability is rated CVSS 9.8 and mapped to CWE-306.
LightRAG addressed the issue in 1.5.5rc1 with code, test, and documentation changes that add startup warnings when the service is bound to a non-loopback address without authentication and when WHITELIST_PATHS leaves /api/* routes publicly accessible. The patch also improves detection of wildcard whitelist entries such as /*, updates container examples and deployment guidance, and warns operators that Ollama-compatible endpoints can remain exposed unless access is restricted, such as limiting WHITELIST_PATHS to /health. Recommended mitigations are to upgrade, enable LIGHTRAG_API_KEY or AUTH_ACCOUNTS with TOKEN_SECRET, and restrict network access to the API server.
Track how attackers are adapting to this technology.
2 events from the most recent confirmed update back to the earliest known activity.
CVE-2026-61808 was published for a critical missing-authentication vulnerability affecting LightRAG through version 1.5.4, where the API server binds to all interfaces and lacks authentication by default. The CVE states remote attackers can read and manipulate data and operations, and notes mitigation in version 1.5.5rc1.
A LightRAG code change introduced startup warnings for non-loopback deployments without authentication, improved detection of WHITELIST_PATHS entries that leave Ollama-compatible /api routes exposed, and updated tests and documentation around the insecure default exposure. The change is referenced as the fix for GHSA-mmg5-8x8q-v934 and is described as mitigation rather than enforcing authentication by default.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
2 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
HKUDS disclosed and fixed **CVE-2026-61740**, a critical authentication bypass in LightRAG versions prior to `1.5.4` that could let remote unauthenticated attackers reach endpoints intended to be protected by `LIGHTRAG_API_KEY`. In affected deployments where `LIGHTRAG_API_KEY` was set but `AUTH_ACCOUNTS` was left unset, the application could fall back to a hardcoded `DEFAULT_TOKEN_SECRET`, enabling guest JWT creation through public endpoints and defeating API-key enforcement. The flaw carries a **CVSS 4.0 score of 9.3** and is mapped to **CWE-287** and **CWE-798**.
Jul 15, 2026
A critical vulnerability in **LiteLLM** tracked as `CVE-2026-49468` allows attackers to bypass authentication through **Host header injection** and reach protected management endpoints. The flaw affects LiteLLM versions earlier than **`1.84.0`** and stems from a mismatch in how the authentication layer evaluates routes versus how **FastAPI** ultimately dispatches them, creating a path for unauthenticated access under specific conditions. The issue is classified as **`CWE-290`** and has been rated **CVSS 9.5**, with researchers describing it as network-exploitable with low attack complexity and no user interaction required. The vulnerability was responsibly disclosed by **Le The Thang** of **KCSC** and **Kim Ngoc Chung** of **One Mount Group**, and LiteLLM maintainers have released a fix in version **`1.84.0`** with no configuration changes required. There is no confirmed evidence of active exploitation, and **LiteLLM Cloud** customers are reportedly not affected. Self-hosted deployments may also be shielded if upstream infrastructure such as **Cloudflare**, **WAFs**, reverse proxies with strict allowlists, or host-validating load balancers normalize or reject malformed Host headers before requests reach the application.
Jun 29, 2026
Multiple vulnerabilities in **LightLLM through version 1.2.0** expose reachable AI inference deployments to unauthenticated remote code execution (RCE) and operational disruption. Critical flaws tracked as `CVE-2026-103040`, `CVE-2026-103041`, and `CVE-2026-103395` involve unsafe pickle-backed deserialization in exposed RPyC services, including profiling and `visual_only` image-inference deployments. An attacker able to reach an affected RPyC port can submit crafted Python objects—such as one abusing `__reduce__`—and execute code with the privileges of the LightLLM service account. The profiling path requires `--enable_profiling`; the visual deployment issue affects the `remote_infer_images` method. Additional weaknesses permit unauthenticated denial-of-service and inference disruption. `CVE-2026-103042` can exhaust memory through the NCCL control channel, while `CVE-2026-103270` exposes reinforcement-learning control endpoints when LightLLM runs with `--enable_rl`, allowing remote callers to pause generation, abort requests, flush caches, initialize weight-update groups, and potentially wedge workers. No public exploitation, known victims, or CISA KEV listing had been reported. Organizations should disable profiling, RPyC, and RL features where unnecessary; restrict all related service and dynamically assigned profiler ports to trusted networks; apply vendor fixes when available; review potentially exposed instances; and rotate credentials accessible to inference processes.
Oct 2, 2026