LangChat: the REST API answers callers who never logged in

01What happened

VulnCheck assigned CVE-2026-111704 to LangChat on October 16, 2026 and rates it 9.3 under CVSS 4.0, crediting the finder hieuPenguinnn. The finder's write-up reports the flaw from reading the default branch at commit 2a6285a and states that no instance was started and no requests were sent. The GitHub Advisory Database listed the report the same day, unreviewed.

02How it works

LangChat is a Spring Boot application that uses Sa-Token to issue and parse session tokens, but Sa-Token only enforces a login where something registers it. The project registers no SaInterceptor, no SaServletFilter and no HandlerInterceptor, so the only routes that require a session are the two handlers that carry the @SaCheckLogin annotation. Every other controller, including the one that lists user accounts and the one that returns configured model providers, resolves no identity before it answers.

03Who is affected

Self-hosted LangChat is exposed in all code up to commit 2a6285a, which is the current state of the default branch; the project publishes no release tags, so there is no version number to compare against. Operators are affected wherever the service port is reachable, because no account is needed. The routes listed below return the passwords and the provider API keys and base URLs that the deployment stores.

04What to do

Block outside access to LangChat and put an authenticating proxy in front of it until the project ships a fix, because no patched version is named. Operators who patch locally can follow the write-up: register a global SaInterceptor that requires a login on all routes with narrow exceptions for login and logout, add per-permission checks on the administrative controllers, and stop serializing the password and apiKey fields. Treat every provider key the deployment held as exposed and rotate it.

Questions people ask

Which LangChat versions are affected by CVE-2026-111704?

LangChat publishes no release tags, so VulnCheck names the affected range as everything up to commit 2a6285a6b8c51d51cdc599771bb667a30bc03f5c on the default branch. That commit was current when the finder reviewed the code, which means an operator who pulled the default branch at any point has the flawed configuration. There is no version number to compare a deployment against.

Is there a patch for the LangChat missing authentication flaw?

No patched LangChat release is listed by VulnCheck, the CVE record or the GitHub Advisory Database, and the finder reports that no public advisory or matching issue existed when the write-up was published. Mitigation is configuration work: keep the service off untrusted networks, front it with an authenticating proxy, or register a global Sa-Token interceptor locally.

What can an unauthenticated caller read from LangChat?

The write-up lists the user account routes under /api/v1/auth/users, which return stored passwords; /api/v1/aigc/models, which returns provider API keys and base URLs; and the datasource routes, including a connection test and a schema introspection endpoint. Conversation, agent, knowledge, role and menu routes are also reachable. A caller can create a super-admin account and delete records.

Was the LangChat flaw demonstrated against a running server?

No. hieuPenguinnn states the finding comes from source review, that runtime behaviour was not observed, and that no instance was started and no requests were sent. VulnCheck's advisory and the CVE record describe the impact without adding runtime evidence. The missing interceptor registration is visible in the code, so the gap is verifiable by reading, not by exploitation.

Sources 6 links, all fetched

1. 1vulncheck.comVulnCheck Advisory
2. 2hackmd.ioResearcher Write-Up
3. 3cveawg.mitre.orgCVE Record
4. 4github.comGitHub Advisory
5. 5github.comMVC Config Source
6. 6github.comUser Controller Source