CVE-2026-111704 is a missing authentication flaw (CWE-306) in LangChat through commit 2a6285a, scored 9.8 critical. No Sa-Token interceptor is registered, so REST controllers answer anyone. The record says this exposes plaintext passwords and LLM provider API keys. Lock down access and rotate every secret.
What's affected
LangChat through commit 2a6285a, per the CVE record. LangChat is tracked by commit and not by a release number in the record, so identify your build by its commit.
The record says no Sa-Token interceptor is registered in the server configuration. That leaves the REST controllers open, including the user listing at /api/v1/auth/users. I could not confirm a fixed commit, so check the project history for one.
How to check if you're exposed
Find the commit your deployment was built from, through your image tags, build logs or the repository checkout. If it is the listed commit or older, treat it as affected.
Then check the exposure. See whether the server's port is reachable from outside the trusted network, and whether a proxy or gateway in front of it enforces any login. Review the user table for accounts you did not create, in particular super administrators, and review the stored LLM provider keys.
In access logs, look for requests to the user listing path and the admin creation routes from unfamiliar addresses.
You can also run the free in-browser dependency scan or browse the Gold directory to see where a package or product shows up in your stack.
What to do now
- Put the application behind a VPN or an authenticating proxy, so that no route answers without a login.
- Rotate every LLM provider API key stored in the application, and check your provider dashboards for unexpected usage.
- Reset passwords for all users, and move to hashed password storage if the application stores plain text.
- Review the user list for new super administrator accounts and audit data changes or deletions.
- Check the project for a fixed commit that registers the interceptor globally, and update when it is available.
Why it matters
Authentication in many Java frameworks depends on an interceptor or filter that guards every route. If it is never registered, nothing is guarded. The class is CWE-306, missing authentication for a critical function. The record lists the effects: reading plaintext passwords, retrieving LLM provider API keys, creating super administrators, and modifying or deleting data.
Two parts make it worse. Passwords stored in plain text are exposed in full, and LLM keys can run up bills or expose data on your provider accounts. Secrets stored by the app are as exposed as the app itself.
A global deny by default rule, with explicit exceptions for public routes, is the safer design. The record does not flag this CVE as exploited in the wild and it is not a CISA Known Exploited Vulnerability.
Quick check
Which secrets should I rotate?
The LLM provider API keys stored in the app, all user passwords, and any other credentials the application can read.
Is a fix available?
I could not confirm one. Check the project history for a commit after 2a6285a that registers the interceptor.
Sources
Last reviewed: 19 October 2026.
