PHP geliştirici ekibi, web sunucularında hesap gerektirmeksizin uzaktan kod çalıştırmaya imkân veren iki kritik güvenlik açığını gidermek amacıyla acil güncellemeler yayımladı. PHP2Shell olarak adlandırılan bu açıklar, PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleriyle kapatıldı. PHP ekibi, bir sunucuyu tam anlamıyla korumanın tek yolunun güncelleme yapmak olduğunu vurguladı.
CVE-2026-109618 ve CVE-2026-109619 tanımlayıcılarını taşıyan açıkların her ikisi de CVSS v4.0 ölçeğinde 9,2 puan aldı. Açıklar herhangi bir uygulamada değil, PHP çalışma ortamının kendisinde bulunuyor; bu nedenle sitenin kendi kodu güvenli olsa bile sunucu risk altında kalıyor. Açıklar PHP 5.4'e kadar uzanan neredeyse tüm PHP sürümlerini etkiliyor.
En yüksek risk, Apache'nin mod_php yapılandırmasını kullanan sunucularda ortaya çıkıyor. Bu yapılandırmada tek bir kimliği doğrulanmamış istek, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetikleyebiliyor. PHP-FPM ise bir istek kurulum aşamasında erken başarısız olduğunda işçi süreci kapattığından farklı davranıyor. PHP'nin kendi analizine göre FPM her iki açıktan da etkileniyor; ancak ikinci açık için FPM üzerinden kod çalıştırma yolu, çalışan uygulama içindeki bir işleme bağımlı.
Saldırganlar, kod çalıştırmadan önce PHP işçi sürecinin belleğini okuyabiliyor. Bu bellekte diğer isteklere ait parolalar, kimlik doğrulama belirteçleri, API anahtarları ve sertifikalar bulunabilir. Araştırmacılar, bu bellek okuma yöntemini kendi kontrollerinde olmayan uygulamalara karşı da başarıyla gösterdi.
PHP 8.1 ve daha eski sürümler PHP projesi tarafından artık güncelleme almıyor. PHP güvenlik ekibi, kaynaktan derleme yapanlar ya da satıcı desteğini bekleyenler için PHP 7.4, 8.0 ve 8.1 sürümlerine yönelik kaynak kodu geri aktarımları yayımladı. Linux dağıtımları ve uzun vadeli destek sağlayıcıları yamaları önceden aldığından, bir dağıtım paketi eski görünümlü bir sürüm numarasıyla düzeltmeyi içerebiliyor. Debian'ın tavsiye ettiği gibi sürüm dizesi yerine paket değişiklik günlüğünde CVE numarası aranması öneriliyor.
CVE-2026-109619 için session.upload_progress.enabled=0 olarak ayarlanması ve tüm işçilerin yeniden başlatılması gerekiyor; PHP 8.5 kullanıcılarının ayrıca fatal_error_backtraces=0 ayarını yapması isteniyor. Oturum yükleme ilerlemesini kapatmak yalnızca doğrulanmış oturum yollarını engelliyor, diğer varyantları engellemiyor. PHP çekirdek geliştiricisi Gina Peter Banyard, yama öncesinde yaptığı açıklamada "Söyleyebileceğim tek şey, tek hafifletme önleminin PHP'yi yamalamak/yükseltmek olduğu" dedi.
Bazı kuruluşlar bir ihlale yanıt olarak değil, önlem amacıyla hizmetlerini çevrimdışına aldı. BambooHR, Amerika Birleşik Devletleri, Kanada ve İrlanda'daki hizmetini kapattı ve maaş ödemelerinin kesintiye uğrayabileceği konusunda uyarıda bulundu. Hollanda'da ise NOS'un haberine göre MijnOverheid, DigiD, parlamentonun alt meclisinin sitesi, ulusal siber güvenlik merkezi ve çeşitli eğitim sistemleri çevrimdışına alındı; merkez, açığın kötüye kullanıldığına dair bir kanıt görmediğini açıkladı.
Açıkları bulan ve bildiren Wiz, Calif ve OpenAI'nin Codex Güvenlik ekibi oldu; PHP güvenlik ekibi ve Google'ın Gemini ekibi düzeltme sürecinde yer aldı. Temel kod on yılı aşkın süredir PHP'de bulunuyordu. Araştırmacılar, yapay zeka modellerinin bu uzun süredir var olan açıkları çalışan istismarlara dönüştürmelerine yardımcı olduğunu ve bir araştırmacının yaklaşık bir haftada bir ekibin aylarca süreceğini söylediği işi tamamlamasını sağladığını belirtti.
PHP Vakfı, açığın geçmişine ilişkin yaptığı açıklamada, CVE-2026-109618'in arkasındaki bellek taşması açığına dair ilk işaretlerin PHP'nin 2024 dış denetimi sırasında bir çekirdek geliştirici tarafından fark edildiğini, ancak o dönemde çalışan bir saldırı yolu bulunamadığını aktardı. Vakıf, düzeltme sürecindeki gecikmeyi karar verme sürecinin ve kaynaklarının "yapısal bir başarısızlığı" olarak nitelendirdi ve o tarihten bu yana güvenlik kararlarını alma biçimini değiştirdiğini, benzer sorunları daha erken yakalamak için personel ve araç kapasitesini artırdığını belirtti.
CVE-2026-109618 ve CVE-2026-109619 tanımlayıcılarını taşıyan açıkların her ikisi de CVSS v4.0 ölçeğinde 9,2 puan aldı. Açıklar herhangi bir uygulamada değil, PHP çalışma ortamının kendisinde bulunuyor; bu nedenle sitenin kendi kodu güvenli olsa bile sunucu risk altında kalıyor. Açıklar PHP 5.4'e kadar uzanan neredeyse tüm PHP sürümlerini etkiliyor.
Hangi Sunucular Risk Altında?
PHP güvenlik danışma belgesine göre web isteklerine yanıt veren her PHP kurulumu, yani PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil olmak üzere risk altında. Açıklar PHP motorunun içinde yer aldığından, savunmasız bir PHP sürümü üzerinde çalışan yalnızca "Merhaba Dünya" yazan basit bir sayfa bile saldırıya açık hale gelebiliyor.En yüksek risk, Apache'nin mod_php yapılandırmasını kullanan sunucularda ortaya çıkıyor. Bu yapılandırmada tek bir kimliği doğrulanmamış istek, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetikleyebiliyor. PHP-FPM ise bir istek kurulum aşamasında erken başarısız olduğunda işçi süreci kapattığından farklı davranıyor. PHP'nin kendi analizine göre FPM her iki açıktan da etkileniyor; ancak ikinci açık için FPM üzerinden kod çalıştırma yolu, çalışan uygulama içindeki bir işleme bağımlı.
Saldırganlar, kod çalıştırmadan önce PHP işçi sürecinin belleğini okuyabiliyor. Bu bellekte diğer isteklere ait parolalar, kimlik doğrulama belirteçleri, API anahtarları ve sertifikalar bulunabilir. Araştırmacılar, bu bellek okuma yöntemini kendi kontrollerinde olmayan uygulamalara karşı da başarıyla gösterdi.
Nasıl Güncelleme Yapılmalı?
Web isteklerine yanıt veren PHP çalışma ortamını güncelledikten sonra Apache, PHP-FPM ve uzun süreli çalışan PHP işçilerini yeniden başlatmak gerekiyor. WordPress veya Laravel gibi bir uygulamayı güncellemek, altında çalışan PHP çalışma ortamını güncellemiyor; bu güncelleme sunucu paketi, barındırma hizmeti veya konteyner imajı aracılığıyla yapılıyor.PHP 8.1 ve daha eski sürümler PHP projesi tarafından artık güncelleme almıyor. PHP güvenlik ekibi, kaynaktan derleme yapanlar ya da satıcı desteğini bekleyenler için PHP 7.4, 8.0 ve 8.1 sürümlerine yönelik kaynak kodu geri aktarımları yayımladı. Linux dağıtımları ve uzun vadeli destek sağlayıcıları yamaları önceden aldığından, bir dağıtım paketi eski görünümlü bir sürüm numarasıyla düzeltmeyi içerebiliyor. Debian'ın tavsiye ettiği gibi sürüm dizesi yerine paket değişiklik günlüğünde CVE numarası aranması öneriliyor.
Güncelleme Yapılamazsa Ne Yapılmalı?
Danışma belgesine göre yalnızca güncelleme tam koruma sağlıyor; aşağıdaki önlemler yalnızca belirli saldırı yollarına karşı maruziyeti azaltıyor. CVE-2026-109618 için memory_limit=-1 olarak ayarlanması, post_max_size değerinin düşük tutulması ve web sunucusu ya da proxy düzeyinde istek boyutu sınırlarının uygulanması öneriliyor. RLIMIT_AS veya RLIMIT_DATA kullanılması ise önerilmiyor; PHP, bu ayarların aynı savunmasız yolu tetikleyebileceği konusunda uyarıyor.CVE-2026-109619 için session.upload_progress.enabled=0 olarak ayarlanması ve tüm işçilerin yeniden başlatılması gerekiyor; PHP 8.5 kullanıcılarının ayrıca fatal_error_backtraces=0 ayarını yapması isteniyor. Oturum yükleme ilerlemesini kapatmak yalnızca doğrulanmış oturum yollarını engelliyor, diğer varyantları engellemiyor. PHP çekirdek geliştiricisi Gina Peter Banyard, yama öncesinde yaptığı açıklamada "Söyleyebileceğim tek şey, tek hafifletme önleminin PHP'yi yamalamak/yükseltmek olduğu" dedi.
Sömürü Girişimleri ve Etkilenen Kuruluşlar
Yama çıkmadan önce Cloudflare, açıkları sömürmeye yönelik erken girişimler gözlemlediğini açıkladı. Cloudflare CTO'su Dane Knecht, şirketin güvenlik duvarı kurallarını geçici bir önlem olarak devreye aldığını belirterek yöneticileri yamalamaya davet etti. watchTowr, 21 Ekim UTC 11:26 itibarıyla vahşi ortamda istismar görmediğini bildirdi; ancak aynı gün UTC 14:19'da her iki CVE için "aktif sömürü girişimleri" gözlemlendiğini duyurdu. Bu güncelleme itibarıyla hiçbir kaynak belirli bir sunucunun başarıyla ele geçirildiğini doğrulamadı; her iki açık da CISA'nın Bilinen İstismar Edilen Güvenlik Açıkları kataloğunda yer almıyordu.Bazı kuruluşlar bir ihlale yanıt olarak değil, önlem amacıyla hizmetlerini çevrimdışına aldı. BambooHR, Amerika Birleşik Devletleri, Kanada ve İrlanda'daki hizmetini kapattı ve maaş ödemelerinin kesintiye uğrayabileceği konusunda uyarıda bulundu. Hollanda'da ise NOS'un haberine göre MijnOverheid, DigiD, parlamentonun alt meclisinin sitesi, ulusal siber güvenlik merkezi ve çeşitli eğitim sistemleri çevrimdışına alındı; merkez, açığın kötüye kullanıldığına dair bir kanıt görmediğini açıkladı.
Açıkların Ortaya Çıkışı ve Tarihçesi
Açıklar, planlanan 22 Ekim açıklamasından önce sızdı. 20 Ekim'de Hacker News'te yayımlanan bir gönderi, iki CVE tanımlayıcısıyla birlikte iki PHP uzaktan kod çalıştırma açığının 22 Ekim'de kamuoyuyla paylaşılacağını duyurdu. PHP ekibi o akşam bir ön bildirim yayımlayarak yayımı 21 Ekim'e aldı. Sızıntıda iddia edilen CVSS 10.0 puanı PHP'nin değerlendirmesiyle örtüşmüyor; PHP her iki açığı da 9,2 olarak derecelendirdi.Açıkları bulan ve bildiren Wiz, Calif ve OpenAI'nin Codex Güvenlik ekibi oldu; PHP güvenlik ekibi ve Google'ın Gemini ekibi düzeltme sürecinde yer aldı. Temel kod on yılı aşkın süredir PHP'de bulunuyordu. Araştırmacılar, yapay zeka modellerinin bu uzun süredir var olan açıkları çalışan istismarlara dönüştürmelerine yardımcı olduğunu ve bir araştırmacının yaklaşık bir haftada bir ekibin aylarca süreceğini söylediği işi tamamlamasını sağladığını belirtti.
PHP Vakfı, açığın geçmişine ilişkin yaptığı açıklamada, CVE-2026-109618'in arkasındaki bellek taşması açığına dair ilk işaretlerin PHP'nin 2024 dış denetimi sırasında bir çekirdek geliştirici tarafından fark edildiğini, ancak o dönemde çalışan bir saldırı yolu bulunamadığını aktardı. Vakıf, düzeltme sürecindeki gecikmeyi karar verme sürecinin ve kaynaklarının "yapısal bir başarısızlığı" olarak nitelendirdi ve o tarihten bu yana güvenlik kararlarını alma biçimini değiştirdiğini, benzer sorunları daha erken yakalamak için personel ve araç kapasitesini artırdığını belirtti.
Siber Güvenlik
Siber Güvenlik
Siber Güvenlik
Yorumlar (0)
Yorum yapmak için giriş yapmalısınız.