Actualizarea PostgreSQL cu 52 de CVE-uri e un proiect de upgrade, nu un simplu patch. Iar PostgreSQL 14 s-a încheiat

Pe 12 noiembrie, proiectul PostgreSQL a lansat versiunile minore 18.7, 17.12, 16.16, 15.20 și 14.25, plus a doua versiune release candidate pentru PostgreSQL 19. Împreună, acestea închid 52 de CVE-uri și corectează peste 140 de bug-uri. Pentru o versiune de tip point release, e un număr mare, iar aceasta cere de la tine mai mult decât obișnuitul „actualizezi pachetul, repornești și gata”.

Două lucruri fac runda aceasta diferită. PostgreSQL 14.25 este ultima versiune din ramura 14, deci 14 a ajuns la sfârșitul suportului (end-of-life) și nu mai primește corecții de securitate sau de bug-uri. Iar remedierea pentru bug-ul principal, CVE-2026-6460, schimbă modul în care serverul comunică cu extensiile. Astfel, un patch de rutină devine un upgrade coordonat de server și extensii, urmat de reindexări și de resetarea backup-urilor.

Ce este CVE-2026-6460

Este o confuzie de tip ce poate fi declanșată după ALTER ... SET DATA TYPE. Un utilizator care are voie să creeze obiecte o poate folosi pentru a rula cod arbitrar caGontul de sistem de operare sub care rulează baza de date. Avizul oficial îi acordă 8,8 în CVSS 3.1: exploatabil prin rețea, complexitate redusă, privilegii reduse, fără interacțiunea utilizatorului. Sunt afectate toate versiunile anterioare lui 18.7, 17.12, 16.16, 15.20 și 14.25.

„Necesită drepturi de creare a obiectelor” sună a precondiție confortabilă. Nu cred că este. În testele noastre de penetrare, configurația cea mai des întâlnită este un rol de aplicație care deține propria schemă. Migrările rulează ca acel rol, aplicația se conectează ca acel rol, deci contul în care ajunge un SQL injection poate de obicei crea tabele. Exact acesta este profilul de atacator de care are nevoie acest CVE.

Raza de impact este partea care mă îngrijorează. Pe un Postgres autogăzduit, utilizatorul de sistem care rulează serverul poate citi tot directorul de date, adică toate bazele de date din cluster, nu doar cea folosită de aplicația compromisă. În configurațiile Docker vede adesea și secretele montate în container.

Capcana extensiilor

Remedierea atinge elemente interne față de care se compilează extensiile. DatumGetHeapTupleHeader() a trecut de la macro la o funcție reală a serverului, iar heap_getattr() apelează acum heap_datum_check(). Din acest motiv, împachetatorii PGDG au reconstruit toate extensiile pentru noile versiuni minore, iar recomandarea lor este să actualizezi serverul și extensiile împreună.

Din experiența noastră cu PHP și Docker, aici apar problemele. Cineva fixează imaginea de bază Postgres la un tag nou, dar pachetele de extensii sunt instalate într-un strat separat, cu versiuni fixate propriu, sau invers. Actualizează-le pe ambele în aceeași modificare, reconstruiește imaginea și testeaz-o înainte să ajungă în producție. Dacă îți compilezi singur extensiile din sursă, reconstruiește-le cu noile headere. O versiune minoră nu cere de obicei asta.

Munca de după upgrade

Anunțul de lansare enumeră mai multe corecții de bug-uri care ajută doar după ce reconstruiești anumite lucruri:

• Indexurile GIN despre care bănuiești că sunt corupte trebuie reindexate.
• Indexurile GiST pg_trgm create cu gist_trgm_ops trebuie reindexate.
• Indexurile B-tree pe coloane bpchar declarate fără lungime trebuie reindexate.
• Orice tabel care aruncă erori „missing chunk number” are nevoie de REINDEX TABLE.
• Dacă folosești backup-uri incrementale, fă un backup complet nou și bazează toate incrementalele următoare pe el. Mai multe dintre bug-urile corectate puteau produce incrementale corupte.

