https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 22:04:16 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-335564 EUVD-2026-335564 https://cve.radiocsirt.org/vuln/euvd-2026-335564 https://cve.radiocsirt.org/vuln/fkie_cve-2026-55605 <p>DeepSeek MCP Server is an MCP server for DeepSeek V4. Starting in version 1.4.2 and prior to version 1.8.0, the self-hosted HTTP transport of `@arikusi/deepseek-mcp-server` exposes `POST /mcp` without any authentication: `createMcpExpressApp` is called without an `authProvider` and no middleware guards the route, so any network-reachable client can issue an unauthenticated `initialize` request and obtain a valid MCP session identifier. In reproduced testing against commit `5e1302171e99`, an unauthenticated client was able to initialize a session, enumerate tools, and invoke the local `deepseek_sessions` tool with no credentials. The same unauthenticated session also exposes `deepseek_chat`, whose handler uses the server-side `DEEPSEEK_API_KEY` when self-hosted deployments configure one. This issue applies to self-hosted HTTP mode, not the separately documented hosted BYOK endpoint in `README.md`, which expects an `Authorization: Bearer ...` header. Upstream self-hosted container assets enable HTTP mode by default (`Dockerfile`) and publish port `3000` (`docker-compose.yml`). Version 1.8.0 contains a patch for this issue.</p> <p>DeepSeek MCP Server is an MCP server for DeepSeek V4. Starting in version 1.4.2 and prior to version 1.8.0, the self-hosted HTTP transport of `@arikusi/deepseek-mcp-server` exposes `POST /mcp` without any authentication: `createMcpExpressApp` is called without an `authProvider` and no middleware guards the route, so any network-reachable client can issue an unauthenticated `initialize` request and obtain a valid MCP session identifier. In reproduced testing against commit `5e1302171e99`, an unauthenticated client was able to initialize a session, enumerate tools, and invoke the local `deepseek_sessions` tool with no credentials. The same unauthenticated session also exposes `deepseek_chat`, whose handler uses the server-side `DEEPSEEK_API_KEY` when self-hosted deployments configure one. This issue applies to self-hosted HTTP mode, not the separately documented hosted BYOK endpoint in `README.md`, which expects an `Authorization: Bearer ...` header. Upstream self-hosted container assets enable HTTP mode by default (`Dockerfile`) and publish port `3000` (`docker-compose.yml`). Version 1.8.0 contains a patch for this issue.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-55605 https://cve.radiocsirt.org/vuln/ghsa-72f3-6w86-7rv3 <p><strong>Affected:</strong> npm: @arikusi/deepseek-mcp-server</p> <p>## Summary The self-hosted HTTP transport of `@arikusi/deepseek-mcp-server` exposes `POST /mcp` without any authentication: `createMcpExpressApp` is called without an `authProvider` and no middleware guards the route, so any network-reachable client can issue an unauthenticated `initialize` request and obtain a valid MCP session identifier. In reproduced testing against commit `5e1302171e99`, an unauthenticated client was able to initialize a session, enumerate tools, and invoke the local `deepseek_sessions` tool with no credentials. The same unauthenticated session also exposes `deepseek_chat`, whose handler uses the server-side `DEEPSEEK_API_KEY` when self-hosted deployments configure one.</p> <p>This issue applies to self-hosted HTTP mode, not the separately documented hosted BYOK endpoint in `README.md`, which expects an `Authorization: Bearer ...` header. Upstream self-hosted container assets enable HTTP mode by default (`Dockerfile`) and publish port `3000` (`docker-compose.yml`).</p> <p>## Affected Code `src/transport-http.ts:17` — `createMcpExpressApp` called without `authProvider`; no challenge is issued to incoming requests</p> <p>```typescript export function createHttpApp(serverFactory: () =&gt; McpServer) { const app = createMcpExpressApp({ host: &#39;0.0.0.0&#39; }); ```</p> <p>`src/transport-http.ts:31` — `POST /mcp` handler instantiates a full MCP session for any body that satisfies `isInitializeRequest`, with no preceding auth check</p> <p>```typescript app.post(&#39;/mcp&#39;, async (req, res) =&gt; {…</p> <p><strong>Affected:</strong> npm: @arikusi/deepseek-mcp-server</p> <p>## Summary The self-hosted HTTP transport of `@arikusi/deepseek-mcp-server` exposes `POST /mcp` without any authentication: `createMcpExpressApp` is called without an `authProvider` and no middleware guards the route, so any network-reachable client can issue an unauthenticated `initialize` request and obtain a valid MCP session identifier. In reproduced testing against commit `5e1302171e99`, an unauthenticated client was able to initialize a session, enumerate tools, and invoke the local `deepseek_sessions` tool with no credentials. The same unauthenticated session also exposes `deepseek_chat`, whose handler uses the server-side `DEEPSEEK_API_KEY` when self-hosted deployments configure one.</p> <p>This issue applies to self-hosted HTTP mode, not the separately documented hosted BYOK endpoint in `README.md`, which expects an `Authorization: Bearer ...` header. Upstream self-hosted container assets enable HTTP mode by default (`Dockerfile`) and publish port `3000` (`docker-compose.yml`).</p> <p>## Affected Code `src/transport-http.ts:17` — `createMcpExpressApp` called without `authProvider`; no challenge is issued to incoming requests</p> <p>```typescript export function createHttpApp(serverFactory: () =&gt; McpServer) { const app = createMcpExpressApp({ host: &#39;0.0.0.0&#39; }); ```</p> <p>`src/transport-http.ts:31` — `POST /mcp` handler instantiates a full MCP session for any body that satisfies `isInitializeRequest`, with no preceding auth check</p> <p>```typescript app.post(&#39;/mcp&#39;, async (req, res) =&gt; {…</p> https://cve.radiocsirt.org/vuln/ghsa-72f3-6w86-7rv3