CVE-2026-111704: LangChat Missing Authentication Flaw (CVSS 9.8) — Detection and Remediation Guide

The NVD has published CVE-2026-111704, a CVSS 9.8 (CRITICAL) missing-authentication vulnerability in LangChat, an open-source Java-based LLM application framework widely used to build Retrieval-Augmented Generation (RAG) and AI-agent backends. The flaw affects all builds through commit 2a6285a and is trivially exploitable over the network with zero authentication.

The root cause is blunt and dangerous: LangChat fails to register a Sa-Token interceptor for its REST controllers. Sa-Token is the authentication/authorization framework LangChat depends on — but if the interceptor is never wired into the request pipeline, every annotated endpoint is reachable by anonymous callers. In practice this means an unauthenticated remote attacker can:

• Query GET /api/v1/auth/users and receive plaintext passwords of application users
• Retrieve LLM provider API keys (OpenAI, Azure OpenAI, Anthropic, and other configured providers)
• Create super-admin accounts for persistent access
• Read, modify, or delete application data, knowledge bases, and agent configurations

This is not a theoretical exposure. The pattern — missing auth middleware on an AI framework's admin API — is exactly the class of bug that internet-wide scanners weaponize within hours of disclosure. Any LangChat instance exposed to the internet, or reachable from a compromised internal host, should be treated as actively at risk. Patch, rotate credentials, and hunt for post-exploitation activity now.

Technical Analysis

Affected Products and Versions

How the Vulnerability Works

LangChat uses Sa-Token for session and permission management. In a correctly configured deployment, a Sa-Token interceptor is registered against controller route patterns so that every request is checked for a valid token before reaching handler logic. In vulnerable builds, the interceptor registration is absent for the application's REST controllers — effectively disabling authentication across the API surface.

From a defender's perspective, the attack chain is a single HTTP request:

1. Reconnaissance: Attacker identifies an exposed LangChat instance (fingerprintable via response headers, default ports, or framework-specific paths).
2. Direct API access: Attacker issues GET /api/v1/auth/users with no credentials. The request bypasses all auth checks and reaches the user controller.
3. Credential theft: The endpoint returns user records including plaintext passwords — a secondary design failure (passwords should never be stored or returned in cleartext) that dramatically amplifies impact.
4. Key extraction: Attacker queries configuration endpoints to harvest LLM provider API keys, enabling financial abuse of paid LLM quotas and potential pivoting into provider accounts.
5. Persistence: Attacker calls the user-management endpoint to create a super-admin account, converting an unauthenticated bug into durable, authenticated access that survives a partial fix.
6. Data manipulation: Knowledge bases, prompts, agent configurations, and stored data can be modified or deleted — a direct integrity threat to any AI workflow built on the instance.

Why This Is Especially Dangerous in AI Infrastructure

LangChat deployments typically sit at a trust boundary: they hold provider API keys, connect to internal data sources for RAG, and often run with broad network reach. Compromise of the LangChat layer means compromise of everything the LLM application can see — vector stores, document repositories, downstream APIs, and the LLM provider account itself (with its billing and data access). Treat a LangChat breach as a breach of every system it integrates with.

Exploitation Status

As of publication, CVE-2026-111704 is newly published in the NVD. Given the trivial, single-request exploitation path, the high-value credential material exposed, and historical precedent for internet-wide scanning of unauthenticated admin APIs, defenders should assume rapid weaponization and opportunistic exploitation rather than waiting for confirmation. Check the NVD entry and CISA KEV catalog for updates on confirmed in-the-wild activity.

Detection & Response

The highest-fidelity detection point is the web access log of the LangChat frontend (reverse proxy, ingress controller, or the embedded web server). Unauthenticated hits to sensitive API routes — especially the user-listing endpoint — are direct evidence of exploitation or reconnaissance. Endpoint rules target post-exploitation behavior: the Java process performing suspicious actions after API abuse.

Sigma Rules

