CVE-2026-25536

W MCP TypeScript SDK od wersji 1.24.0 do przed 1.32.0 eksperymentalna funkcja tasks (taskStore) nie sprawdzała, która sesja utworzyła zadanie. Klienci współdzielący jeden InMemoryTaskStore mogli wyświetlać, odczytywać i anulować zadania innych klientów.

MCP TypeScript SDK w wersjach od 1.12.0 przed 1.31.0 i 2.2.0 pozwala serwerowi MCP, do którego klient się podłącza, decydować, który serwer autoryzacji otrzyma poświadczenia OAuth klienta. Przechowywane i wstępnie zaopatrzone poświadczenia nie były powiązane z serwerem autoryzacji, do którego należą. Złośliwy lub skompromitowany serwer MCP może wskazać własny serwer autoryzacji w metadanych chronionego zasobu. Bez interakcji użytkownika klient wysyłałby temu serwerowi `refresh_token` i `client_secret` zapisane z wcześniejszego logowania (1.x) lub skonfigurowany `client_secret` lub podpisaną asercję z dołączonego nieinteraktywnego dostawcy (1.x i 2.x). Dotyczy to tylko aplikacji używających SDK jako klienta MCP przez HTTP z `authProvider`: własnym `OAuthClientProvider` lub dołączonym `ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider` lub (2.x) `CrossAppAccessProvider` i które mogą łączyć się z serwerem MCP, któremu właściciele nie ufają w pełni, trzymając poświadczenia dla legalnego serwera autoryzacji. `@modelcontextprotocol/sdk` 1.31.0 (1.x) i `@modelcontextprotocol/client` 2.2.0 (2.x) łatają problem. Dostępny jest workaround dla tych, którzy nie mogą zaktualizować. 2.0.0 i 2.1.0 już akceptują `expectedIssuer`. W 1.x jedynym workaroundem jest łączenie klientów z włączonym OAuth tylko z zaufanymi serwerami MCP.

Podatność ReDoS w bibliotece MCP TypeScript SDK od Anthropic (wersje do 1.25.1 włącznie) występuje w klasie UriTemplate podczas przetwarzania wzorców tablicowych RFC 6570. Dynamicznie generowane wyrażenie regularne zawiera zagnieżdżone kwantyfikatory, które mogą prowadzić do katastroficznego cofania się na specjalnie spreparowanych danych wejściowych, powodując nadmierne zużycie CPU.