<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T15:12:46.061481+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/brew-cycode-cve-2026-59950</id>
    <title>BREW-cycode-CVE-2026-59950 — MCP Python SDK: WebSocket server transport does not support Host/Origin validation</title>
    <updated>2026-10-03T15:12:46.408893+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Homebrew: cycode</p>
<p>### Summary
In affected versions, the deprecated WebSocket server transport (`mcp.server.websocket.websocket_server`) 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.</p>
<p>### Am I affected?
Only if a developer's application server exposes `mcp.server.websocket.websocket_server`. 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.</p>
<p>### Details
`websocket_server()` 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 `security_settings: TransportSecuritySettings` and run `TransportSecurityMiddleware.validate_request()` 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 transpor…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/brew-cycode-cve-2026-59950"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cleanstart-2026-fx89856</id>
    <title>CLEANSTART-2026-FX89856 — Security fix for CVE-2026-59950 applied in: litellm-database 1.85.1-r1</title>
    <updated>2026-10-03T15:12:46.408978+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> CleanStart: litellm-database</p>
<p>Security vulnerability affects the litellm-database package. This issue is resolved in later releases. See references for vulnerability details.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cleanstart-2026-fx89856"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-338398</id>
    <title>EUVD-2026-338398</title>
    <updated>2026-10-03T15:12:46.409003+00:00</updated>
    <content>EUVD-2026-338398</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-338398"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-59950</id>
    <title>fkie_cve-2026-59950</title>
    <updated>2026-10-03T15:12:46.409017+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>The MCP Python SDK, called mcp on PyPI, is a Python implementation of the Model Context Protocol (MCP). Prior to 1.28.1, the deprecated mcp.server.websocket.websocket_server transport accepted WebSocket handshakes without applying Host or Origin header validation, leaving no SDK-level way to restrict which origins could connect to applications that exposed that transport. This issue is fixed in version 1.28.1.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-59950"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-vj7q-gjh5-988w</id>
    <title>GHSA-vj7q-gjh5-988w — MCP Python SDK: WebSocket server transport does not support Host/Origin validation</title>
    <updated>2026-10-03T15:12:46.409041+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: mcp</p>
<p>### Summary
In affected versions, the deprecated WebSocket server transport (`mcp.server.websocket.websocket_server`) 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.</p>
<p>### Am I affected?
Only if a developer's application server exposes `mcp.server.websocket.websocket_server`. 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.</p>
<p>### Details
`websocket_server()` 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 `security_settings: TransportSecuritySettings` and run `TransportSecurityMiddleware.validate_request()` 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 transpor…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-vj7q-gjh5-988w"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2026-3483</id>
    <title>PYSEC-2026-3483 — MCP Python SDK: WebSocket server transport does not support Host/Origin validation</title>
    <updated>2026-10-03T15:12:46.409083+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: mcp</p>
<p>### Summary
In affected versions, the deprecated WebSocket server transport (`mcp.server.websocket.websocket_server`) 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.</p>
<p>### Am I affected?
Only if a developer's application server exposes `mcp.server.websocket.websocket_server`. 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.</p>
<p>### Details
`websocket_server()` 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 `security_settings: TransportSecuritySettings` and run `TransportSecurityMiddleware.validate_request()` 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 transpor…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2026-3483"/>
  </entry>
</feed>
