Chainlit’s MCP Endpoint Turned a Browser Request Into Server-Side Code Execution
Chainlit has released version 2.12.0 to fix two vulnerabilities in its Model Context Protocol integration. When MCP was enabled, an unauthenticated request to the framework’s /mcp endpoint could reach either a local process launcher or services that should have remained inside the server’s trusted network.
The most serious flaw, CVE-2026-45018, carries a CVSS score of 9.8. It allowed remote command injection through the MCP stdio transport. Its companion, CVE-2026-45019, is a high-severity server-side request forgery issue that let an attacker direct the Chainlit host toward internal or external HTTP services.
This is not evidence that every Chainlit deployment was exposed. MCP has been disabled by default since version 2.7.0. The vulnerable path required features.mcp.enabled = true. Where that switch was enabled, however, the security boundary depended on controls that the unauthenticated caller could influence.
One endpoint exposed two different trust failures
Chainlit is a Python and TypeScript framework for conversational AI applications. Its MCP feature can connect an application to local tools through stdio or to remote services through SSE and streamable HTTP.
Those transports created different consequences:
- CVE-2026-45018, critical command injection: affected versions accepted a client-supplied
fullCommandvalue for an stdio MCP connection. An unauthenticated attacker could use the server to launch an arbitrary command with the privileges of the Chainlit process. - CVE-2026-45019, high-severity SSRF: the SSE and streamable-HTTP paths accepted a caller-controlled destination URL and headers. The server could therefore be made to send requests to internal services, cloud metadata endpoints or external systems, including requests carrying attacker-selected authentication or cookie headers.
The SSRF was blind, meaning the response body was not returned to the attacker. That does not make it harmless. A blind request can still scan ports, probe metadata services and trigger state-changing operations. If an internal API accepts a POST request carrying a valid-looking header, reading the response may not be necessary for the action to take effect.
Every CVE in the bulletin
| Vulnerability | Impact and prerequisites | Affected and fixed versions | Exploit status |
|---|---|---|---|
| CVE-2026-45018 | Unauthenticated command injection and remote code execution through MCP stdio. MCP must be enabled. | Chainlit 2.4.0rc0 through 2.11.x. Fixed in 2.12.0. | CISA’s enrichment records public proof-of-concept status. No confirmed malicious exploitation is reported in the reviewed sources. |
| CVE-2026-45019 | Unauthenticated blind SSRF with attacker-controlled URL and headers through SSE or streamable HTTP. MCP must be enabled. | Chainlit 2.4.0rc0 through 2.11.x. Fixed in 2.12.0. | Technical reproduction details are public. No confirmed malicious exploitation is reported in the reviewed sources. |
The fix removes client authority
Version 2.12.0 does more than add a filter. Chainlit removed the client-supplied command from the stdio connection request. Administrators must now declare stdio servers in server-side configuration, and clients connect to those entries by name.
User-provided HTTP MCP connections are also denied by default. Enabling them requires an explicit setting and a non-empty URL allowlist. The release validates the scheme, host, port and path prefix, rejects several path-normalisation tricks, and strips headers that should not cross the boundary.
The change is intentionally breaking. Legacy MCP configuration sections can prevent the application from starting after the upgrade until administrators migrate them. That failure mode is preferable to silently retaining an unsafe interpretation, but it means teams should test the upgrade rather than treating it as a routine dependency bump.
What defenders should do
- Upgrade Chainlit to 2.12.0 or later and migrate the MCP configuration.
- If immediate upgrading is not possible, set
features.mcp.enabled = false. This blocks both vulnerabilities. - Review whether the application exposed
/mcpto untrusted networks while MCP was enabled. - Restrict outbound access from the Chainlit host, especially to cloud metadata services and internal management networks.
- Run the Chainlit process with minimal operating-system privileges and isolate any local tool execution.
- Review proxy, application and process telemetry for unexpected POST requests to
/mcp, unusual child processes and connections from the Chainlit host to internal services.
The wider lesson is about agent infrastructure rather than one framework. MCP connects natural-language applications to tools that can start processes, read data and reach other services. Once a web request can shape that connection, a missing authentication or allowlist check becomes a direct route across the server’s trust boundary.
Sources and further reading
- Chainlit 2.12.0 security release, published 25 August 2026. The source provides no publication time.
- Chainlit advisory for command injection, published 25 August 2026. The source provides no publication time.
- Chainlit advisory for SSRF, published 25 August 2026. The source provides no publication time.
