PHP, erken açık ifşasının ardından dört dalda iki kritik RCE açığını yamaladı

İki kritik açık, dört yama sürümü

PHP, 21 Ekim 2026'da iki kimlik doğrulamasız uzaktan kod çalıştırma açığına yönelik düzeltmeleri yayımladı ve 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerini eşzamanlı olarak çıkardı. Her iki açık da CVSS'te 9.2 puan aldı ve CISA bu ikiliye php2shell adını veriyor. dev.to'daki Netics raporuna göre sürüm aslında 22 Ekim için planlanmıştı ama koordineli iflaşa planlanan takvimden yaklaşık iki gün önce dağılmaya başlayınca öne çekildi.

Her bir hata nasıl çalışıyor

İlk sorun olan CVE-2026-109618, PHP'nin bellek yetersizliği durumlarını ele alma biçiminde yatıyor. Bir istek yapılandırılmış memory_limit değerini aştığında PHP isteği iptal ediyor, ancak bu iptal, iç istek verileri henüz kısmen kurulmuşken (örneğin form tabanlı bir dosya yükleminin ayrıştırılması tam ortasında) gerçekleşebiliyor. PHP daha sonra bu eksik veriyi geçerli olarak ele alabiliyor ve bu da belleği bozuyor. İşin kötü tarafı, tetikleyicinin koruyucu bir sınır olması: sunucuyu tüketen bir betiği durdurması beklenen güvenlik mekanizması, saldırının giriş noktasına dönüşüyor.

İkinci sorun olan CVE-2026-109619 ise belleğinden daha uzun yaşayan durumlarla ilgili. Ölümcül bir hatanın ardından, başarısız isteğe ait iç veriler serbest bırakılıyor ama bunlara yapılan referanslar kalıyor. Worker hizmet vermeye devam ediyor ve normal başlatma bunu temizlemeden önce, worker'ın işlediği sonraki istek o artık durum üzerinde işlem yapabiliyor. PHP Foundation, bir use-after-free ve bir worker çökmesinin doğrulandığını, rapor eden tarafın Apache ve mod_php ile çalışan gerçek bir uygulamaya karşı uzaktan kod çalıştırmayı gösterdiğini bildiriyor. PHP-FPM üzerinde de uygulama düzeyindeki kod yollarıyla çalıştırma doğrulandı.

Her iki açık da, kimlik doğrulaması yapılmamış bir isteğin bir PHP worker içinde, o worker'ın halihazırda sahip olduğu izinlerle rastgele kod çalıştırmasına imkân tanıyor. Web isteklerine yanıt veren her kurulum açığa maruz kalıyor; buna PHP-FPM, Apache ile mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil. PHP'nin kendi duyurusu en yüksek riski mod_php olarak değerlendiriyor, çünkü bu yapılandırmada gösterilmiş bir sömürü, herhangi bir uygulama kodu çalışmadan önce devreye giriyor; dolayısıyla uygulama tarafı yamalar ve firewall kuralları saldırıyı hiç göremiyor. AWS, bülteninde etkiyi etkilenen worker ve onun uygulama izinleriyle sınırlı olarak tanımladı ve o ana kadar müşteriler arası bir yayılma tespit edilmediğini belirtti.

Yumağı açılan bir iflasa

Netics'in yeniden yapılandırdığı zaman çizelgesi şöyle: 20 Ekim'de saat 15:00 UTC civarında iki CVE tanımlayıcısı forumlarda ve sosyal medyada dolaşmaya başladı; yanlış bir 10.0 puanı (gerçek değer 9.2) ve hatalı bir sürüm saatiyle birlikte. PHP, saat 19:30 UTC'de bir ön duyuruyla yanıt verdi ve sürümü bir gün öne aldı; gerekçesi, dağıtımcıların hâlâ düzeltmeleri paketlediği ve derhal yapılacak bir sürümün kullanıcılara güncelleme yolu bırakmayacağıydı. Saat 20:00 UTC civarında, rapor eden firmalardan Calif, yanlışlıkla bir proof-of-concept videosu yayımladı ve video yayıldı. 21 Ekim'de saat 07:41 UTC'de, koordineli saat diliminden altı saatten fazla önce Chainguard düzeltmeyi içeren derlenmiş imajlar yayımladı; bu da diğer kullanıcılar beklerken herkesin yamayı ikili formda incelemesine imkân tanıdı. CERT-EU gerçek sürümü 13:30 UTC olarak kaydediyor; bu da duyurulan 14:00 saatinden yarım saat önce. PHP, sürüm anında işlevsel bir sömürü görmediğini söylüyor; bu, kısa bir zaman aralığını kapsayan dar kapsamlı bir ifade.

Yama ve ara süreç hafifletme önlemleri

Etkilenen aralıklar 8.5.0–8.5.11, 8.4.0–8.4.26, 8.3.0–8.3.35 ve 8.2.0–8.2.34; 8.2'den eski her şey destek dışı. AWS, PHP 5.4'ten 8.1'e kadar olan sürümlerde upstream düzeltme bulunmadığını ve geçiş yapılması gerektiğini listeliyor; ancak PHP, kaynaktan derleme yapan ekipler için 7.4, 8.0 ve 8.1'e yönelik minimal kaynak geri taşımaları (backport) yayımladı. Dağıtım paketleri her dağıtımcının kendi takvimini izliyor, dolayısıyla yönetilen sunucular upstream sürümünün gerisinde kalabiliyor. CERT-EU ayrıca, PHP'yi hiçbir zaman kurulabilir bir paket olarak açığa çıkarmadan gömülü bulunduran üçüncü taraf ürünlere dikkat çekiyor; standart envanterlerin genellikle gözden kaçırdığı, NCSC-NL deposunda izlenen bir kategori bu.

Güncelleme beklemek zorunda kalınan yerlerde PHP, saldırının tetikleyicisini kaldırmayı öneriyor: memory_limit değerini php_admin_value üzerinden -1 yapın, dosya yükleminin gerekmediği yerlerde post_max_size'ı 8M ile, gerektiği yerlerde 32M ile sınırlayın, upload_max_filesize'ı bunun altında tutun ve kodu çözülmüş istek boyutu, alan sayısı, multipart parçaları, başlıklar ve iç içe derinlik sınırlarını web sunucusunda ya da proxy'de zorunlu kılın. Bu proxy kuralları bellek değişikliği kadar önemli, çünkü sınırsız bir bellek limiti, tek bir dikkatsiz isteğin makineyi tüketebileceği anlamına geliyor.

Neden önemli

PHP web'in büyük bir bölümünü çalıştırıyor ve bu açıklar, neredeyse her isteğin dokunduğu, kimlik bilgisi olmadan erişilebilen bellek yönetimi ve hata işleme kodunda yatıyor. Bellek hatasının geçmişi de bir uyarı: en erken belirtiler 2024 tarihli bir dış denetimden gelmişti ama tam etki ancak Ağustos 2026'da anlaşıldı; PHP Foundation bu boşluğu güvenlik ekibinin karar alma biçimindeki yapısal sorunlara ve kronik kaynak eksikliğine bağlıyor. İfşanın kendisi, tanımlayıcılar sızdıktan sonra ambargo koordinasyonunun ne kadar kırılganlaştığını gösteriyor; zira tek bir üreticinin erken ikili yayımı fiilen diğer herkesin penceresini kısalttı. Operatörler içinse gizli görev, cihazların ve üçüncü taraf yazılımların içine gömülü PHP'yi bulmak; bunu paket tabanlı hiçbir envanter kendi başına ortaya çıkarmayacak.