LightLLM EUVD-2026-89989

Exploitation requires that the target LightLLM instance (through 1.2.0) was started with the --enable_rl flag, which is what mounts the reinforcement-learning control routes (/pause_generation, /abort_request, /flush_cache, /init_weights_update_group) on the public HTTP API; without that flag the routes do not exist and the deployment is not exploitable. Given the flag is set, no authentication, credentials, or user interaction are needed and the API must simply be network-reachable by the attacker. The primary limiting factors are this non-default RL configuration and network exposure of the API - deployments that bind the API to localhost or place it behind an authenticating proxy substantially reduce risk. Impact is confined to disruption of inference availability; no data disclosure or modification is possible through these routes.

All signals point to a genuine but availability-only exposure. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) is internally consistent: network-reachable, no authentication (CWE-306, missing authentication), no user interaction, and the only impact is availability (VA:H) - there is no confidentiality or integrity loss because the RL control endpoints disrupt/wedge inference workers rather than leak or alter data. The 8.7 score is high largely because CVSS 4.0 weights an unauthenticated, low-complexity network DoS heavily; the real-world blast radius is a service outage, not compromise. No EPSS score, no CISA KEV listing, and no published proof-of-concept were provided, so exploitation must be described as no public exploit identified at time of analysis - do not conflate the availability of source-line references with a weaponized exploit. One important limiting factor is not reflected in the raw score: the vulnerable /pause_generation, /abort_request, /flush_cache, and /init_weights_update_group routes only exist on deployments started with the non-default --enable_rl flag, so most standard inference deployments are not affected. Net assessment: a legitimate priority for the specific subset of operators running reinforcement-learning-enabled LightLLM instances exposed to untrusted networks, but a lower priority than the 8.7 suggests for the general deployment population, and strictly a disruption (not a breach) risk.

An attacker who can reach the LightLLM HTTP API of a deployment launched with --enable_rl sends a simple unauthenticated request to a control route such as /pause_generation or /abort_request. Repeated or well-timed calls halt inference, flush caches, or wedge worker processes, producing a denial of service against the model-serving endpoint. No public proof-of-concept is referenced, though the advisory cites the exact vulnerable source lines, making a working exploit trivial to reconstruct.