Melih Çat

PHP tarafında bugün oldukça ciddi bir güvenlik problemiyle karşı karşıyayız. Biraz teknik detaylara girmek istiyorum çünkü sosyal medyada dolaşan bazı çözüm önerileri, güvenlik açığının kendisi kadar problem yaratabilecek durumda. PHP Security Team, CVSS v4.0 skoru 9.2 olan iki kritik açık için bugün Türkiye saatiyle 17.00’de acil güvenlik güncellemesi yayımlayacak. CVE-2026-109618 ve CVE-2026-109619 olarak raporlanan, php2shell adıyla gündeme gelen açıklara ilişkin RCE demonstrasyonları da paylaşılmaya başlandı. İşin teknik tarafında araştırmacıların işaret ettiği yer oldukça ilginç. PHP’nin ext/session/session.c içerisindeki php_session_rfc1867_callback() fonksiyonu ve session.upload_progress mekanizması. İddialara göre multipart/form-data işlenirken session verilerinin yönetiminde oluşan use-after-free (UAF) hataları, uygun bellek manipülasyonuyla RCE’ye kadar ilerleyebiliyor. Bu mekanizma uygulama kodumuz çalışmadan önce devreye girebildiği için olay yalnızca WordPress, Laravel, Symfony veya herhangi bir framework’e özgü değil. PHP runtime seviyesinde bir problemden bahsediyoruz. Dolayısıyla Laravel middleware’lerine güvenmek, CSRF kontrolü eklemek veya Composer paketlerini güncellemek tek başına çözüm değil. Peki resmi yama gelene kadar ne yapabiliriz? İlk olarak PHP’de varsayılan olarak açık olan aşağıdaki özelliği, uygulamanız kullanmıyorsa geçici olarak devre dışı bırakabilirsiniz: session.upload_progress.enabled = Off Bu ayar normal dosya yüklemelerini kapatmıyor. PHP’nin native session tabanlı upload progress takibini kapatıyor. Ancak önemli bir detay var: Bu özelliğin request initialization aşamasında çalışabilmesi nedeniyle uygulama içerisinden ini_set() kullanmak çözüm değil. Ayar PHP-FPM’in etkin yapılandırmasında veya uygun PHP konfigürasyonunda uygulanmalı. FPM servislerini yeniden yükledikten sonra da ayarın gerçekten web request’lerinde devre dışı olduğunu doğrulamak gerekiyor. CLI’daki php -i çıktısına güvenmek yeterli değil. İkinci konu WAF. Cloudflare üzerinde multipart/form-data isteklerini engelleyen kurallar paylaşılıyor. Fakat bunları production ortamına doğrudan kopyalamak büyük hata. Çünkü WordPress medya yüklemelerinden Laravel dosya upload endpoint’lerine kadar pek çok normal işlem bu Content-Type’ı kullanıyor. PHPSESSID içeren bütün cookie’leri bloklamak ise normal oturumları da etkileyebilir. WAF tarafında kullanılmayan multipart endpoint’lerini kısıtlamak, gerekli endpoint’lerde kuralları dikkatli uygulamak ve logları incelemek çok daha kontrollü bir yaklaşım. Bir de Shodan üzerinde PHP kullanan milyonlarca servis bulunması, hepsinin bu açıklardan etkilendiği anlamına gelmiyor. Etkilenen sürümler henüz resmi olarak açıklanmadı. Benim burada özellikle altını çizmek istediğim şey şu: Bu tip açıklar PHP core seviyesindeyse, uygulamanızın framework sürümünün güncel olması yeterli bir güvenlik garantisi vermiyor. Docker kullananlar da dahil olmak üzere production ortamında gerçekten hangi PHP binary’sinin, hangi FPM pool’unun ve hangi base image’ın çalıştığını bilmek zorundayız. Ayrıca session.upload_progress.enabled = Off şu an yalnızca olası saldırı yüzeyini azaltan geçici bir önlem. Her iki CVE’yi de tamamen engellediği doğrulanmış değil. Asıl çözüm resmi yamanın yayımlanması, etkilenen sürümlerin doğrulanması ve bütün PHP runtime’larının kontrollü şekilde güncellenmesi. PHP 7.x ve 8.0/8.1 gibi desteği bitmiş sürümleri çalıştıranların da bu durumu ayrıca değerlendirmesi gerekiyor. Güvenlikte en tehlikeli şeylerden biri sisteminizin güvende olduğunu varsaymak. Özellikle de kullandığınız framework güncel diye alttaki runtime’ın da güvenli olduğunu düşünüyorsanız. Resmi PHP duyurusu: php.net/archive/2026.php#202…