PostgreSQL CVE-2026-6460: databasegebruikers die objecten kunnen aanmaken, kunnen code op de server uitvoeren

Wat er is gebeurd

Op 12 november 2026 heeft de PostgreSQL Global Development Group PostgreSQL 18.7, 17.12, 16.16, 15.20 en 14.25 uitgebracht. Volgens The Hacker News verhelpen deze releases 52 beveiligingskwetsbaarheden. De ernstigste is CVE-2026-6460 (CVSS 8.8), een typeverwarringskwetsbaarheid in de kernserver.

Een databasegebruiker die objecten kan aanmaken, kan ALTER ... SET DATA TYPE gebruiken om de server een verouderde waarde te laten lezen alsof die een nieuw type heeft. Andere DDL-instructies kunnen hetzelfde, bijvoorbeeld ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN. Hierdoor kan de gebruiker willekeurige code uitvoeren als het besturingssysteemgebruikersaccount waaronder PostgreSQL draait. De oplossing voegt versiecontroles toe, zodat de server waarden kan herkennen die niet meer overeenkomen met hun type.

Beveiligingsonderzoeker Mehmet Ince heeft een technische beschrijving met een werkende exploit gepubliceerd, die hij heeft gedemonstreerd op PostgreSQL 18.6. De beschrijving bevat de SQL die een niet-gepatchte server laat crashen en een stap die geheugenadressen lekt. Ze bevat niet de laatste stap die een opdracht uitvoert. Hij schreef dat hij de crash kon veroorzaken met een login-rol met de laagste privileges. De bronnen vermelden niet of een account met alleen standaardrechten verder kan gaan en code kan uitvoeren. Red Hat stelt dat een aanvaller een databaselogin nodig heeft die objecten kan aanmaken of wijzigen.

Het PostgreSQL-project heeft geen aanvallen gemeld waarbij deze kwetsbaarheid is gebruikt, en CISA vermeldt haar niet als actief misbruikt.

De-zelfde releases verhelpen andere kwetsbaarheden, waaronder CVE-2026-116322, waarmee een niet-geauthenticeerde client PostgreSQL 18-servers kan dwingen opnieuw op te starten. Ook worden kwetsbaarheden in clienttools verholpen: een gemanipuleerd archief kan ervoor zorgen dat pg_restore code uitvoert als de gebruiker die het draait, en een gecompromitteerde bronserver kan ervoor zorgen dat psql code uitvoert via het herstelscript in de tar-uitvoer van pg_dump.

Wie is getroffen

• PostgreSQL 18 voor 18.7, 17 voor 17.12, 16 voor 16.16, 15 voor 15.20 en 14 voor 14.25.
• Oudere hoofdversies zijn ook getroffen en krijgen geen update. PostgreSQL 14 is nu end of life, en 14.25 is de laatste release.
• Het risico is het grootst op servers waar mensen die u niet volledig vertrouwt een databaselogin hebben die objecten kan aanmaken of wijzigen. Dit geldt voor shared hosting, databases die aan klanten worden overgedragen en webapplicaties waarvan het databaseaccount het schema bezit. Als een aanvaller zo'n applicatie overneemt, bijvoorbeeld via SQL-injectie, kan hij mogelijk dit databaseaccount op deze manier gebruiken.
• Beheerde diensten: de onderzoeker heeft proofs of concept gedeeld met AWS (RDS, Aurora), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks en Ubicloud. Hun huidige patchstatus is niet bekend. Controleer de meldingen van uw provider.
• Servers die geen PostgreSQL draaien, zijn niet getroffen. MySQL en MariaDB zijn niet getroffen.

Wat u nu moet doen

1. Maak een back-up van uw PostgreSQL-configuratie (bijvoorbeeld postgresql.conf en pg_hba.conf) en zorg dat u een actuele databaseback-up heeft.
2. Werk de server bij naar de verholpen release voor uw hoofdversie: 18.7, 17.12, 16.16, 15.20 of 14.25. Als u pakketten van uw distributie gebruikt (Debian, Ubuntu, RHEL en afgeleiden), installeer dan de verholpen pakketten die in de advisory van uw distributie staan zodra ze beschikbaar zijn. Gebruik daarna de pakketbeheerder zoals gebruikelijk (apt update && apt upgrade of dnf upgrade).
3. Werk elke C-extensie bij of bouw deze opnieuw, tegelijk met de server. De RPM-beheerders van het project waarschuwen dat extensies die tegen oudere releases zijn gebouwd nog wel laden, maar mogelijk niet beschermd zijn. Sommige extensies vereisen ook wijzigingen in de broncode. Extensiepakketten in de PostgreSQL RPM-repositories vereisen nu de nieuwe minor release.
4. Start PostgreSQL opnieuw. Als het draait buiten de eigen serviceunit van het pakket, bijvoorbeeld onder Patroni, start het dan direct na de update handmatig opnieuw.
5. Volg de stappen voor het herindexeren in de officiële releasemelding. Als u incrementele back-ups gebruikt, maak dan een nieuwe volledige back-up en baseer toekomstige incrementele back-ups daarop.
6. Werk clienttools zoals pg_dump, pg_restore, psql, reindexdb en vacuumdb bij op elke machine die ze gebruikt, inclusief back-uphosts en beheerwerkstations.
7. Gebruik de nieuwe instelling composite_type_mismatch niet om de nieuwe controles uit te schakelen. Het project stelt dat dit beveiligingsrisico's met zich meebrengt.
8. Als u niet meteen kunt updaten, houd er dan rekening mee dat het project geen tijdelijke oplossing biedt. Controleer totdat u kunt updaten welke accounts objecten kunnen aanmaken of wijzigen, vooral accounts die door webapplicaties worden gebruikt of aan klanten zijn gegeven, en zorg dat PostgreSQL niet vanaf internet bereikbaar is tenzij dat nodig is.
9. Als u nog PostgreSQL 14 of een oudere versie draait, plan dan een upgrade naar een ondersteunde hoofdversie.

Hoe u controleert of u getroffen bent

• Controleer de versie van de draaiende server met psql -c 'SELECT version();' of SHOW server_version;. Versies onder 18.7, 17.12, 16.16, 15.20 of 14.25 binnen hun hoofdreeks zijn getroffen.
• Controleer de geinstalleerde binaries en pakketten met postgres -V, dpkg -l | grep postgresql of rpm -qa | grep postgresql. Start de server opnieuw als de draaiende versie ouder is dan de geinstalleerde versie.
• Maak een lijst van geinstalleerde extensies met SELECT extname, extversion FROM pg_extension; in elke database. Controleer of elke C-extensie is bijgewerkt of opnieuw gebouwd voor de nieuwe release.
• Controleer de PostgreSQL-logs op onverwachte crashes van backend-processen, zoals serverprocessen die door een signaal zijn beeindigd. De gepubliceerde exploit laat niet-gepatchte servers crashen, dus dergelijke crashes verdienen nader onderzoek.

Bronnen

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