--- service: "Publicasta" schema_version: "1.0" article_id: 572 title: "AWS naprawia obejścia trybu tylko do odczytu w serwerach MCP baz danych: co powinni sprawdzić operatorzy" language: "pl" default_language: "en" canonical_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=pl" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=pl" api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=pl" channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news" channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-10T07:01:46+00:00" updated_at: "2026-09-10T07:01:46+00:00" translations: - language: "ar" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ar" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ar" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ar" - language: "de" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=de" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=de" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=de" - language: "en" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=en" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=en" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=en" - language: "es" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=es" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=es" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=es" - language: "fr" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=fr" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=fr" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=pl" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=pl" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ru" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=zh" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=zh" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=zh" --- # AWS naprawia obejścia trybu tylko do odczytu w serwerach MCP baz danych: co powinni sprawdzić operatorzy > Dwa biuletyny bezpieczeństwa AWS pokazują, że filtr tekstu nie jest granicą autoryzacji. Sprawdź, które wersje serwerów MCP PostgreSQL i MySQL są podatne, jakie warunki zwiększają ryzyko oraz jak ograniczyć skutki. Dwa biuletyny bezpieczeństwa AWS opublikowane 9 września 2026 r. unaoczniają problem, który dotąd łatwo było opisywać abstrakcyjnie: narzędzie AI mogące wykonywać zapytania wobec produkcyjnej bazy danych nie może traktować reguły dopasowywania ciągów znaków jako ostatniej linii obrony. Ujawnione problemy dotyczą dwóch otwartoźródłowych, samodzielnie hostowanych serwerów Model Context Protocol z AWS Labs — jednego dla PostgreSQL i jednego dla MySQL. Oba mają tryb tylko do odczytu, którego zadaniem jest powstrzymanie asystenta przed wydawaniem modyfikujących instrukcji SQL. Ostatecznie jednak to konto bazy danych decyduje, co rzeczywiście może się wydarzyć. ![Abstrakcyjna ilustracja sieci AI i bazy danych oddzielonych bramką ostrzegawczą, ukazująca ograniczenia tekstowych filtrów trybu tylko do odczytu.](https://publicasta.com/storage/projects/17/pages/572/2026/09/dda7b4d7-2f7d-4716-88da-cc06ee10f526.webp) Problem w serwerze PostgreSQL jest poważniejszy. AWS nadał luce oznaczenie [CVE-2026-87911](https://aws.amazon.com/security/security-bulletins/2026-104-aws/). W określonej kombinacji wersji pakietu, sposobu połączenia, uprawnień bazy i interakcji użytkownika luka może umożliwić wykonanie poleceń systemu operacyjnego. Poprawka znajduje się w wersji 1.1.7. Biuletyn dotyczący MySQL, [CVE-2026-85788](https://aws.amazon.com/security/security-bulletins/2026-103-aws/), opisuje inną usterkę kontroli tylko do odczytu: w określonych warunkach komentarze wbudowane w instrukcję SQL mogły ominąć filtr. Podatne są wersje pakietu 1.0.21 i wcześniejsze, a według AWS problem rozwiązano w wersji 1.0.23. Nie są to podatności po stronie usług AWS, takich jak Aurora, RDS ani inna zarządzana płaszczyzna sterowania AWS. Problemy występują w pakietach klienckich, które klienci sami instalują i uruchamiają. To rozróżnienie ma znaczenie dla reagowania na incydent, ale nie czyni tych ujawnień drugorzędnymi. Pakiety łączą asystenta AI z bazami danych, poświadczeniami, a w niektórych konfiguracjach także z hostem, na którym działa serwer. Niewielki błąd parsera może więc stać się problemem kontroli dostępu w miejscu, gdzie żądania wyrażone językiem naturalnym są zamieniane na operacje bazodanowe. ## Co ujawnił AWS Oba biuletyny pojawiły się razem, lecz opisują odmienne warunki techniczne i powinny być analizowane osobno. Potraktowanie ich jako jednej, ogólnej podatności MCP utrudniłoby precyzyjną reakcję. W przypadku `awslabs.postgres-mcp-server` AWS informuje, że wersje wcześniejsze niż 1.1.7 zawierają lukę umożliwiającą wstrzyknięcie polecenia systemu operacyjnego w komponencie walidacji SQL, który wymusza tryb tylko do odczytu. Biuletyn wskazuje na spreparowaną instrukcję PostgreSQL `COPY ... TO PROGRAM` jako istotną funkcję bazy. W podatnym wdrożeniu treść przetwarzana podczas interakcji uwierzytelnionego użytkownika z serwerem MCP mogła trafić do tej ścieżki, mimo że serwer działał w domyślnym trybie tylko do odczytu. Biuletyn nie twierdzi, że każda instalacja jest zdalnie wykorzystywalna. Wskazuje węższy profil wdrożenia: samodzielnie zarządzany serwer PostgreSQL korzystający z metody połączenia `PG_WIRE_PROTOCOL` oraz skonfigurowana rola bazy mająca uprawnienia superużytkownika albo rolę `pg_execute_server_program`. AWS opisuje możliwy skutek jako wykonanie poleceń systemu operacyjnego na hoście samodzielnie zarządzanego serwera PostgreSQL. Słowo „możliwy” jest tu ważne. Poradnik potwierdza istnienie niebezpiecznej luki i określa warunki, w których ma ona znaczenie; nie potwierdza, że klienci padli ofiarą ataku. Dokumentacja PostgreSQL wyjaśnia, dlaczego warunek dotyczący uprawnień zmienia ocenę ryzyka. Polecenie `PROGRAM` jest wykonywane przez serwer bazy, a nie przez klienta, dlatego PostgreSQL ogranicza tę możliwość do superużytkowników lub użytkowników, którym przyznano rolę serwera-programu. Uprawnienie bazy jest zatem z założenia bardzo silne. Luka MCP ma znaczenie, ponieważ może pozwolić danym przekroczyć granicę, którą tryb tylko do odczytu pakietu miał egzekwować. W przypadku `awslabs.mysql-mcp-server` AWS podaje, że wersje do 1.0.21 włącznie mogą dopuścić wykonanie instrukcji, którą kontrola tylko do odczytu powinna zablokować, gdy w określonych warunkach użyte zostaną komentarze wbudowane w SQL. Biuletyn nie opisuje tej samej ścieżki wykonywania poleceń systemu operacyjnego co poradnik PostgreSQL. Wyjaśnia, że pakiet jest samodzielnie hostowany i że problem nie wpływa na poufność ani integralność usługi AWS. Praktyczne ryzyko polega na tym, że konto bazy z szerszymi uprawnieniami, niż zamierzano, może wykonać zapis, który kontrola na poziomie aplikacji próbowała odrzucić. Pierwsze fakty operacyjne do odnotowania to wersje zawierające poprawki: PostgreSQL 1.1.7 lub nowsza oraz MySQL 1.0.23 lub nowsza. Nie należy zakładać, że aktualizacja jednego pakietu naprawia drugi. Są to odrębne dystrybucje z osobnymi liniami wydań, a we flocie łatwo może znajdować się zarówno jedna, jak i druga. ## Dlaczego określenie „tylko do odczytu” wprowadzało w błąd Wiele narzędzi bazodanowych używa określenia „tylko do odczytu”, jakby oznaczało jedną właściwość. W rzeczywistości kryją się za nim co najmniej trzy różne mechanizmy. Pierwszy to parser lub filtr wewnątrz aplikacji. Analizuje tekst SQL i odrzuca tokeny kojarzone z zapisami, zmianami sesji lub innymi wrażliwymi operacjami. Jest szybki i przydatny jako informacja zwrotna dla użytkownika. Może zatrzymać typową pomyłkę, na przykład wygenerowanie przez asystenta instrukcji `UPDATE`, gdy użytkownik poprosił o raport. Drugi to tryb sesji bazy danych albo transakcji. PostgreSQL i MySQL mają mechanizmy ograniczające działania sesji, choć dokładne zachowanie i wyjątki zależą od silnika, metody połączenia oraz konta. Ustawienie na poziomie sesji może dołożyć kolejną warstwę, ale nie zastępuje uprawnień konta i trzeba je sprawdzić wobec rzeczywistego obciążenia oraz używanego sposobu pracy. Trzeci mechanizm to sama tożsamość bazy danych: rola lub użytkownik uwierzytelniający się na serwerze. Ta tożsamość ma nadania, własność obiektów, członkostwo w rolach, dostęp do procedur składowanych i ewentualnie specjalne możliwości serwera. Jest trwałą granicą, ponieważ baza ocenia ją po przejściu żądania przez klienta, serwer MCP, parser SQL i wszelkie pośrednie zasady. Aktualny README serwera PostgreSQL AWS wyraźnie mówi, że egzekwowanie trybu tylko do odczytu jest zabezpieczeniem typu best effort, a nie granicą bezpieczeństwa. Zaleca dedykowaną rolę bazy i ostrzega przed użyciem superużytkownika, `rds_superuser` lub głównego użytkownika klastra. README MySQL przekazuje tę samą zasadę: strażnik tekstu SQL jest obroną warstwową, natomiast rzeczywistą granicę stanowi skonfigurowana rola bazy. Ujawnione problemy nadają tej dokumentacji wymiar praktyczny. Filtry tekstu działają na reprezentacji, którą rozpoznają. SQL ma komentarze, cytowane identyfikatory, składnię warunkową, procedury składowane, funkcje zależne od wersji, wiele instrukcji oraz zachowanie parsera zmieniające się z czasem. LLM jest kolejnym źródłem zmienności: może tworzyć nietypowe, lecz poprawne składniowo dane wejściowe, a na jego zachowanie może wpływać treść zwrócona przez bazę lub inne narzędzie. Nie można oczekiwać, że wyrażenie regularne zamodeluje wszystkie te interakcje. Bezpieczny projekt powinien zatem stawiać dwa różne pytania. „Czy serwer MCP odrzuci to żądanie?” pomaga ograniczać przypadkowe zapisy. „Jeśli serwer je zaakceptuje, co może zrobić konto bazy?” — to pytanie ogranicza skutki. Druga odpowiedź musi pozostać bezpieczna także wtedy, gdy pierwsza kontrola zostanie ominięta, źle skonfigurowana, będzie nieaktualna albo po prostu niepełna. ## Kto powinien potraktować sprawę jako pilny przegląd Biuletyn PostgreSQL jest najistotniejszy dla organizacji, które przed wersją 1.1.7 zainstalowały pakiet AWS Labs i łączą go z samodzielnie zarządzanym środowiskiem PostgreSQL przez protokół wire. Natychmiastowej uwagi wymaga rola bazy, jeśli jest superużytkownikiem lub ma `pg_execute_server_program`. Wdrożenie korzystające z Aurory albo innego zarządzanego profilu może nie odpowiadać profilowi wskazanemu w biuletynie, ale operatorzy nadal powinni wykonać aktualizację. Wersja pakietu jest częścią łańcucha dostaw oprogramowania, a wskazówki bezpieczeństwa serwera wykraczają poza jeden warunek wykorzystania luki. Biuletyn MySQL dotyczy instalacji w wersji 1.0.21 lub wcześniejszej. Ponieważ pakiet jest często uruchamiany za pomocą zakresu wersji albo zmiennego odwołania `latest`, zespoły nie powinny zakładać, że działająca konfiguracja wskazuje używany kod. Trzeba ustalić zainstalowaną wersję w rzeczywistym środowisku klienta, obrazie kontenera, pliku blokady lub artefakcie wdrożeniowym. Wynik należy zapisać, zamiast opierać się na samej nazwie pakietu w pliku konfiguracyjnym. Zespoły powinny też sprawdzić sposób wybierania poświadczeń. Dokumentacja AWS Labs opisuje połączenia, w których poświadczenia AWS służą do wykrywania zasobów baz danych, a poświadczenia z Secrets Manager uwierzytelniają dostęp do bazy. Serwer MCP połączony z bazą może więc mieć dwie płaszczyzny uprawnień: AWS IAM oraz uprawnienia samej bazy. Ograniczona rola IAM nie sprawia automatycznie, że logowanie do bazy jest tylko do odczytu. Z kolei rola bazy tylko do odczytu nie powstrzymuje automatycznie serwera MCP przed odczytem wrażliwych metadanych AWS lub plików lokalnych, jeśli otaczająca konfiguracja przyznaje mu takie możliwości. Ryzyko rośnie, gdy serwer działa na stacji deweloperskiej zawierającej kod źródłowy, poświadczenia chmurowe, materiały SSH, artefakty kompilacji lub sesje przeglądarki. Jest również większe, gdy serwer jest dostępny przez sieć, współdzielony przez użytkowników albo uruchamiany z szerokim uprawnieniem administratora. Dokumentacja AWS API MCP Server, choć dotyczy powiązanego pakietu, ostrzega, że lokalny projekt STDIO zakłada jednego użytkownika i bezpośredni dostęp do hosta. Wskazuje też, że IAM pozostaje podstawową kontrolą, a klasyfikacja operacji jako tylko do odczytu nie gwarantuje nieszkodliwości wyników poleceń. Są to użyteczne ostrzeżenia architektoniczne także dla wdrożeń bazodanowych MCP. ## Pierwszą reakcją powinien być spis, nie spekulacje Operator reagujący na te biuletyny nie musi zaczynać od dowodzenia, że luka może zostać wykorzystana. Pierwszym celem jest ustalenie, czy istnieje podatny kod oraz odpowiadające mu warunki uprawnień. Krótki spis odpowie na większość pytań o największej wartości. - Zidentyfikuj każdą instalację `awslabs.postgres-mcp-server` i `awslabs.mysql-mcp-server`, w tym lokalne konfiguracje deweloperskie, kontenery, procesy CI, współdzielone hosty pośredniczące oraz środowiska IDE dostarczane jako pakiety. - Zapisz dokładną wersję, sposób uruchomienia, metodę połączenia, silnik bazy oraz profil punktu końcowego dla każdej instalacji. - Powiąż użytkownika lub rolę bazy używaną przez każdy serwer z nadaniami i członkostwami. W PostgreSQL sprawdź szczególnie status superużytkownika i `pg_execute_server_program`; w MySQL — uprawnienia administracyjne, szerokie nadania schematów, wykonywanie procedur składowanych oraz własność obiektów produkcyjnych. - Ustal, czy serwer działa wyłącznie lokalnie, czy jest osiągalny przez sieć, a także czy ten sam proces może być wywoływany przez wiele osób lub dzierżawców. - Sprawdź, czy serwer może zapisywać do bazy, czytać lokalne pliki, wywoływać interfejsy chmurowe albo zwracać sekrety w wynikach narzędzia. - Zachowaj odpowiednie manifesty pakietów, skróty obrazów kontenerów, historię konfiguracji, logi uwierzytelniania, rejestry audytowe bazy oraz logi klientów MCP, zanim zmienisz środowisko. Celem jest zbudowanie konkretnego obrazu sytuacji. Samo stwierdzenie „korzystamy z asystenta AI” nie wystarcza do oceny problemu. Samodzielnie zarządzany PostgreSQL z niskoprzywilejowaną rolą raportową to inny przypadek niż laptop dewelopera używający głównego poświadczenia klastra wobec produkcyjnej bazy. Oba środowiska mogą mieć tę samą nazwę pakietu. ## Najpierw aktualizacja, potem ograniczenie uprawnień Bezpośrednim działaniem naprawczym jest aktualizacja do wersji wskazanych przez dostawcę: PostgreSQL MCP Server 1.1.7 lub nowszej oraz MySQL MCP Server 1.0.23 lub nowszej. Wersję trzeba przypiąć w mechanizmie, który faktycznie uruchamia serwer. Jeśli konfiguracja używa `@latest`, szerokiego zakresu pakietu albo nieprzypiętego taga kontenera, kolejna aktualizacja może być bezpieczniejsza, lecz obecny stan nadal będzie trudny do odtworzenia i audytu. Użyj pliku blokady, niezmiennego skrótu obrazu albo równoważnego mechanizmu kontrolowanego wydania. Po aktualizacji zmień uprawnienia bazy, jeśli są szersze niż wymaga zadanie. Dla przepływu raportowego dedykowana rola powinna zasadniczo mieć dostęp tylko do potrzebnej bazy, schematów, tabel, widoków i wąsko wybranych procedur. Dokumentacja PostgreSQL oraz README AWS Labs odradzają superużytkowników i uprawnienia serwera-programu dla takiej integracji. Rola, która musi jedynie odczytywać zatwierdzone widoki raportowe, nie powinna dziedziczyć roli pozwalającej administrować klastrem lub wykonywać programy na hoście bazy. Ta sama zasada dotyczy MySQL. README AWS Labs zaleca dedykowane konto z wyłącznie wymaganymi nadaniami, na przykład `SELECT` dla właściwej bazy oraz `EXECUTE` tylko dla konkretnie zatwierdzonych procedur. Wyjaśnia również, że filtr po stronie serwera ma wychwytywać typowe instrukcje modyfikujące, ale nie może stanowić gwarancji wobec każdego przypadku brzegowego gramatyki ani przyszłej funkcji SQL. Niezawodny mechanizm odmowy to błąd bazy wynikający z braku uprawnień, a nie pewny siebie komunikat asystenta twierdzącego, że zapis został zablokowany. Nie próbuj „naprawiać” problemu przez włączenie bardziej rozbudowanej reguły w promptcie. Instrukcje dla modelu mogą poprawić zachowanie, lecz nie są kontrolą dostępu. Pliki sterujące, komunikaty systemowe, listy zatwierdzeń i prośby o potwierdzenie przez człowieka mają wartość w warstwowym projekcie, ale żadna z tych rzeczy nie powinna być jedyną barierą chroniącą dane produkcyjne. Użytkownik albo dokument zawierający prompt injection może wpłynąć na tekst wysyłany do modelu, a model może wygenerować żądanie, którego autor promptu nie przewidział. Konto wykonujące żądanie nadal musi nie mieć możliwości wyjścia poza zamierzony zakres. ## Osobno sprawdź płaszczyznę uprawnień AWS Część zespołów skupi się na filtrze SQL i przeoczy uprawnienia AWS używane przez proces MCP. README PostgreSQL informuje, że serwer może korzystać z profilu AWS do wykrywania klastrów lub instancji, a na ścieżce RDS Data API może potrzebować uprawnienia do wykonywania instrukcji. W opisanych konfiguracjach używa też Secrets Manager do pobierania poświadczeń bazy. Są to odrębne decyzje od nadań użytkownika bazy. Użyj specjalnie przygotowanej roli lub profilu IAM dla tego procesu. Ograniczaj dostęp do zasobów tam, gdzie dana usługa AWS to umożliwia, i nie dołączaj polityk administratora tylko dlatego, że asystent może kiedyś potrzebować sprawdzić infrastrukturę. Wytyczne IAM AWS zalecają zasadę najmniejszych uprawnień, tymczasowe poświadczenia dla obciążeń, gdy jest to możliwe, regularny przegląd nieużywanych uprawnień oraz korzystanie z IAM Access Analyzer w celu dopracowania polityk na podstawie zaobserwowanej aktywności. Pamiętaj, że „tylko do odczytu” na poziomie API AWS nie jest równoznaczne z „bezpiecznym wynikiem”. Niektóre operacje odczytu mogą zwracać konfigurację, identyfikatory, dokumenty polityk lub inne wrażliwe materiały. Dokumentacja AWS API MCP Server mówi o tym wprost. Asystent bazodanowy, który potrafi łączyć wykrywanie zasobów chmurowych, pobieranie sekretów, zapytania do bazy i operacje na lokalnych plikach, ma znacznie szerszą efektywną władzę, niż sugerują słowa „SQL tylko do odczytu”. W miarę możliwości rozdzielaj funkcje. Narzędzie odpowiadające na pytania dotyczące zatwierdzonych danych nie musi mieć uprawnień do tworzenia klastrów, zmiany kontroli sieci, pobierania dowolnych sekretów ani zapisywania plików. Jeśli dany przepływ wymaga takich możliwości, umieść je za osobno zatwierdzonym narzędziem i odrębną tożsamością, zamiast dodawać je do ogólnego procesu raportowego. ## Sprawdź użycie podatnych wersji Biuletyny nie potwierdzają, że luki były wykorzystywane w rzeczywistych atakach. Publiczna dyskusja wokół CVE nie jest dowodem incydentu, a obecność podatnego pakietu nie dowodzi, że napastnik uzyskał do niego dostęp. Mimo to przegląd logów ma sens, ponieważ podatna ścieżka łączy treść kontrolowaną przez użytkownika z powierzchnią wykonywania operacji na bazie. W PostgreSQL przejrzyj logi bazy i rejestry audytowe pod kątem nietypowego użycia funkcji serwerowych dotyczących plików lub programów, nieoczekiwanych zmian ról, tworzenia nieznanych funkcji, zmian konfiguracji uwierzytelniania oraz aktywności konta usługi MCP wykraczającej poza zwykły wzorzec zapytań. Zbadaj telemetrię hosta serwera bazy pod kątem procesów, plików, połączeń sieciowych lub mechanizmów utrwalania, których nie da się wyjaśnić obciążeniem bazy. Przegląd powinien pozostać na poziomie defensywnego wykrywania; artykuł ani zgłoszenie incydentu nie powinny stawać się instrukcją odtwarzania wykonania poleceń. W MySQL przejrzyj instrukcje, które powinny zostać zablokowane, lecz pojawiają się w logach audytowych, nieoczekiwane zmiany tabel produkcyjnych, użycie uprawnień administracyjnych lub związanych z plikami oraz połączenia konta MCP z nietypowych klientów albo o nietypowych porach. Porównaj zaobserwowane instrukcje z żądaniami wyrażonymi językiem naturalnym, które je wygenerowały, jeśli takie dane są dostępne. Rozbieżność może ujawnić prompt injection, zbyt szeroki kontrakt narzędzia, problem parsera albo zwykły błąd modelu. CloudTrail może pomóc w zbadaniu strony AWS, ale nie zastąpi telemetrii bazy ani hosta. Szukaj nieoczekiwanych odczytów Secrets Manager, wykrywania RDS lub klastrów poza zwykłym przepływem, zmian IAM albo grup bezpieczeństwa oraz dostępu z tożsamości powiązanych z procesem MCP. Skoreluj znaczniki czasu z klienta MCP, bazy danych, systemu operacyjnego i logów chmurowych. Jeżeli dowody wskazują na nieuprawniony dostęp, postępuj zgodnie z organizacyjną procedurą reagowania na incydenty: odizoluj dotknięty proces, odpowiednio obróć lub unieważnij poświadczenia, zachowaj dowody i oceń integralność bazy oraz hosta. Sama aktualizacja nie jest pełną reakcją na incydent, jeśli mogło dojść do użycia uprzywilejowanego poświadczenia. ## Co to zmienia w projekcie wdrożeń MCP Bezpośrednią poprawką są aktualizacje pakietów, ale szersza lekcja dotyczy miejsca, w którym integracja AI może znajdować się w architekturze. Serwer MCP tłumaczący język naturalny na SQL nie jest wyłącznie wygodnym adapterem. To interpreter umieszczony między człowiekiem, modelem, protokołem narzędzia i systemem przechowującym stan. Każda z tych warstw może przekształcać żądanie albo dodawać mu znaczenie. Potrzebne są kontrole, które pozostają zrozumiałe także wtedy, gdy model zachowuje się nieprzewidywalnie. Warto rozdzielić analitykę tylko do odczytu od operacyjnego dostępu do bazy. Należy utworzyć rolę bazy specjalnie dla integracji, ograniczyć ją do zatwierdzonych obiektów, a zapisy produkcyjne pozostawić w przepływie wymagającym odrębnej tożsamości i wyraźnego procesu zmian. Jeśli produkt został zaprojektowany do pracy jednoosobowej przez STDIO, serwer MCP powinien pozostać lokalny albo zostać odpowiednio odizolowany. Host, ruch wychodzący, sekrety i dostęp do systemu plików wokół procesu także powinny być ograniczone. Wersje i konfiguracja muszą być obserwowalne. Zespół powinien móc odpowiedzieć, który pakiet MCP działał, z jakimi argumentami, pod jaką tożsamością, wobec jakiej bazy oraz które wywołanie narzędzia wygenerowało dane zapytanie. Jeśli tych odpowiedzi brakuje, ujawnienie podatności przerodzi się w długą dyskusję o tym, co być może jest zainstalowane, zamiast w szybką decyzję o remediacji. Testy powinny obejmować rzeczywisty kontrakt bezpieczeństwa, a nie tylko pomyślne zapytanie. Sprawdź, czy zwykłe żądania odczytu działają, czy nieuprawnione zapisy kończą się odmową na poziomie bazy, czy proces nie może korzystać z uprzywilejowanych funkcji serwera, czy błędy prowadzą do bezpiecznej odmowy oraz czy zniekształcone lub nieoczekiwane dane wejściowe nie wyłączają po cichu polityki. Powtórz testy po aktualizacji zależności i po aktualizacji silnika bazy. Celem nie jest dowiedzenie, że filtr rozpoznaje każdy możliwy zapis SQL. Celem jest potwierdzenie, że niezaufane żądanie nie może przekroczyć skutku dozwolonego dla danej tożsamości. ## Praktyczny wniosek Biuletyny AWS z 9 września przypominają, że „tylko do odczytu” jest twierdzeniem projektowym, które trzeba egzekwować w więcej niż jednym miejscu. Problem PostgreSQL wymaga szczególnej uwagi tam, gdzie stary pakiet łączy się przez wire z samodzielnie zarządzanym serwerem przy użyciu roli superużytkownika lub `pg_execute_server_program`. Problem MySQL dotyczy starszych wersji pakietu i pokazuje, że składnia SQL wyglądająca niegroźnie dla filtra tekstu nadal może mieć znaczenie. Zaktualizuj oba pakiety wszędzie tam, gdzie są obecne. Spisz rzeczywiste wersje uruchamiane przez poszczególne procesy oraz metody połączeń. Zastąp silne konta bazodanowe rolami o wąskim zakresie. Przejrzyj profil IAM, dostęp do sekretów, uprawnienia hosta i ekspozycję sieciową procesu MCP. Następnie wykorzystaj logi bazy, hosta i chmury, aby ustalić, czy podatne instalacje były tylko podatne, czy również niewłaściwie użyte. Trwała zasada jest prosta, choć jej wdrożenie może wymagać pracy: to baza danych powinna egzekwować granicę bazy danych. Instrukcje modelu i filtry SQL traktuj jako pomocne warstwy wokół tej granicy, a nie jako jej zamiennik. ## Źródła - [CVE-2026-87911 — obejście egzekwowania trybu tylko do odczytu w awslabs postgres-mcp-server](https://aws.amazon.com/security/security-bulletins/2026-104-aws/) — Amazon Web Services. - [CVE-2026-85788 — problem z awslabs mysql-mcp-server](https://aws.amazon.com/security/security-bulletins/2026-103-aws/) — Amazon Web Services. - [README AWS Labs postgres MCP Server i model bezpieczeństwa](https://github.com/awslabs/mcp/blob/main/src/postgres-mcp-server/README.md) — AWS Labs. - [README AWS Labs mysql MCP Server i model bezpieczeństwa](https://github.com/awslabs/mcp/blob/main/src/mysql-mcp-server/README.md) — AWS Labs. - [Dokumentacja PostgreSQL dotycząca COPY](https://www.postgresql.org/docs/15/sql-copy.html) — PostgreSQL Global Development Group. - [Najlepsze praktyki bezpieczeństwa w IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) — Amazon Web Services. - [AWS Identity and Access Management User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/iam-ug.pdf) — Amazon Web Services. - [aws-api-mcp-server: migracja do AWS MCP Server](https://github.com/awslabs/mcp/issues/4115) — AWS Labs.