PostgreSQL wordt al sinds 2014 in veel organisaties gebruikt, maar er is nu een kwetsbaarheid aan het licht gekomen die een database- en serverovername mogelijk maakt. De naam die daarbij valt is PostGREShell (CVE-2026-6471), een beveiligingslek dat aanvallers met relatief lage rechten kan helpen om alsnog in hoogprivilegde rollen te komen.
Wat het extra riskant maakt: het gaat niet om een willekeurige “fout” in een exotische component, maar om een misbruikroute binnen de manier waarop PostgreSQL logische replicatie verwerkt. Daardoor kan het traject richting remote code execution (RCE), privilege-escalatie en zelfs een persistente backdoor lopen.
Wat is PostGREShell (CVE-2026-6471)?
Cyera rapporteert dat PostgreSQL-releases sinds 2014 een ernstig probleem bevatten dat een database server takeover kan faciliteren. De kwetsbaarheid is geregistreerd als CVE-2026-6471 en heeft een CVSS-score van 7,2.
PostGREShell wordt gekoppeld aan missing authorization in het gedeelte van PostgreSQL dat logical decoding afhandelt. Met andere woorden: er ontbreekt een effectieve controle op het laden en verwerken van een component die normaal bedoeld is voor replicatiefunctionaliteit.
De kans op misbruik ontstaat vooral wanneer een aanvaller kan beschikken over een account met het Replication-privilege. Dat recht is volgens de melding gebruikelijk bij tooling rondom backup, pipelines en monitoring, omdat PostgreSQL een replicatieprotocol inzet om wijzigingen te synchroniseren tussen primaire databases en replica’s.
Hoe werkt logical decoding misbruik precies?
PostgreSQL verwerkt replicatiegebeurtenissen als table events. Externe tools lezen die veranderingen door een logical replication slot aan te maken. Vervolgens noemen ze een output plugin die PostgreSQL laadt om de replicatiestroom te formatteren.
Het cruciale punt is dat wanneer zo’n plugin geladen wordt, PostgreSQL de init-function van die plugin start met de privileges van het postgres serverproces. Voor misbruik zijn er normaal beperkingen: niet-superusers mogen plugins alleen laden vanuit een door een beheerder aangewezen directory.
Maar in PostGREShell gaat het mis doordat de pluginnaam rechtstreeks naar de loader wordt doorgegeven, zonder voldoende validatie of sanitization. Daardoor kan een aanvaller een naam aanleveren die feitelijk een pad bevat, inclusief omleidingen en bestandslocaties.
Van pluginnaam naar pad naar dlopen
Cyera beschrijft dat de parser van het logical replication pad vrijwel elke tekens kan accepteren binnen een dubbel-gequote pluginnaam. Dat maakt constructies mogelijk die lijken op pad-traversal, maar ook varianten zoals slashes, backslashes, dots en zelfs UNC-paths (Windows-stijl netwerkpaden).
Het gevolg is dat de loader uiteindelijk een volledig filesystem pad kan krijgen dat via dlopen() wordt geladen—een C/C++ functie waarmee gedeelde libraries dynamisch worden ingeladen.
Omdat dlopen het procesgedeelte binnen de context van PostgreSQL uitvoert, draait de code in dezelfde address space als de database, zonder sandbox en zonder extra checks op interne API-aanroepen. PostgreSQL vertrouwt dus op geladen code, waardoor de aanvaller feitelijk controle krijgt.
Van RCE naar superuser en persistente toegang
Volgens de beschrijving kan de geladen code een interne functie aanroepen om in de sessie bootstrap superuser te worden. Daarna schrijft de aanvaller direct naar de catalogtabel pg_authid, waarin wordt vastgelegd wie superuser is, en zet vervolgens de relevante privileges op true.
Na die stap heeft de aanvaller permanente superuser-rechten. Dat betekent dat de impact veel verder gaat dan alleen het uitvoeren van commando’s: de aanvaller kan in feite elke tabel in elke database benaderen, OS-commando’s uitvoeren, private keys uitlezen en bestanden schrijven op locaties waar het postgres-proces toegang toe heeft.
Daarnaast is er melding van mogelijkheden voor backdoor-gedrag. De plugin kan bijvoorbeeld verbindingen zonder wachtwoorden mogelijk maken, zichzelf naar een stabiele locatie kopiëren en zich laten herladen in elke nieuwe backend. Zelfs als de superuser-wijziging wordt teruggedraaid, zou de wijziging opnieuw kunnen worden toegepast.
Welke PostgreSQL-versies zijn getroffen?
Cyera stelt dat alle versies van 9.4 tot en met 18 worden geraakt. De onderzoekers bevestigden de werking op versie 18.2.
Het is ook een belangrijke context dat logical replication inmiddels “standaard” is in productieomgevingen: het gevolg is dat de kwetsbare route waarschijnlijk in veel PostgreSQL-instellingen aanwezig is.
Wat kunt u nu doen? (update en audit)
Er zijn patches beschikbaar voor verschillende PostgreSQL-releases. De melding noemt de volgende versies waarin de kwetsbaarheid is verholpen: 18.6, 17.11, 16.15, 15.19 en 14.24.
Het advies is om uw PostgreSQL-instanties zo snel mogelijk te updaten. Daarnaast is het belangrijk om de Replication accounts te auditen: verwijder het Replication-attribuut bij accounts die het niet echt nodig hebben.
Praktische controles die direct helpen
- Inventariseer welke databaseaccounts Replication-privileges hebben (inclusief accounts die door tools, pipelines of monitoring gebruikt worden).
- Beperk waar mogelijk: geef alleen aan wie het echt nodig heeft toegang tot replicatie.
- Controleer of logical replication en bijbehorende pluginmechnismen nog actueel zijn in uw omgeving (backup, monitoring, replicatie-opzet).
- Voer na patchen een extra controle uit op afwijkend gedrag rond superuserrechten en onverwachte configuratiewijzigingen.
Als u een herstelplan heeft, combineer dat met logging- en monitoringafspraken. Zo ziet u sneller wanneer er geprobeerd wordt om replicatiecomponenten te misbruiken, ook als de eerste stap (het verkregen replication-recht) al via “normaal” gebruik binnenkomt.
Waarom dit ook een supply chain- en tooling-probleem kan zijn
PostGREShell richt zich niet op het “hardware”-niveau of een browsercomponent, maar op het vertrouwen tussen database, replicatiefeatures en de tooling die daarmee communiceert. Juist daarom voelt dit voor veel organisaties als een groter ketenrisico: een account met Replication-rechten kan via misbruik van logical decoding uitgroeien tot iets dat beheerderstoegang benadert.
Heeft u meerdere systemen die verbinding maken (backups, event pipelines, monitoring), dan is het verstandig om het toegangsmoment en de reikwijdte van credentials opnieuw te bekijken. Een kleine privilegefout in een systeem dat “alleen maar leest” kan anders doorslaan naar code-uitvoering en persistente toegang.
Meer context: vergelijkbare waarschuwingen over server-side misbruik
Als u de bredere lijn ziet, dan past PostGREShell in een reeks incidenten waarbij servers en applicatieonderdelen via hun eigen technische mogelijkheden worden misbruikt. Wilt u de aanpak van “risico blokkeren” in vergelijkbare ketensystemen verder doorgronden, dan kan dit artikel nuttig zijn:
Voor teams die juist met replicatie-, pipeline- of automation-accounts werken, helpt het om ook de werking van “veiligheid door beperking” te vertalen naar database- en toegangsmodellen.
Conclusie
PostGREShell (CVE-2026-6471) laat zien dat een kwetsbaarheid in logical decoding uit kan groeien tot remote code execution en superuser-toegang, met mogelijk persistente backdoor-mechanismen. Omdat alle versies van 9.4 tot en met 18 worden geraakt, is het voor veel organisaties relevant—even wanneer de database “prima” lijkt te draaien.
De kernmaatregelen zijn helder: update naar een gepatchte versie (zoals 18.6 of nieuwer waar van toepassing) en auditeer Replication-accounts. Daarmee verkleint u de kans dat een aanvaller via tooling-rechten alsnog de kwetsbare route benut.
Bron: https://www.securityweek.com/12-year-old-postgresql-vulnerability-enables-database-server-takeover/
