Yeni PHP2Shell Açığı Çıktı: Geliştiriciler Acil Yamayı Reddetti

PHP ekibi neden acil yamayı reddetti?

Geliştiriciler, güvenlik açığının gerçek sistemlerde tetiklenmesi için çok özel bir yapılandırma dizilimi gerektiğini ve genel saldırı yüzeyinin fazlasıyla dar olduğunu vurguladı.

İlk PHP2Shell sıfır gün açığının (CVE-2026-109619) yarattığı telaşın hemen ardından, PHP Güvenlik Ekibi oturum yönetimiyle bağlantılı yeni bir uzaktan kod yürütme (RCE) riski paylaştı. Ancak bu defa geliştiriciler panik havasına girmeden olağan sürüm takvimine bağlı kalıyor.

CVE-2026-115560 olarak kodlanan açık, PHP'nin oturum yükleme ilerleme mekanizmasında (session upload progress) bulunuyor. Birkaç gün önce sunucu yöneticilerini uykusuz bırakan ilk krizin aksine, bu açığı dışarıdan istismar etmek pek kolay değil.

Açığın çalışması için web uygulamasının önce php.ini üzerinde serileştirme işleyicisini php_binary ya da php_serialize olarak belirlemesi gerekiyor. Ardından kodun tam session_start() çağrısından önce ini_set() kullanarak bu işleyiciyi düz php moduna çevirmesi şart. Bir yazılım oturum başlatılırken bu işleyiciler arasında kasıtlı olarak geçiş yapmıyorsa saldırı vektörü tamamen etkisiz kalıyor.

CVE-2026-115560: Durum, risk seviyesi ve geçici çözüm

İlk PHP2Shell krizinden çıkarılan dersler

Sistem yöneticilerinin PHP açıklarına karşı temkinli yaklaşması sürpriz değil. Ay başında ilk PHP2Shell açığına dair ambargo süresinden önce sızdırılmış ve web genelinde kitlesel taramalar başlamıştı. AWS, planlanan yama tarihinden dört gün önce aktif istismar girişimleri rapor etmişti.

Güvenlik firmalarının konteyner yamalarını erken sunmasıyla birlikte saldırganlar milyonlarca zararlı istek gönderdi. Avrupa'da bazı resmi kurum, sağlık ve üniversite portalları koruma amacıyla sistemlerini geçici olarak internete kapattı.

Buna rağmen doğrulanmış sızıntı sayısı şaşırtıcı şekilde düşük kaldı. Güvenlik uzmanları, modern Linux çekirdeklerindeki ASLR korumasının otomatik saldırıları kırdığını belirtiyor. Sunucu sürecini çökertmeden belleği uzaktan manipüle etmek ciddi bir uzmanlık istiyor; tıpkı daha önce insanların çözemediği eski PHP açığını yapay zekanın silaha dönüştürmesi örneğinde görüldüğü gibi saldırı mekanizmaları giderek karmaşıklaşıyor.

Sunucu yöneticileri sistemi nasıl koruyabilir?

Dağıtımların resmi güncellemelerini beklerken boş durmaya gerek yok. Riskten kurtulmak için tek bir ayar satırını değiştirmek yeterli.

Oturum yükleme takibini kapatmak, modern web çatılarını etkilemeden açığı tamamen bertaraf ediyor. Zira güncel sistemler dosya yükleme ilerlemesini çoğunlukla istemci tarafında veya ters vekil sunucularda çözüyor.

İlk açık olan CVE-2026-109619 sırasında bu ayarı devre dışı bırakan ekipler, ek bir müdahaleye gerek kalmadan CVE-2026-115560 riskinden de korunmuş durumda.

• Sunucularınızdaki aktif php.ini dosyasını açın.
• session.upload_progress.enabled = 0 satırını girin veya değeri sıfır yapın.
• Değişikliğin devreye girmesi için PHP-FPM veya web sunucusu servisini yeniden başlatın.
• Kullandığınız Linux dağıtımı güncel PHP alt sürümünü depolara ekleyene kadar bu ayarı kapalı tutun.

Türkiye'de durum ne?

Türkiye'de hizmet veren e-ticaret siteleri, üniversite portalları ve kamu kurumlarının önemli bir bölümü PHP altyapılarıyla çalışıyor. Ubuntu, Debian veya Red Hat kurumsal depolarından standart güncellemeleri takip eden yerli sistem yöneticilerinin acil gece mesaisi yapmasına gerek bulunmuyor.

Yine de PHP altyapısında özel oturum kütüphaneleri kullanan geliştiricilerin, dağıtımlardan resmi paketler gelene kadar php.ini içinde yükleme takibini pasife alması en güvenli adım olacaktır.