PostgreSQL'in ağustos sürümü: 28 CVE, pg_dump'ınızın da yamaya ihtiyacı var

13 Ağustos'ta PostgreSQL Global Development Group, PostgreSQL 19'un üçüncü betasıyla birlikte 18.6, 17.11, 16.15, 15.19 ve 14.24 sürümlerini yayınladı. Bu sürüm 28 güvenlik açığını kapatıyor ve 110'dan fazla hatayı düzeltiyor. Benim dikkatimi çeken sayı değil, bazı hataların nerede olduğuydu: birkaçı, çoğu kişinin "Postgres'i yamalayalım" derken aklına gelen sunucuda değil, psql ve pg_dump gibi istemci programlarında.

28 CVE nerede duruyor#

Projenin güvenlik sayfası her CVE'yi bir bileşenle etiketliyor. Bu sürümde dağılım şöyle: 18'i çekirdek sunucuda, 6'sı contrib modüllerinde, 4'ü istemci programlarında. On dördü, bu gruptaki en yüksek skor olan CVSS 8.8'e sahip ve bunların çoğu bellek güvenliği hatası; birkaçı keyfi kod çalıştırma olarak tanımlanıyor: düzenli ifadelerde (CVE-2026-14664), to_char'da (CVE-2026-14669) ve contrib tarafında pg_stat_statements'ta (CVE-2026-14676, yalnızca PostgreSQL 18) heap buffer overflow'lar. tsvector/tsquery ve fuzzystrmatch'teki integer wraparound hataları da aynı skoru alıyor.

İkisi sunucu ile araçlar arasındaki çizgiyi aşıyor:

• CVE-2026-15741 (8.8): bir EXTRACT() ifadesinin deparse edilmesi SQL injection'a izin veriyor; böylece bir nesne sahibi, kötü niyetli bir nesne tanımı üzerinden superuser olarak keyfi SQL çalıştırtabiliyor. Bildiriye göre açık, pg_dump ve psql'in \sf komutu dahil olmak üzere deparse kullanan araçları genel olarak etkiliyor.
• CVE-2026-6464 (8.1): COPY FROM STDIN veya \copy FROM STDIN, sunucu satırları beklediğini bildirmeden önce başarısız olursa psql satır içi veri satırlarını psql komutu olarak işliyor. Dosya adıyla kullanılan COPY FROM etkilenmiyor ve tam bir saldırı genellikle hem sunucunun hem de veri satırlarının kontrolünü gerektiriyor.

Ekiplerin unuttuğu kısım: istemci tarafı#

CVE-2026-6464 dışındaki istemci CVE'leri şunlar:

• CVE-2026-19385: pg_dump'ta uzun function transform listeleriyle tetiklenen bir heap buffer overflow, nesne oluşturan kişinin pg_dump'ı çalıştıran işletim sistemi kullanıcısı olarak kod çalıştırmasına imkân tanıyor.
• CVE-2026-18408: \restrict ve \unrestrict meta komutları CVE-2025-8714'ü düzeltmek için eklenmişti; meğer tek başına \unrestrict bir saldırı için yeterliymiş. Kaynak sunucudaki kötü niyetli bir superuser, dump'ı psql üzerinden geri yükleyen işletim sistemi hesabı olarak çalışacak kod yerleştirebiliyor. pg_dumpall da etkileniyor, düz formatta çıktı ürettiğinde pg_restore da.
• CVE-2026-16241: istemciyi çökertebilen bir ECPG integer underflow.

pg_dump ve psql'in nerelerde çalıştığını bir düşünün: gecelik yedekleme container'ı, entegrasyon testlerinden önce temizlenmiş bir dump'ı geri yükleyen CI imajı, production'ı staging'e kopyalamak için kullanılan bastion, geliştirici laptopları. Sunucu 18.6'ya geçtiğinde bunların hiçbiri kendiliğinden güncellenmiyor ve çoğu zaman birden fazla veritabanının kimlik bilgilerini barındırıyorlar.

