Locust CVE-2026-111883

Exploitation requires that (1) the Locust web UI (locust/web.py) is running and network-reachable from the victim's browser, and (2) a human operator with access to that UI is socially engineered into visiting an attacker-controlled web page while the UI is reachable. The vulnerable actions are the /stop and /stats/reset endpoints, which in versions through 2.46.7 accept state-changing GET requests without any anti-CSRF token, so no attacker authentication is needed. Limiting factors that reduce realistic risk: mandatory operator interaction (UI:P - the attack fails if no operator is lured), the fact that the Locust web UI is commonly bound to localhost/internal interfaces and only active during test runs, and that impact is confined to stopping tests and resetting statistics (no data disclosure or code execution).

This is a genuine but low-to-moderate priority issue, best characterized as a defense-in-depth/integrity-hygiene flaw rather than an urgent threat. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) correctly reflects a network-reachable, low-complexity CSRF where the attacker needs no credentials but DOES need a privileged victim (UI:P) - an operator with browser access to the Locust web UI must be lured to a malicious page. Impact is bounded: VC:N (no confidentiality loss), with only VI:L/VA:L (an attacker can stop a running test or wipe recorded statistics, but cannot read data, execute code, or achieve persistent compromise). Exploitation status is 'no public exploit identified at time of analysis' - there is no KEV listing, no EPSS value supplied, and no POC flag in the input, so there is no evidence of active or automated exploitation; the VulnCheck advisory is a disclosure, not an exploitation report. The signals are internally consistent (network vector matches an HTTP-based CSRF; UI:P matches the 'lure an operator' description), so there is no major conflict to flag. The main caveat is that EPSS and POC status are simply absent from the input rather than confirmed-negative. Real-world risk is further limited because the Locust web UI is typically bound to internal/localhost interfaces during test runs, so the attacker's forged request only succeeds if the operator's browser can reach the UI at the moment they visit the malicious page.

While a performance engineer is running a load test with the Locust web UI open in their browser, an attacker lures them (e.g., via a phishing link or a malicious ad) to a web page that contains a hidden image or auto-submitting element pointing at the Locust host's /stop or /stats/reset endpoint. Because these actions are triggerable via simple cross-site GET requests with no CSRF token, the victim's browser silently issues the request, terminating the running swarm and discarding collected performance metrics. No public exploit code is identified at time of analysis, though a working CSRF payload is trivial to construct from the public description.