PHP’de kritik alarm: İki açık, ortak risk ve güncelleme gerçeği
22 Ekim 2026 gündemindeki PHP alarmı, tek bir siteye veya eklentiye özgü bir hatadan kaynaklanmıyor. PHP’nin çalışma zamanında bulunan CVE-2026-109618 ve CVE-2026-109619, uygun koşullarda kimlik doğrulaması olmadan uzaktan kod çalıştırılmasına yol açabiliyor. Her ikisinin CVSS v4.0 temel puanı 9,2: kritik. Düzeltmeler 21 Ekim’de yayımlandı; bugün yapılması gereken, yamanın varlığını öğrenmekten çok hangi sistemlerin gerçekten düzeltildiğini belirlemek.
Bu ayrım önemli: Açığın bulunması, saldırı girişimi görülmesi ve bir sunucunun ele geçirilmesi farklı olgular. Saldırı trafiği gözlemlenmiş olması aciliyeti artırıyor, ancak bundan bütün PHP sitelerinin ihlal edildiği sonucu çıkarılamaz. Başarılı bir saldırının etkisi de web işçi sürecinin izinleriyle sınırlı başlar; otomatik olarak yönetici veya root yetkisi kazanıldığı anlamına gelmez.
İlk açık: Bellek tükenirken güvenli çıkışın bozulması
CVE-2026-109618, bellek tükenmesi sırasında kullanılan longjmp() çıkışıyla ilgili. PHP, henüz tam başlatılmamış iç verilere erişilebilir durumdayken işlemi kesebiliyor; istek kapatılırken bu geçersiz veriler kullanılabiliyor. Özel hazırlanmış çok parçalı istekler, bellekte beklenenden fazla yer kaplayan başlıklar veya uygulamanın kendi bellek kullanımı bu duruma katkıda bulunabiliyor.
Apache’nin mod_php kurulumu için, uygulama kodu çalışmadan önce tetiklenen tam bir uzaktan kod çalıştırma örneği doğrulandı. Yama, bellek tükenmesinin ele alınışını değiştirerek bu güvensiz erken çıkış yolunu düzeltiyor.
İkinci açık: Önceki isteğin geçersiz belleğinin sonraki isteğe taşınması
CVE-2026-109619, bir isteğe ait belleğin serbest bırakılmasına rağmen işçi sürecindeki bazı genel durum bilgilerinin temizlenmemesinden kaynaklanıyor. Aynı işçi sonraki isteği aldığında, normal başlangıç işlemlerinden önce eski bilgiye erişebiliyor. Bu, teknik olarak bir use-after-free, yani serbest bırakılmış belleğin yeniden kullanılması sorunu.
Burada önce geçersiz durumu bırakan, sonra onu kullanan bir işlem gerekiyor. Oturum yükleme ilerlemesi ve erken yapılandırma uyarıları doğrulanmış yollar arasında. PHP 8.5’in ölümcül hata geri izleri de doğrulanmış bir örnek oluşturuyor. Hataları ekranda gizlemek, bellekteki yanlış erişimi ortadan kaldırmıyor.
Kimlerin öncelik vermesi gerekiyor?
İnternetten istek alan PHP kurulumları öncelikli: PHP-FPM, mod_php, php-cgi, FrankenPHP ve LiteSpeed değerlendirmeye dahil. Ancak bu kurulumların saldırı koşulları aynı değil. İlk açık için PHP-FPM’de tamamlanmış bir istismar gösterimi bulunmaması, FPM’nin güvenli olduğu anlamına gelmiyor; ikinci açıkta uygun bir uygulama işlemi üzerinden doğrulanmış FPM yolu bulunuyor.
İçerik yönetim sistemleri, e-ticaret uygulamaları ve kurumsal portalların altında çalışan PHP de envantere girmeli. Uygulamanın kendi güncellemesi PHP çalışma zamanını değiştirmiyorsa bu iki açığı kapatmış sayılmaz.
Hangi sürümler düzeltildi?
Desteklenen dallardaki düzeltme eşikleri şöyle:
| Kullanılan dal | Bu iki açığı düzelten sürüm |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Bu dallarda belirtilen sürümlerin öncesi değerlendirilmelidir. Dağıtımlar, düzeltmeyi eski sürüm numarasını koruyan paketlere geri taşıyabilir; bu yüzden yalnızca sürüm satırına bakmak yerine sağlayıcının paket duyurusunu da kontrol etmek gerekir. PHP 8.1 ve daha eski dallar normal proje desteği dışında. Bazı eski dallar için sınırlı kaynak yamalarının veya sağlayıcı desteğinin bulunması, düzenli güvenlik desteğinin geri geldiği anlamına gelmez.
Geçici ayarlar neden yeterli değil?
session.upload_progress.enabled=0 bilinen oturum yollarını, PHP 8.5’te fatal_error_backtraces=0 ise belirli geri iz yolunu azaltabilir; bunlar bütün varyantları kapatmaz ve ilgili işçilerin yeniden başlatılmasını gerektirir. memory_limit=-1 de bu açığa karşı koşulsuz bir reçete değildir: Bir tetikleyiciyi azaltırken bellek tüketimi ve hizmet sürekliliği açısından başka sonuçlar doğurabilir. Alttaki bellek ayırma hataları hâlâ önemlidir. Web uygulaması güvenlik duvarı da güncellemenin yerine geçmez.
Benim uygulama önceliğim; dışarı açık sistemleri belirlemek, uygun güvenlik paketini yüklemek, ilgili hizmetleri yeniden başlatmak ve ziyaretçilerin isteklerini karşılayan gerçek çalışma zamanını doğrulamak olurdu. Komut satırındaki php -v tek başına bütün havuzların veya konteynerlerin düzeltildiğini kanıtlamaz. Şüpheli izler varsa yama kurmak geçmişteki olası ihlali temizlemez; olay incelemesi ayrıca yürütülmelidir.
Bu olayın verdiği ders, yama yönetiminin bir indirme işlemi olmadığı. Güvenliği belirleyen şey, güncellemenin çalışan bütün kopyalara ulaşması ve bunun doğrulanması.
Kapak yapay zekâyla üretilmiş temsili bir sahnedir; gerçek bir saldırının veya kurumun fotoğrafı değildir.