PHP2Shell için düzeltme yayımlandı; ancak buna ihtiyaç duyan web sitelerinin çoğunda basılacak bir düğme yok. Açıklar PHP’nin kendisinde, her WordPress, Joomla ve Drupal sayfasını çalıştıran; CMS’nin, eklentilerinin ve giriş ekranının altında yer alan altyapıda bulunuyor. WordPress’i güncellemek bu açıkları kapatmıyor. Yamalanmış yorumlayıcının sunucuyu işletenlerden gelmesi gerekiyor: barındırma şirketinden, Linux dağıtımının paketinden ya da kapsayıcı imajından. Bu gerçekleşene kadar, sahibi ne yaparsa yapsın site beklemede kalıyor.

“Hemen yama yükleyin” başlıklarının atladığı nokta bu. PHP ekibi üzerine düşeni yaptı. Yaptıkları düzeltmenin belirli bir sunucuya ulaşması, en yavaş halkasının hızında ilerleyen bir dağıtım zincirine bağlı; ilk gün de bu halkalar arasındaki mesafenin ne kadar büyük olduğunu gösterdi. PHP’sinin nereden geldiğini bilmeyen bir site sahibi, ne ölçüde risk altında olduğunu da anlayamıyor.

WordPress güncellemesi açığı neden kapatmıyor?

Hatalar yorumlayıcının içinde bulunduğundan, PHP’nin güvenlik duyurusu web isteklerini karşılayan tüm kurulumları kapsıyor: PHP-FPM ve Apache’nin mod_php’sinden php-cgi, FrankenPHP ve LiteSpeed’e kadar. The Hacker News’e göre, savunmasız bir sürümde çalışan basit bir “Hello World” sayfası bile saldırıya uğrayabilir. En kötü senaryo mod_php’de görülüyor: hesabı olmayan bir kişinin gönderdiği tek bir istek, uygulama kodu çalışmaya başlamadan saldırıyı tetikleyebiliyor. Dolayısıyla hiçbir güvenlik eklentisi ya da giriş ekranı saldırıyı fark etmiyor.

WordPress güvenlik şirketi Wordfence, The Verge’in aktardığına göre site sahiplerine düzeltmenin otomatik güncellemeler aracılığıyla ulaşamayacağını ve PHP’den kimin sorumlu olduğunu öğrenmeleri gerektiğini söyledi. Laravel Forge da kendi sunucularını kullanan müşterilerine aynı uyarıyı yaptı: otomatik güvenlik güncellemeleri PHP’yi yamalamıyor; Ubuntu’nun gözetimsiz güncellemeleri ise Forge’un PHP’yi kurduğu üçüncü taraf paketlerden değil, yalnızca Ubuntu’nun kendi deposundan paket alıyor.

Bu paket kaynakları aynı anda güncellenmedi. Yamanın yayımlandığı gün site yönetim hizmeti mySites.guru, cPanel’in EasyApache 4’ünün güvenlik duyurularından birkaç dakika sonra düzeltilmiş sürümleri sunduğunu, buna karşılık Laravel Forge’un da kullandığı Ubuntu paket kaynağı Ondřej Surý’nin PPA’sında ve Remi’nin deposunda henüz bir güncelleme bulunmadığını bildirdi. InMotion Hosting, paylaşımlı barındırma ve WordPress sunucularının CloudLinux paketlerini beklediğini söyledi. mySites.guru’nun izlediği yayındaki siteler arasında saat 13:52 UTC itibarıyla PHP’nin düzeltilmiş bir sürümünü bildirenlerin oranı yalnızca %0,08’di.

Sürüm numarası yanıltıcı olabilir

Güncellemenin yapılıp yapılmadığını anlamak, yalnızca sürüm numarasına bakmaktan daha zor. Ubuntu, Debian ve Red Hat güvenlik düzeltmelerini ana sürüme geri taşıyor, ancak üst sürüm numarasını değiştirmiyor. Bu nedenle yama uygulanmış bir Ubuntu 24.04 sunucusu hâlâ 8.3.6 paketini kullandığını gösterebilir. The Hacker News, Debian’a atıfta bulunarak sürüm numarasına güvenmek yerine paketin değişiklik günlüğünde CVE kaydını aramayı öneriyor. mySites.guru ikinci bir tuzağa daha dikkat çekiyor: Komut satırında php -v yanıtını veren PHP ikilisi çoğu zaman sayfaları sunan ikili değil. Bu nedenle sitenin kendisinin bildirdiği sürümü kontrol etmek gerekiyor.

Ardından yamanın yüklenmesi de şart. PHP’nin güvenlik duyurusu ve Forge, Apache’nin, PHP-FPM’in ve uzun süre çalışan tüm iş süreçlerinin yeniden başlatılması gerektiğini özellikle vurguluyor. Kuyruk işçileri ve benzeri arka plan süreçleri yeniden başlatılana kadar eski yorumlayıcıyla çalışmayı sürdürüyor; diskteki dosyalar yamalanmış olsa bile.

Kimler resmî düzeltme alamıyor?

