CVE-2026-17351

pgAdmin 4 9.16 sürümündeki CVE-2026-12045 için getirilen düzeltme, AI Assistant'ın execute_sql_query aracına iletilen ve LLM tarafından sağlanan sorgunun, bir BEGIN TRANSACTION READ ONLY sarmalayıcısı içinde çalıştırılmadan önce sqlparse aracılığıyla tam olarak tek bir işlem kontrolü dışı ifade olarak ayrıştırılmasını gerektiriyordu. sqlparse'ın dize sabitleri sözcük analizi, PostgreSQL'in kendi ayrıştırıcısıyla uyuşmayabilir: standard_conforming_strings = on durumunda (9.1 sürümünden beri PostgreSQL varsayılanıdır), tırnak işaretinden hemen önceki ters eğik çizgi PostgreSQL için sıradan bir karakterdir ancak sqlparse bunu tırnağı kaçış karakteriyle belirtmek olarak değerlendirir. Bu nedenle, SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' gibi bir yük, sqlparse doğrulayıcısı tarafından tek bir SELECT ifadesi olarak ayrıştırılırken, PostgreSQL bunu dört ifade olarak yürütür: gizlenen COMMIT, sarmalayıcı salt okunur işlemi sonlandırır ve sondaki ROLLBACK etkisiz hale gelir. Bu durum, aynı dolaylı istem injection yöntemiyle erişilebilen (bir saldırgan, yükü AI Assistant'ın okuyabileceği herhangi bir nesneye yerleştirir; LLM bunu bir araç çağrısı olarak yayınlar) ve CVE-2026-12045'in kapatmayı amaçladığı yazma/RCE baypasını yeniden ortaya çıkarır. İlk aday düzeltme, sqlparse sınıflandırmasından bağımsız olarak PostgreSQL'in kendi Ayrıştırma adımının (genişletilmiş sorgu protokolü) çoklu ifade metinlerini reddetmesini zorlamak amacıyla sorguyu psycopg'un execute(..., prepare=True) fonksiyonu ile çalıştırıyordu. Bu aday düzeltme sunulduğu haliyle çalışmamaktadır: psycopg3'ün PrepareManager bileşeni, bağlantının prepare_threshold değeri None olduğunda prepare argümanını sessizce yoksayar; bu, pgAdmin'in her sunucu bağlantısı için varsayılan değeridir (sunucu başına "Prepare threshold" alanı, bir yönetici tarafından açıkça ayarlanmadıkça boştur). psycopg3 basit sorgu protokolüne geri döner ki bu, baypasın kullandığı çoklu ifade destekleyen yolla aynıdır; dolayısıyla aday düzeltme, gerçek dünyadaki hiçbir varsayılan yapılandırmada sorunu gidermez. Düzeltilmiş çözüm, AI Assistant aracının açtığı özel, tek kullanımlık salt okunur bağlantı üzerinde doğrudan conn.prepare_threshold = 0 ayarını yaparak, herhangi bir sunucu düzeyindeki yapılandırmadan bağımsız olarak genişletilmiş sorgu protokolünü yapısal olarak zorunlu kılar. Canlı bir PostgreSQL 18 örneği üzerinde doğrulanmıştır: Yük, prepare_threshold=None (varsayılan) davranışı altında başarıyla yürütülürken, o bağlantıda prepare_threshold=0 ayarlandığında "cannot insert multiple commands into a prepared statement" hatasıyla reddedilir. Bu sorun pgAdmin 4'ü etkilemektedir: 9.13'ten 9.17 öncesine kadar olan sürümler.