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 stdio transport, the endpoint accepts a user-controlled fullCommand string. The validate_mcp_command() function in backend/chainlit/mcp.py checks only the executable name against config.features.mcp.stdio.allowed_executables and passes unchecked arguments to StdioServerParameters in backend/chainlit/server.py. Because npx supports the -c argument, an attacker can execute arbitrary shell commands with the privileges of the Chainlit process. If allowed_executables is unset, its None default is treated as allowing every executable. This issue is fixed in version 2.12.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-25T20:16:55.720Z",
  "pubdate": "2026-08-25T20:16:55.720Z",
  "executiveSummary": "Chainlit versions 2.4.0rc0 through 2.11.x contain a critical vulnerability in the handling of MCP (Model Context Protocol) configurations.\nThe vulnerability is classified as an Unauthenticated Remote Code Execution (RCE) flaw arising from improper validation of user-supplied commands passed to the stdio transport layer.\nWhen features.mcp.enabled is set to true, the POST /mcp endpoint is exposed without authentication, allowing remote attackers to interact with the backend service.\nThe core issue stems from the fact that while the system validates the executable name against an allowlist, it fails to sanitize additional command-line arguments passed to the underlying process.\nAn attacker can exploit this by utilizing the -c argument within npx to execute arbitrary shell commands under the context of the Chainlit application process.\nIf the configuration for allowed_executables is left at its default null state, the application permits the execution of any binary on the host system, significantly expanding the attack surface.\nThe risk to the organization is high, as successful exploitation results in full server compromise, potential data exfiltration, and lateral movement within the hosting environment.",
  "technicalDetails": "The vulnerability resides within the interaction between the POST /mcp endpoint and the internal MCP command processing logic. Specifically, the function validate_mcp_command() in backend/chainlit/mcp.py performs an inadequate check on the stdio transport configuration.\nThe root cause is a lack of input validation for arguments passed to StdioServerParameters in backend/chainlit/server.py. The application verifies only the primary executable binary against the whitelist defined in config.features.mcp.stdio.allowed_executables but fails to inspect the fullCommand string for malicious parameters.\nBecause the system supports npx, an attacker can craft a payload containing the -c flag. Since npx -c allows for arbitrary shell command execution, this bypasses the intent of the executable whitelist. The system inadvertently treats the command string as a trusted directive for the subprocess module.\nThe attack flow begins with the discovery of an exposed Chainlit instance where the MCP feature is enabled. The attacker sends a crafted POST request to the /mcp endpoint. Since this endpoint lacks authentication, the attacker directly triggers the processing of the StdioServerParameters.\nWithin the payload, the attacker provides a fullCommand string such as 'npx -c \"[arbitrary_shell_command]\"'. The validator in backend/chainlit/mcp.py observes that 'npx' is the executable. If 'npx' is present in the allowlist, or if allowed_executables is unset (defaulting to allow-all), the validation logic returns true, permitting the command to proceed.\nThe backend subsequently initializes the subprocess with the attacker-controlled fullCommand string. The operating system interprets the npx command, executes the nested shell instruction, and returns the result to the attacker's context or executes the payload silently in the background.\nThis vulnerability is present in versions 2.4.0rc0 through 2.12.0. The impact is total system compromise, as the injected code inherits the permissions and environment of the Chainlit process. If the Chainlit service is running with elevated privileges or has access to sensitive API keys and database credentials, these assets are immediately exposed to the attacker. Post-exploitation activities may include the deployment of persistence mechanisms, reverse shells, or internal network scanning."
}