Restricted mode i Postgres MCP Pro lekker serverfiler, og det finnes ingen patch

CVE-2026-85620 ble publisert 4. september 2026 med CVSS v4.0-score 9,2 og rammer alle versjoner av Postgres MCP Pro til og med 0.3.0. Ifølge Forkast, som omtalte saken, ligger feilen i en ufullstendig validering i pakkens SQL-sikkerhetslag: safe_sql.py sjekker funksjonsnavn mot en tillatelsesliste bare når funksjonen dukker opp som en FuncCall-node i syntakstreet.

Legger du funksjonen i en FROM-klausul i stedet, parses den som en RangeFunction-node, en type validatoren slipper gjennom uten å se på navnet i det hele tatt. SELECT pg_read_file('/etc/passwd') blir blokkert. SELECT * FROM pg_read_file('/etc/passwd') kjører og returnerer innholdet i fila.

Konsekvensen stopper ikke ved databasen. Enhver MCP-klient eller KI-agent som når det restriktive grensesnittet kan lese filer PostgreSQL-prosessen har tilgang til: systemkonfigurasjon, legitimasjon, TLS-nøkler. Det er en eskalering fra databasespørringer til filsystemet på verten, og den krever ingen autentisering mot selve restriksjonslogikken.

Bakgrunn

Postgres MCP Pro er Crystal DBAs åpne MCP-server som gir KI-agenter helsesjekker, indeksjustering og spørringskjøring mot PostgreSQL. Prosjektet har 3 268 stjerner på GitHub og er ingen kuriositet. Restricted mode er nettopp konfigurasjonen operatører får beskjed om å bruke i produksjon, alternativet til å sette opp en egen skrivebeskyttet databaserolle, og hele poenget med den er å gjøre agent-mot-database trygt uten ekstra oppsett. Sikkerhetsforskeren George Chen meldte feilen 6. juni 2026. IONIX Threat Center og VulnCheck klassifiserer den begge som CWE-863, feilaktig autorisasjon. Siste utgivelse er fortsatt 0.3.0, og fiksen ligger som en åpen pull request mot crystaldba/postgres-mcp.

Forkast peker på at samme uke ga to andre hull i KI-stakken: CVE-2026-82526, en kritisk SQL-injeksjon i hentingsrammeverket R2R, og CVE-2026-85695, en autentiseringsomgåelse i FastChats modellservering. Tre samtidige CVE-er i henting, servering og databasetilgang, alle offentliggjort i samme uke. Angrepsflaten er ikke modellen, men limet rundt den.

Mønsteret er verdt å ta inn over seg hvis du bygger agenter som snakker med data. Kontroller i applikasjonslaget, altså tillatelseslister, AST-parsere og skrivebeskyttede transaksjonsmodus, rulles ut som om de var sikkerhetsgrenser på databasenivå. Når håndhevingspunktet ligger i mellomvare som en angriper kan påvirke gjennom prompt-injeksjon eller konstruert SQL, kollapser tillitsmodellen ved første hull i parseren.

Hva bør du gjøre?

1. Ikke regn restricted mode som en sikkerhetsgrense mot SQL som er generert av en agent eller kommer fra en kilde du ikke kontrollerer.
2. Kjør MCP-serveren mot en PostgreSQL-rolle som mangler pg_read_server_files og andre filsystemrettigheter. Databasenivå, ikke applikasjonsnivå.
3. Overvåk loggene for pg_read_file, pg_ls_dir og pg_stat_file i FROM-klausuler, og begrens på nettverksnivå hvilke klienter og agenter som når MCP-serveren.