2 września 2026 CISA po raz pierwszy dodała podatność Model Context Protocol do swojego katalogu Known Exploited Vulnerabilities. Pięć dni później w innym, szeroko używanym serwerze MCP pojawił się drugi, poważniejszy błąd. Żaden z nich nie jest egzotyczną luką specyficzną dla MCP — jeden to mechanizm awaryjny uwierzytelniania, który zawiódł w trybie otwartym, drugi to obejście uprawnień w bazie danych — i właśnie o to chodzi: MCP jest teraz na tyle szeroko wdrożony, że powalają go zwykłe klasy błędów w zwykłej infrastrukturze.

Pierwszy wpis MCP na liście wykorzystywanych luk CISA

CVE-2026-59822 to obejście uwierzytelniania w LiteLLM, otwartoźródłowym proxy, którego duża część samodzielnie hostowanych stosów AI używa do kierowania wywołań do modeli, a w wielu zespołach także do serwerów MCP. CISA dodała ją do katalogu Known Exploited Vulnerabilities 2 września, z terminem usunięcia do 16 września dla federalnych systemów USA — to szybki zegar, który zgodnie z nową dyrektywą Binding Operational Directive 26-04 jest zarezerwowany dla luk z potwierdzonym wykorzystaniem, osiągalnych z publicznego internetu i łatwych do zautomatyzowania. Z tego, co wiemy, to pierwsza implementacja Model Context Protocol na tej liście.

Jak działało obejście

Punkt końcowy MCP Streamable HTTP w LiteLLM sprawdza klucz wywołującego i ma ścieżkę awaryjną dla przekazywania OAuth2 do usług nadrzędnych. Gdy weryfikacja klucza się nie powiodła, ścieżka awaryjna nie odrzucała żądania — podstawiała pusty obiekt UserAPIKeyAuth() i mimo to przepuszczała wywołanie. Żądanie z niczym więcej niż sfabrykowanym nagłówkiem Authorization mogło dotrzeć do dowolnych skonfigurowanych narzędzi MCP, bez ważnego klucza. Poprawka, wydana w wersji 1.84.0, zamyka tę ścieżkę. LiteLLM opublikował komunikat już w czerwcu; dopiero wpis CISA dwa miesiące później potwierdził, że luka była faktycznie wykorzystywana przeciwko prawdziwym wdrożeniom, a nie tylko teoretycznie możliwa do wykorzystania.

Drugi, poważniejszy błąd pięć dni później

9 września AWS Labs ujawniło CVE-2026-87911 we własnym postgres-mcp-server: krytyczną lukę z oceną CVSS 9.6, w której walidację SQL stojącą za trybem tylko do odczytu można było obejść spreparowaną instrukcją COPY ... TO PROGRAM, co pozwalało atakującemu uruchamiać polecenia systemu operacyjnego na hoście bazy danych. Daje o sobie znać tylko wtedy, gdy serwer MCP łączy się z rolą mającą uprawnienia superuser lub pg_execute_server_program — to skrót, na który idzie wiele szybkich konfiguracji, bo to droga najmniejszego oporu, dopóki ktoś nie przeczyta za Ciebie komunikatu. Naprawione w 1.1.7.

Dlaczego to trafia akurat w MCP

Żaden z błędów nie jest wadą specyfikacji MCP — mechanizm awaryjny uwierzytelniania, który zawodzi w trybie otwartym, i eskalacja uprawnień przez COPY TO PROGRAM to klasy błędów stare jak technologie pod spodem. Zmieniło się to, że ich przyspieszone łatanie jest teraz warte czasu CISA i AWS, bo serwery MCP stoją dokładnie tam, gdzie baza danych czy bramka API: są osiągalne, przechowują dane uwierzytelniające i są już na tyle powszechne, że stanowią klasę celów, a nie ciekawostkę. Wrześniowa partia CISA z 2 września objęła siedem wykorzystywanych luk; trzy z nich, w tym ta, zgłoszono jako wymierzone konkretnie w infrastrukturę AI.

Co z tym faktycznie zrobić

  • Zaktualizuj LiteLLM do 1.84.0+ i postgres-mcp-server do 1.1.7+, jeśli używasz któregoś z nich — obie poprawki są już dostępne.
  • Każdy serwer MCP, który dotyka bazy danych, łącz z rolą ograniczoną do tabel i operacji, których faktycznie potrzebuje, nigdy jako superuser. Tryb tylko do odczytu to siatka bezpieczeństwa, a nie zamiennik uprawnień na poziomie bazy danych.
  • Testuj ścieżkę błędu w uwierzytelnianiu, a nie tylko ścieżkę sukcesu. Walidator, który zawodzi w trybie otwartym, jest gorszy niż taki, który się wysypuje, a z zewnątrz wyglądają identycznie, dopóki ktoś nie znajdzie luki.
  • Jeśli nie możesz załatać od razu, umieść proxy MCP za bramką, która sama potrafi blokować lub ograniczać liczbę zapytań do tras /mcp/.

To również podkreśla tezę, którą nasza własna lista kontrolna OAuth powtarza od sierpnia: specyfikacja wymaga OAuth 2.1 na każdym serwerze MCP, a wiele serwerów wciąż idzie na skróty. Te dwa CVE pokazują, ile to kosztuje w praktyce — nie hipotetycznie, tylko jako datowany wpis w katalogu CISA z dołączonym terminem usunięcia.