A newly published CVE details an authentication bypass in FastChat's /register_worker endpoint. According to the NVD entry for CVE-2026-85695, any unauthenticated attacker can register a malicious worker under a legitimate model name, then intercept user prompts, images, and responses, or use the worker mesh to probe internal network ports. If you're running FastChat in any environment that handles real user traffic, this is a direct pipeline to sensitive data exfiltration.

The core failure here is straightforward: an administrative endpoint that mutates system state has no authentication requirement. This isn't a subtle logic flaw. It's a missing control. In my experience, worker registration or node enrollment endpoints get built fast during a project's early days and the auth layer gets added "later." Later never comes, the project ships, and you end up with exactly this.

From an IAM architecture standpoint, every endpoint that registers a new identity, whether that's a human user, a service account, or a compute worker, needs to be treated as a privileged operation. The same rigor you'd apply to a PAM-controlled admin session or a service account provisioning workflow applies here. If a caller can name itself anything and join your processing mesh without proving who it is, you don't have a worker mesh. You have an open relay. The SSRF angle makes it worse: the registered worker can be used to reach internal services that assume mesh-internal traffic is trusted. That's a classic lateral movement path.

What I'd audit right now: any internally deployed orchestration or inference framework that exposes a worker or node registration API. Check whether those endpoints require a shared secret, a mutual TLS certificate, or any form of token validation before accepting a registration request. If the answer is "the endpoint is only reachable internally," that's not a control, that's a hope. Network position is not authentication.

If you're running FastChat, isolate the controller endpoint behind a network policy or reverse proxy that enforces authentication immediately, and treat any existing worker registrations as potentially untrusted until you've audited them. If a patch isn't available yet, the short-term mitigation is to block unauthenticated access to /register_worker at the perimeter and audit your worker list for unexpected entries. Don't wait on this one.