Un cont de backup PostgreSQL poate acum executa cod pe serverul tău. Aplică patch-ul CVE-2026-6471.

Postgres a lansat un patch pe 13 august pentru o vulnerabilitate prezentă în cod din 2014. CVE-2026-6471 permite oricărui cont cu atributul REPLICATION — tipul de cont cu privilegii reduse pe care îl folosește instrumentul de backup sau replica de citire — să încarce o bibliotecă partajată arbitrară în procesul bazei de date și să execute cod ca utilizatorul sistemului de operare care deține Postgres. Advisory-ul oficial descrie situația direct: decodarea logică poate face dlopen pe un fișier arbitrar, ales de clientul de replicare, fără niciun control de autorizare. Cyera Research, care l-a raportat alături de Yu Kunpeng, îl numește PostGREShell.

Mecanica merită înțeleasă, deoarece explică și patch-ul. Când un client de replicare deschide un slot de decodare logică, specifică un plugin de ieșire, iar Postgres îl încarcă ca cod compilat în propriul proces. Pentru un SQL LOAD obișnuit, Postgres restricționează utilizatorii non-superadmin la un director controlat de plugin-uri. Calea de replicare a omis această verificare, astfel încât numele plugin-ului putea fi orice cale de pe disc. Pe Windows situația se agravează: loader-ul acceptă o cale UNC, deci un atacator îl poate direcționa spre un DLL de pe propriul share SMB, fără a trebui să depoziteze mai întâi un fișier pe țintă.

Iată ce s-a pierdut în unele dintre acoperirile media. CVSS-ul oficial este 7.2, ridicat dar nu critic, iar motivul stă chiar în vector: PR:H. Ai nevoie de un cont care deține deja REPLICATION. Nu este o gaură neautentificată expusă pe internet. Atunci de ce contează? Pentru că în sistemele reale acele conturi sunt peste tot și nimeni nu le tratează ca periculoase. Fiecare replică de streaming, fiecare job de backup, fiecare pipeline de change-data-capture, fiecare agent de monitorizare care urmărește write-ahead log-ul rulează ca rol REPLICATION. Ele sunt instalația operațională, iar instalațiile tind să aibă credențiale slabe, cu durată lungă de viață, copiate pe scară largă.

În timpul auditurilor de securitate în cloud, găsim mereu același tipar: un utilizator de replicare ale cărui credențiale se regăsesc în trei fișiere env și o variabilă Terraform, reutilizate pe staging și prod, accesibile din mai multă rețea decât a intenționat cineva. Privit izolat, asta pare un finding de severitate scăzută — un cont de serviciu cu privilegii excesive. Acest CVE transformă exact acel cont în execuție de cod de la distanță pe gazda bazei de date. Lecția nu este de fapt despre Postgres. Este că credențialele de serviciu „cu privilegii reduse“ rămân cu privilegii reduse doar până când cineva găsește o primitivă care le actualizează.

Patch-ul este un nou parametru de server, output_plugin_libraries, adăugat de Jacob Champion. Este un allowlist. Implicit, permite doar cele două plugin-uri livrate cu Postgres, pgoutput și test_decoding, astfel încât un client de replicare nu mai poate specifica o bibliotecă arbitrară. Dacă folosești un decoder terț ca decoderbufs (utilizatori Debezium, asta înseamnă voi), trebuie să îl adaugi explicit după upgrade, altfel replicarea logică se oprește. Pe versiunea 17 și ulterior, pg_upgrade --check refuză să continue dacă allowlist-ul noului cluster nu acoperă plugin-urile pe care le folosesc slot-urile existente. Este o barieră de protecție utilă și un aspect de migrare de planificat.

Ce să faci săptămâna aceasta

1. Aplică patch la 18.6, 17.11, 16.15, 15.19 sau 14.24. Ramurile mai vechi au depășit end-of-life și nu vor primi acest fix, deci dacă ești pe 13 sau mai vechi, tratează-l ca un motiv în plus să migrezi.
2. Auditează cine deține REPLICATION. Fă un inventar real, nu un calcul aproximativ. Orice cont de utilizator uman cu atributul ar trebui probabil să îl piardă, iar fiecare cont de serviciu care îl păstrează are nevoie de un secret unic, schimbat.
3. Blochează SMB și NFS de ieșire de la gazdele bazei tale de date. Calea DLL-ului de la distanță pe Windows depinde de baza de date care ajunge la share-ul de fișiere al atacatorului. Serverul tău Postgres nu are niciun motiv să deschidă conexiuni SMB de ieșire, deci elimină-le de la firewall.
4. Dacă setezi output_plugin_libraries manual, enumeră exact decoderele pe care le folosești și nimic altceva.

Un lucru merită verificat, iar altul ignorat. Vânătoarea de amenințări Cyera a descoperit 114 plugin-uri Postgres malițioase pe VirusTotal: trojani, mineri, shell-uri inverse. Asta amintește că încărcarea plugin-urilor este o țintă populară, dar niciunul dintre acele exemple nu a fost legat de exploatarea acestui CVE specific, deci nu îl interpreta ca dovadă că ai fost afectat. Merită ignorat: formularea „doisprezece ani necorectat“. Vulnerabilitatea a existat o perioadă lungă de timp, dar exploatarea ei necesită în continuare un cont REPLICATION, iar dacă ai ținut acele conturi blocate nu ai fost niciodată atât de expus cum sugerează titlul.

Petrecem destul timp acolo unde întărirea bazelor de date se intersectează cu politica de rețea, de la stive PHP și Docker pe AWS la regulile Cloudflare și firewall care decid ce poate atinge o mașină compromisă. Tiparul care prinde echipele nepregătite este aproape întotdeauna un cont intern prea de încredere plus egress pe care nimeni nu l-a blocat. Dacă o credențială de replicare uitată cu o parolă partajată sună ca ceva din infrastructura ta, haideți să vorbim.