PostgreSQL heeft updates uitgebracht om een beveiligingsprobleem op te lossen waardoor een account met het REPLICATION-attribuut willekeurige code kan uitvoeren als de gebruiker van het besturingssysteem die de databaseserver beheert.
De fout, bijgehouden als CVE-2026-6471 (CVSS-score: 7.2), is aanwezig sinds de introductie van logische decodering in PostgreSQL 9.4 in 2014. Versies vóór PostgreSQL 18.6, 17.11, 16.15, 15.19 en 14.24 worden beïnvloed.
Exploitatie vereist een account met het REPLICATION-attribuut en een server met wal_level = logisch. Back-uptools, standby-servers, pijplijnen voor het vastleggen van wijzigingsdata (CDC) en monitoringsystemen beschikken routinematig over dit kenmerk.
De oplossing, die op 13 augustus werd uitgebracht, voegt een serverparameter toe met de naam output_plugin_libraries, die aangeeft welke bibliotheken kunnen worden geladen als uitvoerplug-ins voor logische decodering, standaard ingesteld op ‘pgoutput, test_decoding’.
Installaties met behulp van een andere uitvoerplug-in, wal2json en decoderbufs
onder hen zal logische decodering worden geweigerd na het updaten totdat een beheerder de bibliotheek aan die lijst toevoegt en de serverconfiguratie opnieuw laadt.
“Voorheen kon een replicatiegebruiker elke laadbare bibliotheek selecteren voor logische decodering, waardoor allerlei soorten exploits mogelijk waren. Om dit te kunnen vergrendelen zonder de instellingen die eerder werkten te verbreken, introduceert u een witte lijst met toegestane uitvoerplug-ins”, aldus de PostgreSQL Global Development Group in de release-opmerkingen van 18.6.
Het PostgreSQL-project gaf Vladimir Tokarev en Yu Kunpeng de eer om het probleem te melden.
Tokarev heeft dit gedetailleerd beschreven in een artikel van 1 september voor gegevensbeveiligingsbedrijf Cyera Research, waarin de fout wordt genoemd PostGRESell.
De plug-innaam die wordt opgegeven in een CREATE_REPLICATION_SLOT-opdracht wordt rechtstreeks doorgegeven aan de functie die de bibliotheek laadt, zei Cyera.
De bestaande beperking van PostgreSQL op plug-inpaden, die niet-supergebruikers beperkt tot een enkele door de beheerder beheerde directory, wordt nooit aangeroepen op het replicatiepad. De parser van het replicatieprotocol accepteert vrijwel elk teken binnen een plug-innaam tussen dubbele aanhalingstekens, inclusief padscheidingstekens en ../ traversal, zodat een volledig bestandssysteempad de lader bereikt zoals getypt.
Op Windows lost de server een netwerkpad op via Server Message Block (SMB) en haalt de bibliotheek op van een machine die de aanvaller bestuurt, zonder iets naar het doel te schrijven, zei Cyera.
Op Linux en macOS vereist hetzelfde resultaat het inschakelen van automatische activering van Network File System (NFS). Overal elders heeft de aanvaller een bestaande manier nodig om een bestand naar de schijf van de server te schrijven. Code die op deze manier wordt geladen, wordt in het backend-proces van de database uitgevoerd als gebruiker van het postgres-besturingssysteem.
De testplug-in van Cyera schreef vervolgens de rollencatalogus rechtstreeks om van het replicatieaccount een PostgreSQL-superuser te maken. Het heeft ook drie persistentiemechanismen opgezet die een herstart van de server overleven.
Cyera beschrijft het REPLICATION-attribuut als een back-upreferentie met weinig bevoegdheden, maar PostgreSQL scoorde de fout door Privileges Required op Hoog te zetten, een beoordeling die in SUSE’s eigen beoordeling werd herhaald.
PostgreSQL weigerde de bestaande LOAD-beperking op het replicatiepad toe te passen.
“REPLICATION-gebruikers waren voorheen niet onderworpen aan beperkingen op de paden van uitvoerplug-ins, dus konden ze de LOAD-time-beveiligingen tijdens logische decodering omzeilen. Helaas zou het toevoegen van de standaard LOAD-beperkingen nu met terugwerkende kracht vereisen dat alle uitvoerplug-ins van derden worden geïnstalleerd onder de map $libdir/plugins”, zei Jacob Champion, die de oplossing schreef, in het commit-bericht.
Mislukte laadacties verschijnen in het serverlogboek als ERROR: bibliotheek “…” mag niet worden gebruikt als uitvoerplug-in, met een hint die de instelling een naam geeft, volgens de documentatie van de parameter.
Beheerders wordt geadviseerd de volgende stappen te ondernemen:
- Voer de SELECT DISTINCT-plug-in uit VAN pg_replication_slots WAAR de plug-in NIET NULL IS; voordat u de update uitvoert om de gebruikte uitvoerplug-ins te identificeren, waardoor alleen plug-ins worden weergegeven die op een bepaald moment met succes zijn gebruikt.
- Update naar 18.6, 17.11, 16.15, 15.19 of 14.24, of naar het equivalente distributiepakket.
- Voeg een niet-standaard plug-in toe aan output_plugin_libraries en laad de configuratie opnieuw met pg_ctl reload of SELECT pg_reload_conf(). Een herstart is niet vereist.
- Stel de output_plugin_libraries van het nieuwe cluster in voordat u pg_upgrade –check uitvoert wanneer u migreert vanaf versie 17 of hoger, omdat de controle mislukt als de lijst de slotplug-ins van het oude cluster niet toestaat.
Vaste pakketten zijn beschikbaar op Amazon RDS voor alle vijf branches, evenals voor Debian, SUSE en Ubuntu.
Het advies van PostgreSQL heeft betrekking op ondersteunde branches 14 tot en met 18 en gaat niet in op eerdere branches. PostgreSQL 14 ontvangt op 12 november 2026 geen oplossingen meer, aldus het project in de release-aankondiging.
De upstream-fix “vereist aanvullende wijzigingen aan de configuratie als sommige extensies worden gebruikt”, waarschuwt Debian’s advies, waarbij de pakketten wal2json en decoderbufs worden genoemd.
Ubuntu’s USN-8653-1, die op 20 augustus de oplossing voor 22.04, 24.04 en 26.04 LTS heeft verzonden, maakt geen melding van de parameter en vertelt beheerders dat ze PostgreSQL alleen opnieuw moeten opstarten na de update.
Vanaf 4 september had het wal2json-project zijn documentatie bijgewerkt om gebruikers te vertellen de plug-in toe te voegen aan output_plugin_libraries, onder verwijzing naar de CVE.
Er is nog een gat in de oplossing open. pg_createsubscriber maakt replicatieslots aan met behulp van pgoutput zonder de nieuwe parameter te controleren, zodat een –dry-run slaagt en de conversie vervolgens mislukt.
“De opdracht pg_createsubscriber creëert replicatieslots met plug-in ‘pgoutput’, zonder de GUC te controleren. Dit betekent dat als de naam van de plug-in niet in de parameter is gespecificeerd, de –dry-run-modus slaagt maar de daadwerkelijke conversie mislukt. Het is zeer verrassend voor gebruikers en moet worden vermeden, “zei Hayato Kuroda van Fujitsu in een bericht aan de pgsql-hackers-mailinglijst.
Een patch werd beoordeeld en was op 4 september nog niet doorgevoerd. CVE-2026-6471 bleef vanaf 4 september afwezig in de Known Exploited Vulnerabilities (KEV)-catalogus van CISA.
The Hacker News vond er op dezelfde datum geen proof-of-concept-code voor in openbare opslagplaatsen.
Totdat de update kan worden toegepast, kan de blootstelling volgens Cyera worden verminderd door het REPLICATION-attribuut te verwijderen van accounts die het niet nodig hebben, replicatie-items in pg_hba.conf te beperken tot bekende adressen, uitgaand SMB- (poort 445) en NFS-verkeer (poort 2049) van databaseservers te blokkeren en autofs uit te schakelen waar dit niet nodig is.
