CVE-2026-90938: LangBot through 0.4.17 Unauthenticated Plugin Registration via WebSocket
LangBot's plugin runtime (pip package langbotplugin) through 0.4.17 starts a debug WebSocket server on 0.0.0.0:5401 (/plugin/ws) whose authentication is gated on plugindebugkey, which defaults to an empty string and is never set by the upstream repository, Docker image, or docker-compose (which additionally publishes port 5401 to the host); the key check is therefore skipped entirely. Any remote attacker able to reach the port can register an arbitrary "debug plugin" without credentials. Because events are broadcast to all initialized plugins without filtering, the attacker's plugin receives the full context of every IM message event (including private chats, message chains, and user/sender IDs in plaintext) and can inject forged replies, send messages as any configured bot, enumerate bot UUIDs, invoke configured LLM models, read knowledge-base contents, and register malicious tools that feed every user's LLM pipeline. Registering with "prodmode": true causes later legitimate installations of a plugin with the same author/name to be rejected, resulting in persistent denial of service. No patched version was available at the time of publication.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated plugin registration?
Deployments running langbot_plugin through 0.4.17 are exposed when an attacker can reach the debug WebSocket service at 0.0.0.0:5401/plugin/ws. The upstream repository, Docker image, and docker-compose configuration do not set plugin_debug_key, and docker-compose also publishes port 5401 to the host.
Does exploitation require credentials or user interaction?
No. The authentication check is skipped when plugin_debug_key is empty, allowing any network-reachable attacker to register a debug plugin without credentials or user interaction.
What can an attacker do after registering a plugin?
A malicious plugin can receive the full context of IM message events, including private chats, message chains, and user and sender IDs. It can also forge replies, send messages as configured bots, enumerate bot UUIDs, invoke configured LLM models, read knowledge-base contents, and register tools affecting users' LLM pipelines.
Is there a workaround if no patch is available?
Restrict network access to port 5401 so untrusted remote systems cannot reach the WebSocket service, and set a non-empty plugin_debug_key. No patched version was available at publication.
Can exploitation persist after the attacker's connection ends?
Yes. An attacker can register a plugin with prod_mode set to true; later legitimate installations using the same author and name are rejected, causing persistent denial of service.