Düzeltilmiş sürümler PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35; bu sürümler CVSS v4.0’a göre 9,2 puanla derecelendirilen CVE-2026-109618 ve CVE-2026-109619 açıklarını kapatıyor. PHP projesi, PHP 8.1 ve daha eski sürümler için herhangi bir güncelleme sunmuyor; yalnızca PHP’yi kendileri derleyenlere yönelik olarak 7.4, 8.0 ve 8.1 için asgari düzeyde kaynak kod düzeltmeleri sağlıyor. Bazı tedarikçiler bu açığı kapatıyor: InMotion, cPanel’in 7.4’ten 8.1’e kadar olan paketlere düzeltmeleri geri taşıdığını, CloudLinux’un ise dağıttığı tüm sürümlere yama uyguladığını söylüyor. CentOS 7 içinse hiçbir düzeltme sunulmuyor.

Destek dışı kalan eski sürümlerin kullandığı sistemlerin sayısı az değil. Yayımdan bir gün önce mySites.guru’nun izlediği yayındaki Joomla ve WordPress sitelerinin %22,7’si PHP 8.1 veya daha eski bir sürümle çalışıyordu; %16,6’sı ise hâlâ PHP 7 ya da daha eski bir sürüm kullanıyordu. Şirket, bunun bir kısmının WordPress’in kendisinden kaynaklandığını belirtiyor: WordPress PHP 8.3’ü öneriyor, ancak desteği çoktan sona ermiş olan 7.4 sürümünü hâlâ uyumlu olarak listeliyor. PHP 8.2 bu yamayı aldı, ancak güvenlik desteği 31 Aralık 2026’da sona eriyor.

Geçici ayar neyi engelliyor?

Düzeltme yayımlanmadan önce dolaşıma giren geçici çözüm, session.upload_progress.enabled=0 ayarını yapmak, işe yarıyor ama yalnızca kısmen. PHP, bunun CVE-2026-109619’a giden doğrulanmış oturum yollarını kapattığını, ancak diğer varyantları engellemediğini söylüyor. Ayarın php.ini dosyasında ya da sunucu veya havuz yapılandırmasında yapılması ve ardından tüm iş süreçlerinin yeniden başlatılması gerekiyor. PHP 8.5’te fatal_error_backtraces=0 ayarı, doğrulanmış bir başka yolu daha kapatıyor. Ancak bu ayarların hiçbiri CVE-2026-109618’i etkilemiyor. PHP bu açık için geçersiz kılınamayan memory_limit=-1 ayarını, düşük bir post_max_size değeri belirlenmesini ve web sunucusu ya da proxy’de istek boyutu sınırları uygulanmasını öneriyor. PHP’nin kendi ifadesiyle, açıkları tamamen gideren bir önlem yok. InMotion, WordPress, Joomla, Drupal, Magento ve PrestaShop’un yükleme ilerleme özelliğini kullanmadığını, dolayısıyla bu özelliği kapatmanın söz konusu sistemlerde hiçbir şeyi bozmayacağını belirtiyor.

Cloudflare tüm planlarda güvenlik duvarı kurallarını devreye aldı. Şirketin teknoloji direktörü Dane Knecht bu önlemi geçici bir çözüm olarak nitelendirdi. mySites.guru’nun da belirttiği gibi, bu kurallar yalnızca arka plandaki sunucu Cloudflare’ı atlayıp doğrudan kendi IP adresine yönelen trafiği reddederse işe yarıyor.

Şimdiye kadarki saldırılar

watchTowr, bal küpü sistemlerinin yayımlanma günü her iki açığa yönelik istismar girişimleri kaydettiğini söylüyor. Cloudflare ise saldırganların kurallarını aşmak için zararlı yüklerini değiştirdiğini gördü. Hiçbir kaynak, belirli bir sunucuya başarıyla sızıldığını doğrulamadı. Bazı işletmeciler riske girmedi: The Hacker News, BambooHR’ın hizmetini çevrimdışı bıraktığını, DigiD’nin de aralarında bulunduğu Hollanda’daki kamu hizmetlerinin önlem olarak erişime kapandığını aktarıyor. AB’nin CERT’i ve Birleşik Krallık Ulusal Siber Güvenlik Merkezi, yama yükleyemeyen kuruluşlara açığa açık uygulamaları ağdan yalıtmalarını ya da çevrimdışı bırakmalarını söyledi.

Açıkları Wiz Research, Calif ve OpenAI’nin Codex Security ekibi buldu. PHP Foundation’a göre bellek açığına ilişkin işaretler 2024’teki bir denetimde ortaya çıktı, ancak düzeltme aylarca ilerleme kaydedemedi. Vakıf bu gecikmeyi “yapısal bir başarısızlık” olarak nitelendirdi. Araştırmacılar, yapay zekâ modellerinin on yıllık hataları yaklaşık bir hafta içinde çalışan istismarlara dönüştürmeye yardımcı olduğunu söylüyor.

PHP’nin bu düzeltmeyi yayımlayabilmesi için bir denetim, aylar süren çıkmaz ve bir sızıntı gerekti. Paylaşımlı barındırmadaki bir site içinse son adım, destek talebi açmaktan ibaret.

Etiketler: Cloudflare, güvenlik açıkları, PHP, PHP2Shell, WordPress