Bu tek seferlik bir durum da değil: aynı güvenlik sayfasına göre bir önceki minor sürüm de libpq'nun lo_* fonksiyonlarında, pg_basebackup'ta ve pg_rewind'da istemci tarafı hataları düzeltmişti. İstemci araçları da saldırı yüzeyinin parçası ve sunucuyla aynı yama temposunu hak ediyor.

Güncelleme sonrası üç adım#

Minor bir sürüm genellikle durdur, binary'leri değiştir, başlat demektir. Bu sefer ek işler var:

• GIN indeksleri: paralel GIN indeks oluşturma işlemleri, bir tablonun reltuples değerini Infinity veya NaN dahil anlamsız bir değerde bırakabiliyordu. Bu, autovacuum ve autoanalyze'ın tabloyu işlemesini engelleyebiliyor ve kendiliğinden düzelmiyor. Değeri yanlış görünen her tabloda ANALYZE çalıştırın.
• btree_gist: NaN içerebilecek float4/float8 kolonlarındaki ve bit/bit varying kolonlarındaki btree_gist indekslerini reindex edin.
• ltree: yaklaşık 14.653'ten fazla etiket içeren ltree değerleri üzerindeki B-tree indeksleri bozulmuş olabilir ve reindex edilmeleri gerekir.

Duyuruda bir GIN kontrol sorgusu var; benim versiyonum access method'u adıyla eşleştiriyor:

SELECT DISTINCT t.oid::regclass AS table_name, t.reltuples
FROM pg_index i
JOIN pg_class ic ON ic.oid = i.indexrelid
JOIN pg_am am    ON am.oid = ic.relam
JOIN pg_class t  ON t.oid = i.indrelid
WHERE am.amname = 'gin';

Güncellemeleri script'leyenler için iki ayrıntı. 18.5 diye bir sürüm yok: bir regresyon yüzünden yayınlanmadı, yani 18 serisi 18.4'ten doğrudan 18.6'ya geçiyor. Ayrıca 14, 15 ve 16'da bu sürüm, daha eski bir minor sürümdeki primary'den gelen WAL'ı replay eden bir standby'ın takılıp kalabildiği bir self-deadlock'u düzeltiyor; bu da bir önceki minor sürüm turundan kalma bir regresyondu. Standby'ları primary'den önce güncelliyorsanız bilmekte fayda var.

PostgreSQL 14'ün üç ayı kaldı#

PostgreSQL 14, 12 Kasım 2026'da düzeltme almayı bırakıyor; yani 14.24 son güncellemelerinden biri. Hâlâ 14'teyseniz yükseltmenin tarihini ekimde değil, şimdi belirlemeniz gerekiyor.

Daha ileriye bakarsak, 19 Beta 3 GROUP BY ALL'u geri alıyor ve yeni FOR PORTION OF sözdizimi ile logical replication sequence senkronizasyonundaki birkaç sorunu düzeltiyor. Production için değil, ama proje insanların gerçek iş yüklerini üzerinde denemesini istiyor.

Benim yorumum#

Postgres, PostGIS destekli bir seyahat uygulaması da dahil olmak üzere birçok stack'imde var ve buradan çıkan ders şu: "veritabanı" tek bir sunucu değil, birçok makineye dağılmış bir binary kümesi. Pazartesi günü bir ekibe vereceğim liste:

• psql, pg_dump, pg_restore veya libpq barındıran her yerin envanterini çıkarın: base imajlar, CI runner'lar, yedekleme job'ları, bastion'lar, laptoplar. Hepsini eşleşen minor sürüme yükseltin.
• Sunucuları yamalayın ve replica'ları bilinçli bir sırayla güncelleyin, özellikle 14 ile 16 arasındaki sürümlerde.
• GIN reltuples kontrolünü çalıştırın, ardından geçerli olduğu yerlerde btree_gist ve ltree indekslerini reindex edin.
• Tam olarak kontrol etmediğiniz bir sunucudan alınmış dump'ı geri yüklemeyi güvenilmeyen kod çalıştırmak gibi görün, çünkü CVE-2026-18408 bunun tam olarak öyle olabileceğini gösteriyor.
• PostgreSQL 14 yükseltmesini takvime koyun.