LangChat CVE-2026-111704

No special conditions beyond network reachability - the flaw stems from a missing global Sa-Token interceptor, so all REST controllers of a default LangChat deployment (through commit 2a6285a) are exposed to unauthenticated remote attackers with no user interaction. Exploitation requires only HTTP/HTTPS access to the langchat-server API (e.g. the /api/v1/auth/users endpoint); the only real limiting factor is network exposure of the instance (internet-facing versus internal/firewalled) and running a version at or before the vulnerable commit. No authentication, specific feature toggle, or non-default configuration is needed.

All available signals point to genuine high priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity flaw requiring no authentication or user interaction, and the description confirms this: because no Sa-Token interceptor is registered, REST controllers are globally exposed. The high-high-high impact rating (VC:H/VI:H/VA:H) is substantiated by concrete described consequences - reading plaintext passwords and LLM provider API keys (confidentiality), creating super-admin accounts (integrity), and modifying or deleting data (availability/integrity). No EPSS score, CISA KEV entry, or dedicated POC flag was supplied in the input, so exploitation-probability and active-exploitation signals are UNKNOWN rather than low; absence of these is not evidence of low risk. SSVC-style reasoning: exploitation is effectively automatable (a single unauthenticated GET to /api/v1/auth/users) and technical impact is total, which would drive an 'Act'/'Attend' decision despite the lack of EPSS/KEV data. The main mitigating factor is deployment footprint rather than exploitability - LangChat is a niche open-source product, so this is likely targeted/opportunistic against exposed instances rather than mass-exploited. The CVSS network vector is consistent with the description (no conflict to flag).

An attacker who can reach a LangChat instance's HTTP API sends an unauthenticated request to /api/v1/auth/users and immediately receives user records including plaintext passwords and stored LLM provider API keys. Using the same unprotected controllers, they create a super-admin account and then modify or delete application data at will. A detailed technical write-up on HackMD and a VulnCheck advisory document the exact vulnerable code paths, making reliable exploitation straightforward even though no packaged exploit tool is flagged in the input.