Description

Chainlit is a Python framework for building production-ready conversational AI applications. From 2.4.0rc0 until 2.12.0, Chainlit deployments with features.mcp.enabled set to true in .chainlit/config.toml expose the POST /mcp endpoint without requiring authentication. For sse and streamable-http transports, ConnectSseMCPRequest and ConnectStreamableHttpMCPRequest in backend/chainlit/types.py accept a user-controlled url and optional headers dictionary without scheme validation, private-address filtering, or an allowlist. The connect_mcp handler in backend/chainlit/server.py passes these values to sse_client() or streamablehttp_client(), allowing the Chainlit server to make blind outbound requests to arbitrary internal or external services, including cloud metadata endpoints, with attacker-controlled Authorization and Cookie headers. The SSE URL sink has existed since 2.4.0rc0, while attacker-controlled header forwarding and streamable-http support were added in 2.6.4. The response is consumed internally and not returned, but the attacker can issue state-changing authenticated requests, discover internal services, scan ports, and probe metadata endpoints. This issue is fixed in version 2.12.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-08-25T20:16:55.910Z",
  "pubdate": "2026-08-25T20:16:55.910Z",
  "executiveSummary": "Chainlit, a framework for conversational AI applications, is vulnerable to an unauthenticated Server-Side Request Forgery (SSRF) flaw when the MCP (Model Context Protocol) feature is enabled.\nThis vulnerability originates from improper validation of user-controlled inputs within the POST /mcp endpoint, specifically affecting the 'sse' and 'streamable-http' transport mechanisms.\nBy bypassing authentication requirements—which are absent when features.mcp.enabled is set to true—an unauthenticated remote attacker can force the Chainlit server to initiate arbitrary outbound HTTP requests.\nThe vulnerability allows for the crafting of requests containing attacker-controlled headers, including sensitive 'Authorization' and 'Cookie' fields. This capability enables the exploitation of internal services, local port scanning, and the exfiltration of sensitive information from cloud metadata endpoints.\nThe impact is significant, as the server acts as an internal proxy, potentially bypassing network firewalls and security perimeters to access sensitive infrastructure that is otherwise unreachable from the public internet.\nThe issue affects versions ranging from 2.4.0rc0 through 2.11.x, with a comprehensive fix implemented in version 2.12.0.",
  "technicalDetails": "The vulnerability resides within the backend processing of MCP requests in 'backend/chainlit/server.py', specifically within the 'connect_mcp' handler. The root cause is a lack of input validation, scheme filtering, and network-level allowlisting when processing user-provided URLs and headers.\nWhen 'features.mcp.enabled' is configured as true in '.chainlit/config.toml', the POST /mcp endpoint fails to enforce authentication. The data structures 'ConnectSseMCPRequest' and 'ConnectStreamableHttpMCPRequest', defined in 'backend/chainlit/types.py', accept an arbitrary URL and an optional headers dictionary from the client. These parameters are passed directly to the 'sse_client()' or 'streamablehttp_client()' functions without verification.\nThe attack flow proceeds as follows: An attacker sends a crafted POST request to the /mcp endpoint. Within the request body, the attacker specifies a target URL pointing to an internal service, such as a cloud provider's metadata service (e.g., 169.254.169.254) or an internal database management interface. The attacker also injects arbitrary HTTP headers, such as 'Authorization: Bearer <token>' or 'Cookie: session=<value>', which the Chainlit server then includes in the request to the target resource.\nBecause the server-side client performs the network request, it originates from the context of the Chainlit application server. Consequently, if the server possesses elevated IAM roles or is positioned within a trusted VPC, the attacker can leverage the server's identity to interact with cloud metadata services or perform lateral movement within the internal network. The 'streamable-http' support and header forwarding capabilities, introduced in version 2.6.4, significantly expanded the attack surface, allowing for complex state-changing requests against internal systems.\nWhile the response from the targeted resource is consumed internally rather than returned directly to the attacker, the primary impact is successful exploitation of internal state-changing interfaces. This allows for persistent configuration changes, data exfiltration via side-channels (like blind timing or differential response analysis), and unauthorized access to protected internal APIs. The lack of private-address filtering ensures that internal-only IP spaces are fully reachable via this proxy mechanism."
}