Pentru a găsi rapid indexurile trigram:

SELECT i.indexrelid::regclass AS index_name
FROM pg_index i
JOIN pg_opclass o ON o.oid = ANY (i.indclass::oid[])
WHERE o.opcname = 'gist_trgm_ops';

Dacă faci un singur punct din listă, fă backup-ul. Un incremental corupt nu dă niciun semn până în ziua în care restaurezi din el, iar atunci e cel mai prost moment să afli. Reindexarea tabelelor mari consumă timp și I/O, așa că programeaz-o într-o fereastră liniștită. Nu o lipi pur și simplu la finalul rulării patch-ului.

Actualizează și uneltele client

Serverul nu e singurul lucru care trebuie reparat. CVE-2026-116318 este un SQL injection în pg_dump prin numele constrângerilor not-null, iar CVE-2026-116330 privește scriptul de restaurare în format tar, care nu blochează injecția de comenzi psql. Anunțul mai listează CVE-2026-116314, execuție de cod arbitrar în pg_restore (CVSS 8,8), și CVE-2026-116313, unde vacuumdb --missing-stats-only permite proprietarului unei baze de date să ruleze cod ca persoana care rulează vacuumdb (CVSS 7,2). Dacă altcineva poate crea și denumi obiecte în bazele tale de date, actualizează uneltele client odată cu serverul.

Gândește-te unde rulează de fapt aceste unelte: containere cron de backup, runnere CI, laptopul de ops folosit pentru restaurări ad-hoc. Când construim aplicații cloud-native pentru clienți enterprise, sidecar-ul de backup este aproape întotdeauna cea mai neglijată imagine din stack, fixată la versiunea de client curentă când cineva a scris prima dată jobul cron. Și rulează cu credențiale ample.

Pe un serviciu gestionat, verifică ce a implementat furnizorul. Chiar dacă serverul e în grija lui, uneltele client, reindexarea și lanțul de backup pot rămâne în sarcina ta.

PostgreSQL 14 s-a terminat

14.25 este ultimul patch pe care îl va primi ramura 14. Dacă ești încă pe ea, aplică 14.25 acum și începe să planifici upgrade-ul major în acest trimestru. Nu-l lăsa pentru anul viitor. Pentru clienții noștri enterprise din Elveția, cu cerințe de conformitate, o versiune de bază de date fără suport este, în sine, o constatare de audit, indiferent dacă a exploatat cineva ceva.

14 persistă cel mai des în spatele aplicațiilor mobile. În proiectele noastre native iOS și Android pentru clienți din sănătate și IoT, aplicațiile se livrează la câteva săptămâni, în timp ce baza de date a API-ului a fost configurată o dată, acum ani, și nimeni nu s-a mai atins de ea pentru că „merge și așa”. Dacă îți descrie backend-ul, acesta e impulsul de a-l repara. Țintește 18, cea mai nouă ramură stabilă. 19 este încă release candidate și îi e locul într-un mediu de staging, nu în spatele utilizatorilor tăi. Am făcut astfel de migrări în munca noastră de dezvoltare, iar upgrade-ul bazei de date în sine rareori e partea grea. Greu e să găsești fiecare serviciu care se conectează la ea.

Ce am face săptămâna aceasta

1. Inventariază fiecare instanță Postgres și versiunea ei, inclusiv cele uitate din staging și CI.
2. Actualizează serverul și extensiile împreună la 18.7, 17.12, 16.16, 15.20 sau 14.25.
3. Actualizează pg_dump, pg_restore și vacuumdb oriunde rulează.
4. Fă un backup complet nou dacă folosești incrementale.
5. Reindexează indexurile GIN, GiST trigram și B-tree bpchar afectate.
6. Verifică ce roluri pot crea obiecte și retrage acest drept oricărui rol de aplicație care nu îl necesită.
7. Pune în calendar o dată pentru părăsirea PostgreSQL 14.

Dacă un cluster PostgreSQL 14 pe care nu vrea nimeni să-l preia ți se pare cunoscut, hai să vorbim.