---
title: LangChat Unauthenticated Access to Sensitive API Endpoints
id: 3f8c1a92-7d4e-4b6a-9c15-2e8f0a5b7d31
status: experimental
description: Detects HTTP requests to LangChat REST endpoints known to be exposed without authentication in CVE-2026-111704, including the user-listing endpoint that returns plaintext passwords and user-management endpoints used to create super-admin accounts.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-111704
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
  product: linux
detection:
  selection:
    cs-uri-stem|contains:
      - '/api/v1/auth/users'
      - '/api/v1/auth/user'
  filter_options:
    cs-method:
      - 'OPTIONS'
  condition: selection and not filter_options
falsepositives:
  - Legitimate authenticated admin API calls (correlate with session/token headers and source IP allowlists)
level: high
---
title: LangChat Java Process Spawning Shell or Command Interpreter
id: 9b2e5d41-6c3f-4a8b-b7d2-1f4e9c0a3d52
status: experimental
description: Detects the LangChat Java process spawning a shell or command interpreter, a strong post-exploitation indicator after unauthenticated API abuse of CVE-2026-111704 (e.g., attacker leveraging the application for command execution or persistence).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-111704
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/java'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Rare; some health-check or deployment scripts may exec from Java. Baseline per host.
level: high
---
title: Outbound Connection to LLM Provider API from Unusual Process
id: 5d1a7f03-2e9b-4c4d-8a61-3c7b2e5f9a04
status: experimental
description: Detects processes other than the expected LangChat Java runtime connecting to LLM provider API endpoints (OpenAI, Anthropic, Azure OpenAI), indicating possible theft and reuse of provider API keys harvested via CVE-2026-111704.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-111704
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.exfiltration
  - attack.t1567
logsource:
  category: network_connection
  product: linux
detection:
  selection_domain:
    DestinationHostname|contains:
      - 'api.openai.com'
      - 'api.anthropic.com'
      - '.openai.azure.com'
      - 'generativelanguage.googleapis.com'
  filter_expected:
    Image|endswith:
      - '/java'
      - '/node'
      - '/python'
      - '/python3'
  condition: selection_domain and not filter_expected
falsepositives:
  - Developers testing provider keys manually; corporate AI tooling. Tune per environment.
level: medium

KQL — Microsoft Sentinel / Defender

This query hunts for requests to LangChat's exposed authentication and user-management endpoints via web/proxy logs ingested into Sentinel (CEF/Syslog from your reverse proxy, WAF, or ingress controller), and flags client IPs hitting the sensitive user-listing endpoint without an associated successful authentication event nearby.

let Lookback = 14d;
let SensitivePaths = dynamic(["/api/v1/auth/users", "/api/v1/auth/user"]);
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where RequestURL has_any (SensitivePaths)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
    RequestCount = count(), Methods = make_set(RequestMethod),
    ResponseCodes = make_set(ApplicationProtocol),
    Destinations = make_set(DestinationHostName), URLs = make_set(RequestURL)
    by SourceIP
| where RequestCount > 0
| join kind=leftouter (
    CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where RequestURL has "login"
    | summarize AuthEvents = count() by SourceIP
) on SourceIP
| extend UnauthenticatedSuspect = iif(isnull(AuthEvents) or AuthEvents == 0, true, false)
| where UnauthenticatedSuspect == true
| project SourceIP, FirstSeen, LastSeen, RequestCount, Methods, Destinations, URLs
| order by RequestCount desc;

If you ingest raw web server logs via the Syslog table instead, swap CommonSecurityLog for Syslog and match on SyslogMessage with the same path strings.

Velociraptor VQL

Use this artifact on LangChat hosts to surface post-exploitation conditions: the Java process spawning shells or download tools, and active outbound connections to LLM provider APIs from unexpected binaries.

-- CVE-2026-111704 post-exploitation hunt: suspicious children of java and outbound LLM API connections
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(curl|wget|bash|sh |nc |ncat|python|chmod|chown)'
   AND Name =~ 'sh|bash|dash|curl|wget|nc|ncat|python'
UNION ALL
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'api\.openai\.com|api\.anthropic\.com|openai\.azure\.com'
   AND NOT Name =~ 'java|node'

