PHP’nin çekirdeğinde ortaya çıkan ve kimlik doğrulaması gerektirmeyen CVE-2026-109618 ile ilişkili hata, web sunucularını otomatik taramalarda açık hedefe çevirdi. Güvenlik araştırmacıları, multipart/form-data işleme yolunda oluşan heap use-after-free kusurunun saldırganlara uzaktan kod yürütme imkânı verebildiğini ve interneti tarayan botların zafiyeti kısa sürede yoklamaya başladığını aktarıyor.
Hata, PHP’nin HTTP üzerinden gönderilen çok parçalı form gövdelerini ele alış biçiminde ortaya çıkıyor. Aynı hatayla birlikte anılan CVE-2026-109619 de dosya yükleme akışını etkileyen bellek yönetimi sorunları arasında yer alıyor. Saldırı için kullanıcı adı, parola ya da özel bir panel gerekmiyor; herhangi bir .php uç noktasına gönderilen tek bir zararlı POST isteği yeterli olabiliyor.
Tehlikeyi büyüten unsur, PHP’de session.upload_progress.enabled seçeneğinin uzun süredir varsayılan olarak açık gelmesi. PHP 5.4 sürümünden bu yana etkin olan bu özellik, dosya yükleme sırasında ilerleme bilgisini oturum üzerinden izlemek için kullanılıyor. Güvenlik çevrelerinde paylaşılan teknik değerlendirmeye göre, çoğu web sitesi bu yerleşik mekanizmayı hiç kullanmıyor ve modern JavaScript tabanlı yükleme araçlarına yöneliyor.
Bu nedenle saldırganların hedefinde yalnızca güncel olmayan sistemler yok. Eski PHP sürümleri çalışan sunucular daha yüksek risk taşısa da, temel problem zafiyetin uygulama katmanında değil çekirdeğin kendisinde yer alması. Yeraltı forumlarında dolaşan ve php2shell benzeri istismar araçlarının hızla türediği bilgisi de otomatik sömürü ihtimalini artırıyor. Bu araçlar, saldırganların savunmasız makineleri tarayıp botnet ağına, madencilik operasyonlarına ya da başka bir kötü amaçlı yüke bağlamasına imkân tanıyabiliyor.
Özellikle EOL, yani güvenlik desteği kesilmiş sürümler, saldırı yüzeyinin en görünür kısmını oluşturuyor. Küresel taramalara göre aktif web sitelerinin yaklaşık %25’i hâlâ PHP 5.4, 5.6, 7.0, 7.4 ve 8.0 gibi artık yama almayan sürümlerde çalışıyor. Resmî PHP geliştiricileri bu sürümler için yeni güvenlik güncellemesi yayınlamıyor. Bu da eski yazılımları barındıran sunucuları, internet üzerindeki rastgele taramalarda kolay bulunur hedefler hâline getiriyor.
Resmî paketlerin dağıtıcılar üzerinden sunuculara ulaşması saatler, kimi zaman günler alabiliyor. Bu nedenle birçok sistem yöneticisi, yama gelene kadar saldırı yüzeyini daraltacak geçici ayarlara yöneliyor. En sık önerilen adım, session.upload_progress.enabled özelliğini kapatmak. Linux ortamında bu ayar, kalıcı bir drop-in dosyasıyla örneğin /etc/php.d/99-security-hardening.ini ya da Plesk altında ilgili php.d dizinleri üzerinden Off konumuna çekiliyor.
Ardından web ve PHP-FPM servislerinin kesintiye yol açmadan yeniden yüklenmesi öneriliyor. Verilen örnekte systemctl reload-or-try-restart httpd nginx php-fpm komutu kullanılıyor. Windows tarafında ise ilgili php.ini dosyasında aynı satır düzenleniyor; ardından php-cgi süreçleri sonlandırılıyor ve IIS için W3SVC servisi yeniden başlatılıyor. Bu adımların amacı, web uygulamasını tamamen durdurmadan PHP’nin dosya yükleme ilerleme mekanizmasını devre dışı bırakmak.
WAF katmanında da benzer bir sıkılaştırma yapılıyor. ModSecurity, Cloudflare ya da kurum içi güvenlik duvarı kurallarında PHP_SESSION_UPLOAD_PROGRESS parametresi taşıyan, ayrıca alışılmadık uzunlukta payload ya da PHP fonksiyon çağrısı izleri bulunan POST isteklerinin doğrudan engellenmesi isteniyor. Böylece istismar denemeleri uygulama katmanına ulaşmadan 403 yanıtıyla kesilebiliyor.
Sunucunun daha önce yoklanıp yoklanmadığını anlamak için erişim günlükleri de taranıyor. Teknik ekipler, grep -i "PHP_SESSION_UPLOAD_PROGRESS" /var/log/httpd/*access_log komutuyla loglarda bu parametreye yönelik istekleri ayıklıyor. Özellikle kaynağı belirsiz dış IP’lerden gelen yoğun POST trafiği, otomatik keşif faaliyeti olarak değerlendiriliyor.
PHP topluluğunda ve sistem yönetimi çevrelerinde konuşulan asıl başlık, kalıcı çözümün sürüm yenilemesi olduğunda birleşiyor. Eski sürümler geçici ayarlarla bir süre korunabilse de, yeni bellek hatalarına karşı yine savunmasız kalıyorlar. Bu yüzden PHP 8.1, 8.2 veya 8.3 ile uyumlu uygulama ve eklenti setlerine geçiş, kurumsal barındırma ortamlarında artık ertelenen bir bakım işi olmaktan çıkmış durumda.
Dağıtıcıların yayımladığı güvenlik bültenlerinin düzenli takip edilmesi de başka bir basamak olarak öne çıkıyor. CloudLinux, Red Hat, Ubuntu ve Debian tabanlı sistemlerde güvenlik paketlerinin gecikmeden uygulanması gerektiği vurgulanıyor. Çoklu sunucu yöneten ekipler için merkezi izleme araçları da gündemde. Bu sistemler, alan adlarının PHP sürümlerini tek ekranda raporluyor ve anormal segfault artışlarını izleyebiliyor.
Şimdilik ortada, çekirdekteki bellek hatasının nasıl istismar edildiğine ilişkin teknik detaylarla otomatik taramanın birleştiği bir tablo var. Yetkisiz erişim gerektirmemesi ve varsayılan olarak açık bir özelliği hedeflemesi, zafiyeti sıradan bir uygulama açığından çıkarıp geniş ölçekli bir internet sorunu hâline getiriyor. Güvenlik ekipleri ise ilk aşamada gözlerini, değişmeyen sürümlere ve loglarda beliren şüpheli POST trafiğine çevirmiş durumda.