AWS postgres-mcp-server CVE-2026-87911: „read-only” może skończyć się wykonaniem polecenia w systemie operacyjnym

AWS opublikował 9 września 2026 advisory dla awslabs.postgres-mcp-server. CVE-2026-87911 (wersje <1.1.7) uderza w mechanizm, który miał wymuszać tryb tylko do odczytu: w określonej konfiguracji crafted SQL może użyć COPY ... TO PROGRAM — funkcji PostgreSQL uruchamiającej program po stronie serwera. Najważniejsze pytanie VE brzmi: gdzie kończy się deklaracja capability, a zaczyna techniczna granica uprawnień? Odpowiedź AWS jest konkretna: aplikacyjny filtr zapytań nie jest samodzielną granicą — blast radius wyznaczają uprawnienia roli PostgreSQL.

CVE-2026-87911 (fix 1.1.7): bypass read-only + COPY ... TO PROGRAM → OS command execution, jeśli rola ma superuser lub pg_execute_server_program.

Mierzalny control: least privilege po stronie PostgreSQL, nie regex na SQL po stronie MCP.

Attack path

agent/uzytkownik korzysta z postgres-mcp-server (tryb read-only) -> tresc prowadzi do craftowanego SQL -> walidacja MCP nie zatrzymuje COPY ... TO PROGRAM -> zapytanie trafia do PostgreSQL (PG wire protocol) -> rola z superuser/pg_execute_server_program uruchamia polecenie systemowe -> execution boundary na hoscie bazy

Kluczowy jest warunek roli: sama podatna wersja nie dowodzi pełnego impactu, ale też napis „read-only” w MCP nie dowodzi bezpieczeństwa. Do OS command execution potrzebne są: podatna wersja, właściwy sposób komunikacji z bazą, rola z niebezpiecznym uprawnieniem i ścieżka, przez którą crafted content dociera do narzędzia. AWS nie potwierdza active exploitation — nie dopisuj sygnału „exploited”; brak potwierdzenia nie oznacza jednak braku pilności, bo MCP pracuje na styku modelu, narzędzia i uprzywilejowanego backendu (prompt injection może być częścią path).

False positive i false negative

False positive: skaner widzi <1.1.7 i raportuje RCE, a instancja nie używa wymaganej ścieżki, łączy się rolą bez superuser/pg_execute_server_program, ma transakcyjne read-only wymuszone przez PostgreSQL — stan to product vulnerable / environment mitigated z rewalidacją, nie „not affected”. False negative: po 1.1.7 ticket zamknięty, ale serwer nadal łączy się jako superuser — CVE zamknięte, architektura gotowa na kolejny bypass. To różnica PATCH_APPLIED vs REMEDIATION_VERIFIED.

Least privilege i weryfikacja

AWS: poza 1.1.7 — least privilege. Rola read-only powinna mieć tylko konieczne prawa (np. CONNECT, USAGE do schematów, SELECT do obiektów) i mieć odebrane superuser, pg_execute_server_program i inne role przekraczające granicę danych. Blokada zapytań i minimalna rola to defense in depth, nie zamienniki. Weryfikacja wielopoziomowa: (1) wersja realnie uruchomionego procesu ≥ 1.1.7; (2) czy deployment używa konfiguracji/protokołu z advisory; (3) dokładna rola PostgreSQL (nie nazwa secreta czy parametr Terraform); (4) efektywne granty i membership, w tym dziedziczenie pg_execute_server_program; (5) behavioral verification — poprawiona wersja blokuje niebezpieczną konstrukcję, a rola i tak nie może uruchamiać programów. Najmocniejszy compensating control to ograniczenie praw roli — mierzalny i dobry dla VEX (warunkowe ograniczenie exploitability z konkretnych danych o roli, wygasające przy zmianie konfiguracji). Lifecycle: AFFECTED_CODE → ENVIRONMENT_MITIGATED → PATCH_APPLIED → REMEDIATION_VERIFIED.

Powiązane na blogu

mysql-mcp: komentarz omija read-only — ta sama klasa granicy capability
SQLChat: unauth database proxy — pivot do baz zamiast SSRF

Źródła

AWS Security Bulletin 2026-104-AWS — CVE-2026-87911 — aws.amazon.com

Nota redakcyjna: stan informacji 10 września 2026. CVE-2026-87911 (awslabs.postgres-mcp-server <1.1.7, fix 1.1.7): bypass read-only + COPY ... TO PROGRAM przy uprzywilejowanej roli PostgreSQL. Brak potwierdzenia active exploitation. Artykuł podkreśla least privilege jako mierzalną granicę i rozróżnienie patch applied vs remediation verified.