Güvenlik açığı: CVE-2026-109618 ve CVE-2026-109619
🔴 Düzey: 9.2 / 10
En önemli tehlike, saldırganların kimlik doğrulaması yapmadan internet üzerinden PHP sunucusunda zararlı kod çalıştırabilmesi (Remote Code Execution - RCE) ihtimalidir. Bu durum, uygun saldırı koşullarında sunucunun ele geçirilmesine ve verilerin çalınmasına neden olabilir.
Resmî PHP duyurusuna göre:
- İki kritik açık için güvenlik güncellemesi hazırlanıyor.
- Yayın tarihi 21 Ekim 2026, Türkiye saatiyle 17.00 olarak açıklandı.
- Etkilenen sürümlerin ve düzeltmelerin tam listesi güncelleme duyurusunda paylaşılacak.
En önemli gelişme Cloudflare'den geldi. Şirketin CTO'su Dane Knecht, saldırı faaliyetlerinin başladığını gördüklerini ve yeni saldırı yöntemleri ortaya çıktıkça güvenlik duvarı önlemlerini güncellediklerini açıkladı. Reuters bu açıklamayı 21 Ekim'de aktardı.
https://www.php.net/archive/2026.php?ref=teteos.net
🔬 PHP2Shell Gerçekte Nasıl Çalışıyor?
Bu güvenlik açıklarını tehlikeli yapan nokta, sorunun yalnızca WordPress, Laravel veya başka bir PHP uygulamasındaki hatadan kaynaklanmaması. Açıkların doğrudan PHP yorumlayıcısını (PHP Core) etkilemesi, saldırı yüzeyini oldukça genişletiyor.
Normal şartlarda bir HTTP isteği uygulamaya ulaştığında çeşitli güvenlik kontrollerinden geçirilir. Ancak PHP, bazı HTTP verilerini uygulama kodu çalışmaya başlamadan önce işlemektedir.
Araştırmacıların üzerinde yoğunlaştığı noktalardan biri, PHP'nin multipart/form-data isteklerini işleyen RFC1867 dosya yükleme mekanizması.
⚙️ 1. PHP'nin HTTP İsteğini İşleme Zinciri
Normal bir dosya yükleme isteğinde süreç kabaca şöyledir:
HTTP POST → Nginx/Apache → PHP-FPM → RFC1867 Parser → Session Upload Progress → PHP Uygulaması
Buradaki kritik ayrıntı, Session Upload Progress işlemlerinin PHP uygulaması başlamadan önce gerçekleşebilmesidir.
Yani Laravel middleware, WordPress güvenlik eklentisi veya uygulama seviyesindeki bir dosya yükleme kontrolü, PHP'nin önceden yaptığı işlemleri geri alamaz.
Bu özellik, saldırının mutlaka /upload.php gibi özel bir dosya yükleme sayfasına ihtiyaç duyacağı varsayımını da zayıflatıyor.
Ancak bunun bütün PHP uç noktalarının istismar edilebilir olduğu anlamına gelmediğini belirtmek gerekiyor.
🧠 2. Session Upload Progress ve Bellek Güvenliği
PHP'nin session.upload_progress özelliği, yüklenen dosyanın ne kadarının işlendiğini oturum verileri üzerinden takip etmeye yarar.
Varsayılan yapılandırmada özellik aktiftir:
session.upload_progress.enabled = Onsession.upload_progress.name = PHP_SESSION_UPLOAD_PROGRESSsession.upload_progress.prefix = upload_progress_
Sistemde yükleme ilerlemesi için bytes_processed, content_length ve files gibi bilgiler tutulabilir.
Sızdırıldığı iddia edilen teknik analizlerde, bu mekanizmadaki bellek yönetimine ve olası Use-After-Free (UAF) davranışına dikkat çekiliyor.
Peki UAF nedir?
Bir programın bellekteki bir nesneyi serbest bıraktıktan sonra aynı bellek adresini kullanmaya devam etmesidir. Uygun koşullarda bellek bozulmasına, uygulamanın çökmesine veya daha ileri istismar zincirlerine neden olabilir.
PHP tarafında araştırılan senaryolardan biri de zval işaretçileri ve session verilerinin yaşam döngüsüyle ilgili.
Önemli teknik not: Bazı bağımsız araştırmacılar ilgili kod yollarını laboratuvar ortamında tetikleyebildi; ancak yayımlanan UAF iddialarının tamamı doğrulanamadı. Resmî yama açıklaması yayımlanmadan iki CVE'nin kök nedenlerini kesin olarak bu mekanizmaya bağlamak doğru olmaz.
🎯 3. Başarılı Bir RCE Saldırısı Neye Yol Açabilir?
Saldırgan sunucuda uzaktan kod çalıştırmayı başarırsa PHP işleminin sahip olduğu yetkiler kapsamında aşağıdaki faaliyetleri gerçekleştirebilir:
- Sunucu ortamını, çalışan servisleri ve erişilebilir dosyaları keşfetmek.
- Uygulama yapılandırmalarındaki veritabanı kimlik bilgilerine ulaşmaya çalışmak.
- Web shell veya kalıcılık sağlayan zararlı bileşenler yerleştirmek.
- Sunucunun erişebildiği diğer sistemlere yönelmek.
- Hassas verileri dışarı aktarmak.
Burada RCE ile root yetkisini birbirinden ayırmak gerekiyor. RCE, saldırganın otomatik olarak root olduğu anlamına gelmez. Elde edilen yetki, PHP worker işleminin çalıştığı kullanıcıya ve sunucunun izolasyonuna bağlıdır.
🔎 4. SOC Ekipleri Hangi IOC ve Davranışları İzlemeli?
Henüz bu iki CVE'ye özgü, kapsamlı ve doğrulanmış bir IOC listesi bulunmasa da davranışsal tespit yapılabilir.
Linux / PHP-FPM üzerinde dikkat edilmesi gerekenler:
php-fpm, apache2 veya httpd süreçlerinden beklenmedik sh, bash ya da python alt süreçleri oluşması.- Web sunucusu üzerinden
curl, wget veya benzeri ağ araçlarının çalıştırılması.
- Normalde dosya yüklemesi beklenmeyen uç noktalara olağandışı
multipart/form-data POST trafiği gönderilmesi.
- Web dizinlerine beklenmedik PHP dosyalarının yazılması.
- PHP worker çökmeleri, anormal yeniden başlamalar veya beklenmedik dış ağ bağlantıları.
PHP_SESSION_UPLOAD_PROGRESS alanının şüpheli isteklerle birlikte görülmesi de araştırmaya değer olabilir. Ancak bu alan meşru uygulamalar tarafından kullanılabilir ve standart erişim günlükleri her zaman POST gövdesini kaydetmez.
Bu göstergeler tek başına PHP2Shell istismarının kesin kanıtı değildir; olay incelemesinde birden fazla bulgunun ilişkilendirilmesi gerekir.
🛡️ 5. Geçici Önlem: PHP Yapılandırmasını Sıkılaştırmak
Bazı araştırmacılar, kullanılmayan upload-progress özelliğinin kapatılmasını öneriyor.
php.ini dosyasında değerlendirilebilecek yapılandırma:
; Geçici risk azaltma
session.upload_progress.enabled = Off
; Genel oturum güvenliği
session.use_strict_mode = 1
Değişikliğin, web isteklerini gerçekten işleyen PHP-FPM veya Apache PHP yapılandırmasında etkin olduğu doğrulanmalıdır.
Upload-progress özelliğinin kapatılması, onu kullanan ilerleme çubuklarının çalışmasını etkileyebilir; normal dosya yükleme işlevini tek başına kapatmaz.
⚠️ Dikkat: Bu ayarlar güvenlik yamasının yerini tutmaz. Araştırmacılar, upload-progress özelliğini devre dışı bırakmanın iki kritik güvenlik açığını tamamen engellediğini doğrulamış değil.
Ek olarak WAF üzerinde gereksiz multipart isteklerinin sınırlandırılması, PHP işlemlerinin düşük yetkilerle çalıştırılması ve sunucunun dış ağ erişimlerinin kısıtlanması saldırı yüzeyini azaltabilir.
🌍 6. Neden Bu Kadar Büyük Bir Güvenlik Olayı?
Sorunun tek bir CMS eklentisiyle sınırlı olmaması ciddi bir operasyonel risk yaratıyor.
Aynı PHP yorumlayıcısını kullanan birden fazla uygulama veya alan adı, ortak bir çalışma zamanı nedeniyle birlikte etkilenebilir.
Üstelik PHP 7.x, 8.0 ve 8.1 gibi kullanım ömrünü tamamlamış sürümler PHP projesinden artık resmî güvenlik güncellemesi almıyor.
Bu nedenle yalnızca WordPress veya Laravel güncellemek yeterli olmayacaktır. Sunucuda çalışan PHP sürümü, paket sağlayıcısı ve olası güvenlik yamaları ayrıca kontrol edilmelidir.
📌 Son Durum
21 Ekim 2026 itibarıyla PHP güvenlik ekibinin iki kritik açık için planladığı güncelleme bekleniyor.
Kesin etkilenen sürümler, düzeltilmiş paketler ve CVE bazında teknik kök nedenler resmî açıklamayla netleşecek.
Bu noktada savunma açısından en kritik işlem; kullanılan PHP çalışma ortamlarını envantere almak, saldırı göstergelerini izlemek ve güvenlik güncellemesi yayımlandığında gecikmeden uygulamak.
Siber güvenlikte tehlike yalnızca açığın varlığı değil, istismar ile yama uygulaması arasındaki sürenin saldırganlar tarafından kullanılabilmesidir.
📚 Teknik kaynaklar