For network-state validation on the host, pair with netstat() filtered to remote TCP/443 sessions whose owning process is not the expected Java runtime.

Remediation and Hardening Script

The following Bash script helps operators (1) confirm exposure by safely probing the vulnerable endpoint against a non-production or authorized target, (2) pull the latest upstream code past commit 2a6285a, and (3) apply a compensating reverse-proxy block while awaiting an upstream fix.

#!/usr/bin/env bash
# CVE-2026-111704 - LangChat missing authentication triage & mitigation
# Run on an authorized system only.
set -euo pipefail

TARGET="${1:-http://localhost:8080}"

echo "[*] Step 1: Test whether /api/v1/auth/users is reachable WITHOUT credentials"
HTTP_CODE=$(curl -sk -o /tmp/langchat_probe.json -w "%{http_code}" "${TARGET}/api/v1/auth/users" || echo "000")
echo "    HTTP status: ${HTTP_CODE}"
if [[ "${HTTP_CODE}" == "200" ]]; then
  echo "[!!!] VULNERABLE/EXPOSED: endpoint returned data with no auth token."
  echo "      Response sample (first 500 bytes):"
  head -c 500 /tmp/langchat_probe.json; echo
else
  echo "[OK] Endpoint did not return 200 unauthenticated (status ${HTTP_CODE}). Verify against your auth policy."
fi

echo "[*] Step 2: Confirm deployed commit — pull latest upstream beyond 2a6285a"
echo "    cd to your LangChat checkout and run:"
echo "      git fetch origin && git log --oneline -5"
echo "    If HEAD is at or before 2a6285a, rebuild from the latest fixed branch."

echo "[*] Step 3: Emergency compensating control — block sensitive routes at the reverse proxy"
cat <<'NGINX'
# nginx snippet: deny unauthenticated access pending upstream fix
location ~ ^/api/v1/auth/users {
    return 403;
}
NGINX

echo "[*] Step 4: Credential hygiene (MANDATORY if the instance was internet-reachable)"
echo "    - Rotate ALL LangChat user passwords (plaintext exposure = full compromise)."
echo "    - Revoke and reissue ALL LLM provider API keys (OpenAI, Azure, Anthropic, etc.)."
echo "    - Audit the user table for unauthorized super-admin accounts:"
echo "        SELECT username, role, create_time FROM sys_user ORDER BY create_time DESC;"
echo "    - Review access logs for requests to /api/v1/auth/* and user-creation calls."

Remediation

1. Update LangChat immediately. Pull the latest upstream source beyond commit 2a6285a and rebuild/redeploy. Confirm the Sa-Token interceptor is registered for all REST controller route patterns before returning the service to production — verify with an unauthenticated request to /api/v1/auth/users expecting a 401/403, not 200.
2. Rotate every credential the instance held. Because the endpoint returned plaintext passwords, assume all user credentials are burned. Force password resets across the application and — critically — revoke and reissue all LLM provider API keys stored in LangChat configuration. Monitor provider billing dashboards for anomalous usage.
3. Audit for persistence. Query the user store for accounts created since the disclosure window, especially super-admins you did not provision. Review web access logs for hits to /api/v1/auth/users, user-creation POSTs, and data-modification calls from unfamiliar source IPs.
4. Apply network-layer controls while patching. If a rebuilt build cannot ship immediately, block the sensitive routes at your reverse proxy/WAF (see script above) and restrict network reachability of the LangChat admin API to a management allowlist. Unauthenticated admin APIs must never be internet-reachable.
5. Fix the defense-in-depth gaps. Plaintext password storage is an independent, serious design failure — ensure the upstream project (or your fork) hashes passwords with a modern algorithm (bcrypt/Argon2) and never serializes credentials into API responses. Add explicit authorization tests to CI so interceptor regressions fail the build.
6. Monitor vendor and authoritative advisories. Track the NVD entry for CVE-2026-111704 and the LangChat repository for the official fix commit and any updated guidance; check CISA KEV for exploitation confirmation, which would escalate remediation urgency.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub