PHP, web sunucularında yetkisiz uzaktan kod çalıştırmaya izin veren iki kritik güvenlik açığı için acil güncellemeler yayınladı. Topluca PHP2Shell olarak adlandırılan açıklar, PHP dilinin kendisinde bulunuyor ve saldırganın hesap sahibi olmadan sunucuda kod çalıştırmasına olanak tanıyor. Düzeltmeler PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerinde yer alıyor. PHP ekibi, sunucunun tam olarak korunması için yalnızca güncelleme yapılması gerektiğini belirtiyor. Açıklar 21 Ekim saat 14:00 UTC civarında, 22 Ekim olarak planlanan açıklamadan bir gün önce sızıntının ardından duyuruldu. Her iki açık da CVSS v4.0 ölçeğinde 9.2 puanla derecelendirildi ve CVE-2026-109618 ile CVE-2026-109619 kodlarını taşıyor.
Danışma metni, web isteklerini işleyen her PHP kurulumunun risk altında olduğunu belirtiyor. Etkilenen yapılar arasında PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed bulunuyor. Açıklar neredeyse PHP 5.4'e kadar uzanan tüm sürümleri etkiliyor.
Riskin en yüksek olduğu yapı Apache mod_php olarak gösteriliyor. Bu yapıda çalışan bir istismarda, tek bir yetkisiz istek, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetikleyebiliyor. PHP-FPM ise farklı davranıyor; istek kurulumun erken aşamasında başarısız olduğunda çalışan işlemi kapatıyor. PHP'nin kendi analizine göre, iki açıktan biri için FPM'nin savunmasız olduğu doğrulanıyor ancak tam bir FPM istismarı gösterilmiş değil. İkinci açıkta ise hem mod_php hem de PHP-FPM üzerinde kod çalıştırmaya ulaşıldı, ancak FPM yolunda çalışan uygulama içindeki bir işleme bağlı kalınıyor.
Araştırmacılar ayrıca kod çalıştırmaya gerek kalmadan PHP çalışan sürecinin belleğini okumanın mümkün olduğunu gösterdi. Bu bellek, diğer isteklere ait parolalar, kimlik doğrulama jetonları, API anahtarları ve sertifikaları içerebiliyor. Bellek okuma gösterimi, araştırmacıların kontrol etmediği uygulamalar üzerinde de gerçekleştirildi ve bu durumun üstte çalışan uygulamadan bağımsız olduğu vurgulandı.
Güncellenmesi gereken dallar ve ilk düzeltilmiş sürümler şöyle:
Linux dağıtımları ve uzun süreli destek sunan satıcılar yamaları önceden aldı. Bu nedenle dağıtım paketi, eski görünen bir sürüm numarası altında düzeltmeyi içerebiliyor. Debian'ın da önerdiği gibi sürüm numarasına değil, paket değişiklik günlüğündeki CVE kaydına bakılması gerekiyor.
Güncelleme sonrası bellek ayarlarının gözden geçirilmesi öneriliyor. Düzeltme ile birlikte yeni bir katı bellek sınırı eklendi ve bu sınıra ulaşılması süreci sonlandırıyor ve kapatma işleyicilerinin çalışmasını durduruyor. Bu nedenle memory_limit ve post_max_size değerlerinin uygulamanın ihtiyaçlarına göre kontrol edilmesi gerekiyor.
CVE-2026-109618 için memory_limit değerinin -1 olarak ayarlanarak uygulamaların bunu geçersiz kılmasının engellenmesi, post_max_size değerinin düşük tutulması ve web sunucusu veya vekil sunucuda istek boyutu sınırlarının uygulanması öneriliyor. PHP, RLIMIT_AS veya RLIMIT_DATA kullanımının aynı savunmasız yolu tetikleyebileceği konusunda uyarıyor ve bunların alternatif olarak kullanılmaması gerektiğini belirtiyor.
CVE-2026-109619 için session.upload_progress.enabled değerinin 0 olarak ayarlanması ve tüm çalışanların yeniden başlatılması, PHP 8.5 üzerinde ayrıca fatal_error_backtraces değerinin 0 yapılması isteniyor. Oturum yükleme ilerlemesini kapatmak, doğrulanmış oturum yollarını engelliyor ancak diğer varyantları engellemiyor ve güncelleme dışında hiçbir yapılandırma değişikliği bu açığı tam olarak hafifletmiyor. Bu ayar, yama öncesinde geçici çözüm olarak dolaşıma girmişti ve sürüm notları bunun hiçbir zaman tam bir düzeltme olmadığını doğruluyor.
Oturum yükleme ilerlemesi varsayılan olarak açık geliyor ve PHP bir isteğin kurulumunu tamamlamadan önce oturum işlemlerine ulaşabiliyor. Bu nedenle CVE-2026-109619 için doğrulanmış bir saldırı yolunda rol oynuyor ve kapatılması CVE-2026-109618 için bir etki yaratmıyor.
PHP çekirdek geliştiricisi Gina Peter Banyard, sürüm öncesi yaptığı açıklamada bu ayarın yeterli olabileceği önerisine yanıt vererek, "Söyleyebileceğim tek şey, tek hafifletmenin PHP'yi yamalamak/güncellemek olduğu. Ne yazık ki çok fazla şey biliyorum" ifadelerini kullandı.
21 Ekim saat 11:26 UTC itibarıyla hiçbir kaynak başarılı bir ihlali doğrulamadı. CVE-2026-109618'i yeniden üreten watchTowr, o saat itibarıyla vahşi ortamda istismar görmediğini bildirdi ve her iki açık da o sırada CISA'nın Bilinen İstismar Edilen Açıklar kataloğunda yer almıyordu.
Bazı kuruluşlar bir ihlale yanıt olarak değil, önlem amacıyla hizmetlerini çevrimdışı hale getirdi. BambooHR, Amerika Birleşik Devletleri, Kanada ve İrlanda genelinde hizmetini durdurdu, bordro işlemlerinin kesintiye uğrayacağı uyarısında bulundu ve henüz bir geri yükleme zamanı veremediğini açıkladı. Hollanda'da ise yayıncı NOS'un aktardığına göre MijnOverheid, DigiD, Temsilciler Meclisi'nin sitesi, ulusal siber güvenlik merkezi ve çeşitli eğitim sistemleri çevrimdışı oldu; merkez açığın istismar edildiğini görmediğini ancak herkese yama yapma çağrısı yaptığını bildirdi.
Yama yapıldığı halde daha önceki bir ihlalden şüphelenenler için araştırmacılar, bellek sınırı hataları veya tekrarlanan HTTP 500 yanıtlarının izlediği olağandışı multipart istekleri, alışılmadık derecede büyük PHPSESSID yanıt çerezleri ve PHP çalışanlarının açıklanamayan yeniden başlatmalarının izlenmesini öneriyor.
Açıklar Wiz Research, Calif ve OpenAI Codex Security ekibi tarafından bulundu ve raporlandı. Düzeltme üzerinde PHP güvenlik ekibi ve Google Gemini ekibi birlikte çalıştı. Altta yatan kodun PHP'de on yıldan uzun süredir bulunduğu belirtiliyor.
Araştırmacılar, yapay zeka modellerinin bu uzun süredir var olan açıkları çalışan istismarlara dönüştürmeye yardımcı olduğunu, bir araştırmacının aksi halde bir ekibin aylar sürecek çalışmasını yaklaşık bir haftada tamamlayabildiğini ifade ediyor. Calif, hatanın kökenini 2004 yılındaki PHP araştırmalarına kadar izlediğini, hedefin geçmişini bilmenin hala önemli olduğunu ve mevcut modellerin tek başına yirmi yıllık belirsiz ilkel yapılardan güvenilir şekilde başlayamadığını belirtiyor.
PHP2Shell Açıkları Nedir ve Kimler Etkileniyor
PHP güvenlik danışma metnine göre açıklar herhangi bir uygulamada değil, doğrudan PHP çalışma ortamında yer alıyor. Bu nedenle bir sitenin kendi kodu güvenli olsa bile, altta çalışan PHP sürümü savunmasızsa site saldırıya açık hale geliyor. Basit bir "Hello World" sayfası bile savunmasız bir PHP sürümünde hedef alınabiliyor.Danışma metni, web isteklerini işleyen her PHP kurulumunun risk altında olduğunu belirtiyor. Etkilenen yapılar arasında PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed bulunuyor. Açıklar neredeyse PHP 5.4'e kadar uzanan tüm sürümleri etkiliyor.
Riskin en yüksek olduğu yapı Apache mod_php olarak gösteriliyor. Bu yapıda çalışan bir istismarda, tek bir yetkisiz istek, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetikleyebiliyor. PHP-FPM ise farklı davranıyor; istek kurulumun erken aşamasında başarısız olduğunda çalışan işlemi kapatıyor. PHP'nin kendi analizine göre, iki açıktan biri için FPM'nin savunmasız olduğu doğrulanıyor ancak tam bir FPM istismarı gösterilmiş değil. İkinci açıkta ise hem mod_php hem de PHP-FPM üzerinde kod çalıştırmaya ulaşıldı, ancak FPM yolunda çalışan uygulama içindeki bir işleme bağlı kalınıyor.
Araştırmacılar ayrıca kod çalıştırmaya gerek kalmadan PHP çalışan sürecinin belleğini okumanın mümkün olduğunu gösterdi. Bu bellek, diğer isteklere ait parolalar, kimlik doğrulama jetonları, API anahtarları ve sertifikaları içerebiliyor. Bellek okuma gösterimi, araştırmacıların kontrol etmediği uygulamalar üzerinde de gerçekleştirildi ve bu durumun üstte çalışan uygulamadan bağımsız olduğu vurgulandı.
Hangi Sürümler Güncellenmeli ve Ne Yapılmalı
PHP ekibi, web isteklerini karşılayan PHP çalışma ortamının güncellenmesini ve ardından Apache, PHP-FPM ile uzun süre çalışan tüm PHP işlemlerinin yeniden başlatılmasını istiyor. WordPress veya Laravel gibi bir uygulamayı güncellemenin, alttaki PHP çalışma ortamını güncellemediği özellikle vurgulanıyor; bu güncelleme sunucu paketinden, barındırma sağlayıcısından veya konteyner imajından geliyor.Güncellenmesi gereken dallar ve ilk düzeltilmiş sürümler şöyle:
- 8.5 sürümünde 8.5.12 öncesi sürümler savunmasız, düzeltme 8.5.12
- 8.4 sürümünde 8.4.27 öncesi sürümler savunmasız, düzeltme 8.4.27
- 8.3 sürümünde 8.3.36 öncesi sürümler savunmasız, düzeltme 8.3.36
- 8.2 sürümünde 8.2.35 öncesi sürümler savunmasız, düzeltme 8.2.35
Linux dağıtımları ve uzun süreli destek sunan satıcılar yamaları önceden aldı. Bu nedenle dağıtım paketi, eski görünen bir sürüm numarası altında düzeltmeyi içerebiliyor. Debian'ın da önerdiği gibi sürüm numarasına değil, paket değişiklik günlüğündeki CVE kaydına bakılması gerekiyor.
Güncelleme sonrası bellek ayarlarının gözden geçirilmesi öneriliyor. Düzeltme ile birlikte yeni bir katı bellek sınırı eklendi ve bu sınıra ulaşılması süreci sonlandırıyor ve kapatma işleyicilerinin çalışmasını durduruyor. Bu nedenle memory_limit ve post_max_size değerlerinin uygulamanın ihtiyaçlarına göre kontrol edilmesi gerekiyor.
Güncelleme Yapılamıyorsa Alınabilecek Geçici Önlemler
Danışma metnine göre yalnızca güncelleme tam bir düzeltme sağlıyor. Aşağıdaki önlemler belirli saldırı yollarına karşı maruziyeti azaltıyor ancak sunucuyu güvenli hale getirmiyor.CVE-2026-109618 için memory_limit değerinin -1 olarak ayarlanarak uygulamaların bunu geçersiz kılmasının engellenmesi, post_max_size değerinin düşük tutulması ve web sunucusu veya vekil sunucuda istek boyutu sınırlarının uygulanması öneriliyor. PHP, RLIMIT_AS veya RLIMIT_DATA kullanımının aynı savunmasız yolu tetikleyebileceği konusunda uyarıyor ve bunların alternatif olarak kullanılmaması gerektiğini belirtiyor.
CVE-2026-109619 için session.upload_progress.enabled değerinin 0 olarak ayarlanması ve tüm çalışanların yeniden başlatılması, PHP 8.5 üzerinde ayrıca fatal_error_backtraces değerinin 0 yapılması isteniyor. Oturum yükleme ilerlemesini kapatmak, doğrulanmış oturum yollarını engelliyor ancak diğer varyantları engellemiyor ve güncelleme dışında hiçbir yapılandırma değişikliği bu açığı tam olarak hafifletmiyor. Bu ayar, yama öncesinde geçici çözüm olarak dolaşıma girmişti ve sürüm notları bunun hiçbir zaman tam bir düzeltme olmadığını doğruluyor.
Oturum yükleme ilerlemesi varsayılan olarak açık geliyor ve PHP bir isteğin kurulumunu tamamlamadan önce oturum işlemlerine ulaşabiliyor. Bu nedenle CVE-2026-109619 için doğrulanmış bir saldırı yolunda rol oynuyor ve kapatılması CVE-2026-109618 için bir etki yaratmıyor.
PHP çekirdek geliştiricisi Gina Peter Banyard, sürüm öncesi yaptığı açıklamada bu ayarın yeterli olabileceği önerisine yanıt vererek, "Söyleyebileceğim tek şey, tek hafifletmenin PHP'yi yamalamak/güncellemek olduğu. Ne yazık ki çok fazla şey biliyorum" ifadelerini kullandı.
Saldırı Girişimleri Gözlendi, Bazı Hizmetler Önlem Amaçlı Kapandı
Yama yayınlanmadan önce Cloudflare, açıkları istismar etmeye yönelik erken girişimler gördüğünü açıkladı. Cloudflare CTO'su Dane Knecht, "Erken saldırılar ortaya çıkarken görüyoruz ve yeni vektörler ortaya çıktıkça hafifletmeleri güncelliyoruz" dedi ve devreye alınan güvenlik duvarı kurallarını geçici bir önlem olarak nitelendirerek yöneticilere yama yapma çağrısında bulundu.21 Ekim saat 11:26 UTC itibarıyla hiçbir kaynak başarılı bir ihlali doğrulamadı. CVE-2026-109618'i yeniden üreten watchTowr, o saat itibarıyla vahşi ortamda istismar görmediğini bildirdi ve her iki açık da o sırada CISA'nın Bilinen İstismar Edilen Açıklar kataloğunda yer almıyordu.
Bazı kuruluşlar bir ihlale yanıt olarak değil, önlem amacıyla hizmetlerini çevrimdışı hale getirdi. BambooHR, Amerika Birleşik Devletleri, Kanada ve İrlanda genelinde hizmetini durdurdu, bordro işlemlerinin kesintiye uğrayacağı uyarısında bulundu ve henüz bir geri yükleme zamanı veremediğini açıkladı. Hollanda'da ise yayıncı NOS'un aktardığına göre MijnOverheid, DigiD, Temsilciler Meclisi'nin sitesi, ulusal siber güvenlik merkezi ve çeşitli eğitim sistemleri çevrimdışı oldu; merkez açığın istismar edildiğini görmediğini ancak herkese yama yapma çağrısı yaptığını bildirdi.
Yama yapıldığı halde daha önceki bir ihlalden şüphelenenler için araştırmacılar, bellek sınırı hataları veya tekrarlanan HTTP 500 yanıtlarının izlediği olağandışı multipart istekleri, alışılmadık derecede büyük PHPSESSID yanıt çerezleri ve PHP çalışanlarının açıklanamayan yeniden başlatmalarının izlenmesini öneriyor.
Sızıntı Yayın Takvimini Öne Çekti
Açıkların duyurusu bir sızıntı nedeniyle öne alındı. The Hacker News'in aktardığına göre 20 Ekim'de Hacker News'te, iki PHP uzaktan kod çalıştırma açığının iki CVE kimliğiyle birlikte 22 Ekim'de açıklanmasının planlandığına dair bir paylaşım yapıldı. PHP o akşam bir ön bildirim yayınladı ve sürümü 21 Ekim'e çekti. Sızıntıda yer alan CVSS 10.0 puanı iddiası PHP'ye ait değildi; PHP her iki açığı da 9.2 olarak derecelendirdi.Açıklar Wiz Research, Calif ve OpenAI Codex Security ekibi tarafından bulundu ve raporlandı. Düzeltme üzerinde PHP güvenlik ekibi ve Google Gemini ekibi birlikte çalıştı. Altta yatan kodun PHP'de on yıldan uzun süredir bulunduğu belirtiliyor.
Araştırmacılar, yapay zeka modellerinin bu uzun süredir var olan açıkları çalışan istismarlara dönüştürmeye yardımcı olduğunu, bir araştırmacının aksi halde bir ekibin aylar sürecek çalışmasını yaklaşık bir haftada tamamlayabildiğini ifade ediyor. Calif, hatanın kökenini 2004 yılındaki PHP araştırmalarına kadar izlediğini, hedefin geçmişini bilmenin hala önemli olduğunu ve mevcut modellerin tek başına yirmi yıllık belirsiz ilkel yapılardan güvenilir şekilde başlayamadığını belirtiyor.
Yazılım ve Uygulamalar
Yazılım ve Uygulamalar
Yazılım ve Uygulamalar
Yorumlar (0)
Yorum yapmak için giriş yapmalısınız.