PostgreSQL, 22 Yıllık Bir Güvenlik Açığı Dahil 52 Hatayı Giderdi

PostgreSQL, 22 Yıllık Bir Güvenlik Açığı Dahil 52 Hatayı Giderdi

PostgreSQL’de tespit edilen bir tür karışıklığı güvenlik açığı, nesne oluşturma yetkisine sahip bir veritabanı kullanıcısının sunucuda kod çalıştırmasına olanak tanıyordu. Dün yayınlanan güncellemeler, bu hatayı ve diğer 51 güvenlik açığını giderdi. Bu güvenlik açığından tam koruma sağlamak için sunucuda kurulu tüm C dili uzantılarının yeniden oluşturulması gerekiyor.

CVE-2026-6460 olarak izlenen bu güvenlik açığı, 8.8 CVSS puanına sahip. Bu yolla çalıştırılan herhangi bir kod, PostgreSQL’i çalıştıran işletim sistemi kullanıcısının haklarına sahip oluyor. 18.7, 17.12, 16.16, 15.20 ve 14.25 öncesi tüm sürümler bu açıktan etkileniyor.

Veritabanının sürümlerini yayınlayan PostgreSQL Global Development Group, bu güvenlik açığını kullanarak herhangi bir saldırı rapor etmedi. CISA’nın CVE kaydındaki değerlendirmesi de istismarın olmadığını belirtiyor.

Güvenlik açığı, her biri kendi veri tipine sahip adlandırılmış alanlardan oluşan bileşik tipleri içeriyor. Bir alanın tipi, o tipin eski değerleri sunucunun diğer bölümlerinde tutulurken değiştirilebiliyordu. Bu durumda sunucu, eski bir değeri yeni tipteymiş gibi okuyabiliyordu. Projenin sürüm notlarında açıklanan düzeltme, sunucunun artık tipiyle eşleşmeyen bir değeri algılayabilmesi için sürüm kontrolleri ekliyor.

Güvenlik araştırmacısı Mehmet İnce, bu hafta yayınladığı teknik bir makalede, PostgreSQL 18.6 üzerinde gösterilen, bu güvenlik açığı için çalışan bir istismarı detaylandırdı.

İnce’nin yöntemi, bir değer tutan bir sorgu hazırlamak, değerin alanlarından birinin tipini değiştirmek ve ardından sorguyu çalıştırmaktır. Makale, bu şekilde yamalanmamış bir sunucuyu çökerten SQL kodunu ve bellek adreslerini sızdıran ikinci bir adımı içeriyor. Ancak sunucunun bir komut çalıştırmasını sağlayan son adım için SQL kodunu içermiyor.

İnce, bu çöküşü “en düşük ayrıcalıklı oturum açma rolü olarak tetikleyebildiğini” yazdı. Projenin güvenlik uyarısı, saldırganı yalnızca nesne oluşturabilen biri olarak tanımlıyor, ancak bunun hangi ayrıcalıkları gerektirdiğini belirtmiyor.

PostgreSQL paketlerini dağıtan Red Hat, CVE değerlendirmesinde, bir saldırganın nesne oluşturma veya değiştirme yeteneğine sahip bir veritabanı oturum açma bilgisine ihtiyacı olduğunu belirtiyor. Bu kaynakların hiçbiri, yalnızca varsayılan ayrıcalıklara sahip bir hesabın çöküşün ötesine geçerek kod çalıştırıp çalıştıramayacağını söylemiyor.

İnce, güvenlik açığının kökenini, PostgreSQL’in bir sütunun tipini değiştirme yeteneğini kazandığı 5 Mayıs 2004 tarihine dayandırıyor. Kod çalıştırma tekniği ise 14 Mayıs 2015’te yapılan daha sonraki bir değişikliğe dayanıyor.

Ayrıca, istismarı yönetilen PostgreSQL hizmetleri için uyarladı ve Ağustos ayında güvenlik ekipleriyle özel olarak kavram kanıtlarını paylaştı. Çalıştığı sağlayıcılar arasında AWS (Aurora ve RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks ve Ubicloud bulunuyor. Makale, her hizmetin mevcut yama durumunu belirtmiyor.

Proje, araştırmacı da dahil olmak üzere CVE-2026-6460 için bir düzineden fazla raporlayıcıya ve aynı sürümdeki diğer beş güvenlik açığı için de İnce’ye teşekkür ediyor.

Proje, 52 güvenlik açığından 32’sini 8.8 olarak derecelendiriyor; bu, sürümdeki en yüksek puandır. Güvenlik açığı endeksindeki puanlara göre, sunucudaki yalnızca bir güvenlik açığı ne oturum açma ne de kullanıcı eylemi gerektiriyor. Bu güvenlik açığı, CVE-2026-116322, kimliği doğrulanmamış bir istemcinin PostgreSQL 18 sunucularının yeniden başlatılmasını tetiklemesine olanak tanıyor.

Diğer bazı düzeltmeler istemci araçlarında bulunuyor. Hazırlanmış bir arşiv, pg_restore’un onu çalıştıran kullanıcı olarak kod çalıştırmasına neden olabilir. Güvenliği ihlal edilmiş bir kaynak sunucu, pg_dump’ın tar çıktısındaki geri yükleme betiği aracılığıyla psql’in kod çalıştırmasına neden olabilir.

Yöneticiler Ne Yapmalı?

1. Sunucuyu ana sürümünüze uygun olarak 18.7, 17.12, 16.16, 15.20 veya 14.25’e güncelleyin.
2. Her C dili uzantısını sunucuyla aynı anda yeniden oluşturun veya güncelleyin. Eski sürümlere karşı oluşturulmuş uzantılar hala yüklenir, ancak projenin RPM paket bakıcılarından gelen bir depo bildirimine göre “bu sürümde düzeltilen güvenlik açıklarından korunmayabilirler”. Bazı uzantılar için kaynak kodu değişiklikleri de gerekecektir.
3. Yeni sürümler için yeniden oluşturulan uzantılar, eski sunucularda yüklenemeyebilir. Projenin RPM depolarındaki uzantı paketleri artık yeni küçük sürümü gerektiriyor.
4. PostgreSQL, kendi paketinin hizmet birimi dışında, örneğin Patroni altında çalışıyorsa, bir RPM paket bakıcısının paketleme blog yazısında belirttiği gibi, güncellemeden hemen sonra yeniden başlatın.
5. pg_dump, pg_restore, reindexdb ve vacuumdb gibi istemci araçlarını bunları çalıştıran her makinede güncelleyin.
6. Kontrolleri kapatmak için yeni composite_type_mismatch ayarını kullanmayın. Proje, bunu yapmanın güvenlik riskleri taşıdığını belirtiyor.
7. Projenin uyarısı ve sürüm notları, henüz güncellenemeyen sunucular için bir geçici çözüm sunmuyor.
8. PostgreSQL 14 artık kullanım ömrünün sonuna geldi ve 14.25 son sürümüdür. Daha eski ana sürümler de etkileniyor ve güncelleme almadılar.
9. Güncellemeden sonra, sürüm duyurusundaki yeniden indeksleme adımlarını izleyin. Artımlı yedeklemeler kullanıyorsanız, yeni bir tam yedekleme alın ve sonraki artımlı yedeklemeleri buna dayandırın.