PHP’deki iki kritik açık: Etkisi ve alınması gereken önlemler.

PHP ekibi 21 Ekim’de, bazı PHP kurulumlarında uzaktan kod çalıştırmaya kadar gidebilen iki kritik güvenlik açığını duyurdu. Haberlerde büyük başlıklarla karşıma çıktı; ben de teknik olarak ne olduğunu ve ne kadar telaşlanmamız gerektiğini sade biçimde anlamaya çalıştım.

Önce önemli ayrım: Bu, her PHP uygulamasında yazılmış bir kod hatası değil. Sorun PHP çalışma zamanının kendi içinde, istekleri işlerken kullandığı bellek ve hata yönetimi katmanlarında. Açıklar PHP’nin resmi duyurusunda CVE-2026-109618 ve CVE-2026-109619 olarak listeleniyor. İkisi de CVSS 4.0 ölçeğinde 9,2 puanla kritik sınıfta.

İlk açık: bellek bittiğinde yarım kalan durum

CVE-2026-109618, bellek yetersizliği (out of memory, OOM) yaşandığında PHP’nin isteği sonlandırma biçimiyle ilgili. İstek işlenirken PHP’nin bazı iç verileri henüz tamamen hazırlanmış olmayabiliyor. Tam o sırada bellek sınırına ulaşılırsa işlem erken kesiliyor; ardından temizlik aşaması, tamamlanmamış verileri geçerliymiş gibi ele alabiliyor.

Bu durum her bellek hatasının otomatik olarak sunucunun ele geçirilmesi demek değil. Zamanlama ve istek işleme koşulları önemli. PHP ekibi, Apache’nin `mod_php` kullanımını en riskli senaryo olarak belirtiyor: burada uygulama kodu başlamadan önce tetiklenebilen ve uzaktan kod çalıştırdığı gösterilmiş bir yol var. PHP-FPM için de risk var, ancak doğrulanmış senaryolar uygulama kodundaki belirli yollara bağlı. Ayrıntılar PHP’nin CVE-2026-109618 güvenlik danışmanında açıklanıyor.

İkinci açık: önceki isteğin belleğinden kalan iz

CVE-2026-109619 farklı bir bellek hatası. Bir istek hata ile bittiğinde, ona ait bazı iç durumlar serbest bırakılmış belleğe işaret etmeye devam edebiliyor. Aynı çalışan süreç daha sonra başka bir isteği işlerken bu eski duruma, tamamen sıfırlanmadan erişebiliyor. Yazılım güvenliğinde buna use-after-free, yani serbest bırakılmış belleği yeniden kullanma hatası deniyor.

PHP ekibi bir işçi sürecin çökmesini ve gerçek bir uygulamada uzaktan kod çalıştırılmasını doğruladığını bildiriyor. Bu açığın da ayrıntıları resmî kaynak kodu deposundaki güvenlik danışmanında yer alıyor. İki açık aynı şey değil; ikisi de PHP’nin her istekte çalışan temel mekanizmalarına dokundukları için ciddiler.

“Yapay zekâ keşfetti” başlığının arkasında ne var?

Hikâyenin konuşulmasının bir nedeni de yapay zekâ destekli güvenlik araştırmaları. PHP Foundation’ın anlatımına göre bellek yönetimi sorununa dair ilk işaretler 2024’teki bir güvenlik denetimi sırasında görülmüştü. 2026’da Calif, OpenAI ve Wiz gibi ekiplerin raporları sorunun uzaktan kod çalıştırmaya dönüşebileceğini ortaya koymaya yardımcı oldu. OpenAI, Calif araştırmacısının GPT-5.6 Sol kullanarak kritik açığı bulduğunu ve kendilerinin de aynı kök nedeni bağımsız olarak raporladığını belirtiyor. Süreç ve ekiplerin katkıları PHP Foundation’ın açıklamasında ayrıntılı biçimde anlatılıyor.

Burada “yapay zekâ tek başına açığı buldu ve çözdü” demek doğru olmaz. Araştırmacılar bulguları doğruladı, PHP ekibi hataları inceledi ve yamaları hazırladı; farklı ekipler de test ve koordinasyona katkı verdi. PHP Foundation, raporların önemli bir bölümünün geçersiz ya da tekrarlı çıktığını, nihai değerlendirme ve düzeltmelerin insanlar tarafından yapıldığını özellikle vurguluyor. OpenAI’ın koordineli açıklama yazısı da bu katkıların nasıl yürüdüğünü kendi tarafından özetliyor.

Sunucu yönetenler ne yapmalı?

En doğru adım PHP sürümünü kullanılan dağıtımın veya barındırma sağlayıcısının güvenlik duyurusuna göre güncellemek. PHP projesinin yayımladığı düzeltilmiş sürümler 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Linux dağıtımları ve uzun süreli destek sağlayıcıları yamayı kendi paketlerine ayrıca aktarabiliyor; bu nedenle sürüm numarası farklı görünüyorsa sağlayıcının duyurusunu kontrol etmek gerekiyor. PHP 8.1 ve daha eski sürümler artık PHP projesinden doğrudan güvenlik güncellemesi almıyor; bazı dağıtımlar geriye dönük yama sunabiliyor. Güncel tablo için resmî PHP duyurusuna bakın.

Güncelleme hemen yapılamıyorsa PHP ekibi bazı geçici ayarları listeliyor; bunlar yalnızca belirli saldırı yollarını daraltıyor ve güvenli bir sürüme geçmenin yerini tutmuyor. Sunucunun hangi SAPI ile çalıştığını (`mod_php`, PHP-FPM, php-cgi gibi) ve dağıtımın yamasını alıp almadığını sistem yöneticinizle veya hosting sağlayıcınızla doğrulayın. Rastgele bir `php.ini` ayarıyla sorunun tamamen çözüldüğünü varsaymayın.

Kısacası

Bu, PHP’yi kullanan herkesin sitesinin ele geçirildiği anlamına gelmiyor. Ancak web isteği karşılayan PHP kurulumlarının yöneticileri için yamayı geciktirmemek gerekiyor. Benim bu olaydan çıkardığım daha geniş ders şu: yapay zekâ araştırmacıların ciddi bir hatayı fark etmesine yardımcı olabilir, ama güvenlik açığını gerçek dünyada azaltan şey hâlâ dikkatli doğrulama, iyi hazırlanmış yamalar ve bu yamaları zamanında dağıtmak.