CVE-2026-85695: FastChat Authentication Bypass Vulnerability

CVE-2026-85695 Overview

FastChat contains an authentication bypass vulnerability in the /register_worker endpoint of its controller service. Unauthenticated attackers can register arbitrary worker addresses against the controller, enabling server-side request forgery (SSRF) and model spoofing attacks. Malicious workers registered under legitimate model names intercept user prompts, uploaded images, and model responses. Attackers can also use the controller as a proxy to probe internal network ports across the worker mesh. The flaw is tracked as a missing authentication weakness [CWE-306] and affects FastChat deployments that expose the controller service on trusted or untrusted networks.

Critical Impact
Unauthenticated attackers can hijack LLM traffic, steal prompts and responses, and pivot into internal networks through the FastChat controller.

Affected Products

FastChat (lm-sys/FastChat) controller service
FastChat version v0.2.36 and prior releases exposing /register_worker
Any deployment using fastchat/serve/controller.py without a network authentication layer

Discovery Timeline

2026-09-04 - CVE-2026-85695 published to the National Vulnerability Database (NVD)
2026-09-10 - Last updated in NVD database

Technical Details for CVE-2026-85695

Vulnerability Analysis

FastChat is an open-source platform for training, serving, and evaluating large language model (LLM) chatbots. Its architecture separates a central controller from one or more worker processes that host models. Workers announce themselves to the controller through the HTTP endpoint /register_worker, which the controller then treats as an authoritative source for routing user traffic.

The controller does not authenticate or validate the identity of the caller invoking /register_worker. Any network-reachable client can submit a registration payload containing an attacker-chosen worker_name, model list, and callback URL. The controller adds the entry to its routing table and begins forwarding requests to the supplied address.

Because the controller also issues outbound heartbeat and status calls to registered worker URLs, the vulnerability doubles as a server-side request forgery primitive. An attacker can enumerate internal services and ports by registering worker URLs that point at private network resources and observing controller behavior.

Root Cause

The root cause is missing authentication on a security-relevant function [CWE-306]. The register_worker handler in fastchat/serve/controller.py accepts registration input without verifying caller identity, tokens, mutual TLS, or network origin. The design assumed the controller and workers would run on a trusted network segment.

Attack Vector

Exploitation requires only network access to the controller port. An attacker sends a single HTTP POST to /register_worker claiming ownership of a legitimate model name such as vicuna-13b. Subsequent user requests for that model may be routed to the attacker-controlled worker, exposing prompt content, image uploads, and generated responses. Alternatively, the attacker points the worker URL at an internal host and port, using the controller's outbound requests to map internal infrastructure. Refer to the VulnCheck Advisory for FastChat and GitHub FastChat Issue #3886 for additional technical context.

Detection Methods for CVE-2026-85695

Indicators of Compromise

Unexpected POST requests to /register_worker from addresses outside the trusted worker subnet
Registered workers with hostnames or IP addresses that do not match approved infrastructure inventory
Duplicate model names served by multiple worker addresses, especially where one address is unknown
Controller outbound HTTP requests to internal IP ranges, loopback, or link-local addresses (127.0.0.0/8, 169.254.0.0/16, RFC1918)

Detection Strategies

Enable HTTP access logging on the controller and alert on any /register_worker call not originating from an allow-listed worker host
Periodically enumerate /list_models and /list_workers and diff against a known-good baseline of workers and model mappings
Correlate controller egress traffic with expected worker destinations; flag connections to internal services never previously contacted

Monitoring Recommendations

Capture and retain full request bodies for /register_worker to support forensic reconstruction of hijack attempts
Monitor for anomalous spikes in model registrations or rapid re-registration of the same model name
Instrument worker traffic to detect prompts or responses being served by unauthorized endpoints

How to Mitigate CVE-2026-85695

Immediate Actions Required

Restrict controller network exposure so only authorized worker hosts can reach the /register_worker endpoint
Place the FastChat controller behind an authenticating reverse proxy that enforces mutual TLS or a shared secret header
Audit the current worker list and remove any registrations that do not match approved infrastructure
Rotate any credentials, API keys, or sensitive data that may have transited a compromised worker

Patch Information

At the time of publication, no vendor-supplied patch is referenced in the NVD entry. Track the upstream GitHub FastChat Repository and GitHub FastChat Issue #3886 for remediation status. Review the current controller source at GitHub FastChat Controller Source before deploying custom fixes.

Workarounds

Bind the controller to a loopback interface and expose only user-facing endpoints through an authenticated gateway
Enforce firewall rules or Kubernetes NetworkPolicies that limit inbound access to /register_worker to specific worker pod identities
Add an authentication middleware in front of the controller that validates a bearer token or client certificate on every registration request
Egress-filter controller traffic so it cannot reach internal management interfaces, cloud metadata services, or sensitive subnets

bash

# Example nginx reverse proxy enforcing a shared registration secret
location /register_worker {
    if ($http_x_fastchat_token != "REPLACE_WITH_STRONG_SECRET") {
        return 401;
    }
    allow 10.0.0.0/24;   # worker subnet
    deny all;
    proxy_pass http://127.0.0.1:21001;
}