PostgreSQL CVE-2026-6460: databasanvändare som kan skapa objekt kan köra kod på servern

Vad hände

Den 12 november 2026 släppte PostgreSQL Global Development Group PostgreSQL 18.7, 17.12, 16.16, 15.20 och 14.25. Enligt The Hacker News åtgärdar de här utgåvorna 52 säkerhetsbrister. Den allvarligaste är CVE-2026-6460 (CVSS 8.8), en typförväxlingsbrist i kärnservern.

En databasanvändare som kan skapa objekt kan använda ALTER ... SET DATA TYPE för att få servern att läsa ett föråldrat värde som om det hade en ny typ. Andra DDL-satser kan göra detsamma, till exempel ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN. Det gör att användaren kan köra godtycklig kod som operativsystemsanvändaren som kör PostgreSQL. Rättningen lägger till versionskontroller så att servern kan upptäcka värden som inte längre matchar sin typ.

Säkerhetsforskaren Mehmet Ince har publicerat en teknisk genomgång med en fungerande exploit, som han demonstrerade på PostgreSQL 18.6. Genomgången innehåller SQL-koden som kraschar en server utan uppdatering, samt ett steg som läcker minnesadresser. Den innehåller inte det sista steget som kör ett kommando. Han skrev att han kunde utlösa kraschen med en inloggningsroll med lägst behörighet. Källorna säger inte om ett konto med enbart standardbehörigheter kan gå längre och köra kod. Red Hat säger att en angripare behöver en databasinloggning som kan skapa eller ändra objekt.

PostgreSQL-projektet har inte rapporterat några attacker som använder bristen, och CISA listar den inte som utnyttjad.

De här utgåvorna åtgärdar även andra brister, bland dem CVE-2026-116322, som låter en klient utan autentisering tvinga PostgreSQL 18-servrar att starta om. De rättar också brister i klientverktygen: ett manipulerat arkiv kan få pg_restore att köra kod som användaren som kör det, och en komprometterad källserver kan få psql att köra kod via återställningsskriptet i pg_dumps tar-utdata.

Vem som påverkas

• PostgreSQL 18 före 18.7, 17 före 17.12, 16 före 16.16, 15 före 15.20 och 14 före 14.25.
• Äldre huvudversioner påverkas också och kommer inte att få någon uppdatering. PostgreSQL 14 är nu uttjänt, och 14.25 är dess sista utgåva.
• Risken är störst på servrar där personer som du inte helt litar på har en databasinloggning som kan skapa eller ändra objekt. Det gäller delad webbhotell, databaser som lämnas till kunder och webbapplikationer vars databaskonto äger sitt schema. Om en angripare tar över en sådan applikation, till exempel genom SQL-injektion, kan de kanske använda applikationens databaskonto på det här sättet.
• Hanterade tjänster: forskaren delade bevis-koncept med AWS (RDS, Aurora), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks och Ubicloud. Deras aktuella status för uppdateringar är inte känd. Kontrollera din leverantörs meddelanden.
• Servrar som inte kör PostgreSQL påverkas inte. MySQL och MariaDB påverkas inte.

Vad du ska göra nu

1. Säkerhetskopiera din PostgreSQL-konfiguration (till exempel postgresql.conf och pg_hba.conf) och se till att du har en aktuell databasbackup.
2. Uppdatera servern till den rättade utgåvan för din huvudversion: 18.7, 17.12, 16.16, 15.20 eller 14.25. Om du använder paket från din distribution (Debian, Ubuntu, RHEL och liknande) installerar du de rättade paketen som listas i distributionens säkerhetsmeddelande så snart de finns tillgängliga. Använd sedan pakethanteraren som vanligt (apt update && apt upgrade eller dnf upgrade).
3. Uppdatera eller bygg om varje C-tillägg samtidigt som servern. Projektets RPM-underhållare varnar för att tillägg som byggts mot äldre utgåvor fortfarande laddas men kanske inte är skyddade. Vissa tillägg kräver också ändringar i källkoden. Tilläggspaket i PostgreSQL:s RPM-förråd kräver nu den nya mindre utgåvan.
4. Starta om PostgreSQL. Om den körs utanför sin pakets egen tjänstfil, till exempel under Patroni, starta om den manuellt direkt efter uppdateringen.
5. Följ omindexeringsstegen i den officiella utgåvsannonseringen. Om du använder inkrementella backuper tar du en ny fullbackup och baserar framtida inkrementella backuper på den.
6. Uppdatera klientverktyg som pg_dump, pg_restore, psql, reindexdb och vacuumdb på varje dator som använder dem, inklusive backupvärdar och administratörsarbetsstationer.
7. Använd inte den nya inställningen composite_type_mismatch för att stänga av de nya kontrollerna. Projektet säger att det medför säkerhetsrisker.
8. Om du inte kan uppdatera direkt bör du komma ihåg att projektet inte erbjuder någon tillfällig lösning. Tills du kan uppdatera bör du granska vilka konton som kan skapa eller ändra objekt, särskilt konton som används av webbapplikationer eller lämnats till kunder, och se till att PostgreSQL inte är nåbart från internet om det inte behövs.
9. Om du fortfarande kör PostgreSQL 14 eller en äldre version bör du planera en uppgradering till en version som stöds.

Så kontrollerar du om du påverkas

• Kontrollera den körande serverversionen med psql -c 'SELECT version();' eller SHOW server_version;. Versioner under 18.7, 17.12, 16.16, 15.20 eller 14.25 inom sin huvudserie påverkas.
• Kontrollera de installerade binärfilerna och paketen med postgres -V, dpkg -l | grep postgresql eller rpm -qa | grep postgresql. Starta om servern om den körande versionen är äldre än den installerade.
• Lista installerade tillägg med SELECT extname, extversion FROM pg_extension; i varje databas. Se till att varje C-tillägg har uppdaterats eller byggts om för den nya utgåvan.
• Kontrollera PostgreSQL-loggarna för oväntade krascher i serverprocesser, till exempel processer som avslutats av en signal. Den publicerade exploiten kraschar servrar utan uppdatering, så krascher av det här slaget är värda en närmare titt.

Källor

• https://nvd.nist.gov/vuln/detail/CVE-2026-6460
• https://www.postgresql.org/support/security/CVE-2026-6460/