PHP2Shell: Kritik PHP açıkları en çok mod_php sunucularını etkiliyor

PHP, iki açığın ayrıntılarının bir gün önce Hacker News'te sızmasının ardından güvenlik güncellemesinin yayımlanmasını 21 Ekim Çarşamba günü saat 14.00 UTC'ye çekti. Düzeltmeler PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerinde sunuluyor. Her iki hata da bir CMS'de değil, doğrudan yorumlayıcıda bulunuyor. PHP'nin CVE-2026-109618 ve CVE-2026-109619 için yayımladığı güvenlik duyuruları, her bir açığı CVSS 4.0 kapsamında 9,2 puanla değerlendiriyor ve kimlik doğrulama olmadan web işçi sürecinin yetkileriyle uzaktan kod yürütülebildiğini doğruluyor.

Bellek yetersizliğinin ele alınış biçimi, belleği kısmen başlatılmış durumda bırakıyor

İlk açık, PHP'nin bellek yetersizliği hatalarını nasıl ele aldığından kaynaklanıyor. Bellek yetersizliği (OOM) durumunda yorumlayıcı, o anda isteğe ait bellek yalnızca kısmen başlatılmış olsa bile mevcut bağlamdan çıkmak için longjmp() kullanıyor. Ardından sonlandırma prosedürü bu durumu geçerli kabul ederek okuyor. Bir saldırgan, post_max_size sınırının altında kalan çok parçalı bir istekle OOM durumunu tetikleyebiliyor; örneğin her parçada sınırsız sayıda başlık, max_file_uploads sınırına dahil edilmeyen boş dosya alanları veya iç içe alan adları kullanabiliyor. Yama, longjmp() yerine bir sonraki VM güvenli noktasında kontrollü bir OOM işleme mekanizması, ikinci ve daha yüksek bir eşik aşıldığında ise doğrudan _exit() çağrısı kullanıyor.

İkinci açık, bir istek sona erdikten sonra da varlığını sürdüren genel durumla ilgili. Ölümcül bir hata, bir işlemi durumunu sıfırlamadan önce durdurursa genel bir alan, serbest bırakılmış öbek belleğini işaret etmeye devam ediyor. Aynı işçi sürecindeki bir sonraki istek, normal başlatma işlemlerinden önce bu değeri okuduğunda serbest bırakılmış belleğin kullanımı (use-after-free) ortaya çıkıyor. PHP, doğrulanmış iki yol sıralıyor: PHP 8.5'teki fatal_error_backtraces ayarı ve varsayılan olarak etkin olan, uygulamanın session_start() çağrısı yapmasını gerektirmeyen oturum yükleme ilerlemesi özelliği.

mod_php neden en fazla risk altında?

mod_php kullanan Apache, isteğin başlatılması zaten başarısız olmuş olsa bile istek sonlandırma prosedürünü çağırıyor. PHP istek gövdesini ayrıştırırken belleğin tükenmesi yeterli oluyor ve hiçbir uygulama kodunun çalışması gerekmiyor. PHP, varsayılan bellek ve girdi sınırlarıyla mod_php üzerinde tam kod yürütmeyi doğruladı. PHP-FPM, başlatılması başarısız olan alt süreci sonlandırarak bu doğrudan yolu engelliyor. İkinci açık içinse PHP, normal bir FPM havuzuna karşı istismarı yine de doğruladı; ancak bu, uygulamada uygun bir işlemin bulunmasına bağlı. Kaynak kod analizi, FrankenPHP'nin mod_php gibi davrandığını, LSAPI'nin ise belirli koşullarda etkilenebileceğini gösteriyor. CVSS vektöründeki yüksek saldırı karmaşıklığı, PHP derlemesinin ve öbek belleği düzeninin istismarın güvenilirliğini etkilemesini yansıtıyor.

İstismar girişimleri ve yapay zekânın rolü

watchTowr, her iki açığa yönelik aktif istismar girişimleri gözlemlediğini söylüyor. Cloudflare ise The Hacker News'e, yama yayımlanmadan önce ilk saldırıları gördüğünü belirtti. Şu ana kadar başarıyla ele geçirilmiş bir sistem doğrulanmadı. Buna rağmen DigiD ve MijnOverheid dahil Hollanda kamu hizmetleri önlem olarak çevrimdışı oldu. Birleşik Krallık'ın NCSC kurumu da başka seçenek yoksa yama uygulanmamış sistemlerin çevrimdışı bırakılmasını tavsiye ediyor.

Wiz Research, hataları buldu ve 24 Ağustos'ta bildirdi. Wiz'e göre Gemini 4 Argon ve GPT-5.6 Sol; keşif, istismar geliştirme ve yama doğrulama çalışmalarına, özellikle de istismarın her hedefe göre ayarlanmasına yardımcı oldu. Wiz, keşif ve koordinasyona katkıları için OpenAI ve Calif'e de teşekkür ediyor. Bu durum, Anthropic'in yakın zamanda ucuz TV kutularını hedef alan, kendini kopyalayan yapay zekâ hakkında yazdıklarıyla örtüşüyor; orada da modeller saldırı gerçekleştirmeyi kolaylaştırıyor.

Yöneticiler şimdi ne yapmalı?

Tek eksiksiz çözüm güncelleme yapmak. Linux dağıtımları ve LTS sağlayıcıları yamaları önceden aldı ve bunları çoğu zaman eski sürüm numaraları altında önceki sürümlere uyarlıyor. Bu nedenle sürüm dizesi yerine değişiklik günlüğünde CVE kimliklerini kontrol edin. Artık desteklenmeyen 7.4, 8.0 ve 8.1 dalları için yalnızca asgari düzeyde kaynak kodu uyarlamaları sunuluyor. Hemen güncelleme yapamıyorsanız PHP, yönetici düzeyinde memory_limit=-1 ayarının uygulanmasını öneriyor; çünkü doğrulanmış OOM istismarının çalışmasını sağlayan unsur, istek başına öngörülebilir bir sınır bulunması. session.upload_progress.enabled=0 ve PHP 8.5'te fatal_error_backtraces=0 ayarlarını ekleyin, ardından tüm işçi süreçlerini yeniden başlatın. Uygulamanız çok parçalı formlar kullanmıyorsa bunları ön uçta engelleyin. Bu ayarların hiçbiri eksiksiz bir çözüm değil. Paylaşımlı barındırma hizmetinde veya web sunucusu bulunan bir NAS üzerinde, sağlayıcınızın hangi PHP sürümünü sunduğunu kontrol edin.