Teknoloji Trendleri6 dk okuma26 Ekim 2026

PHP2Shell Artık Gerçek Saldırılarda: Çalışan Kabuklar, Yamasız Yeni Bir Açık ve 5 Milyondan Fazla Açıkta Sunucu

26 Ekim'de iki güvenlik kaynağı PHP2Shell açıklarının artık gerçek sunuculara karşı başarıyla kullanıldığını bildirdi. Üstüne yamasız yeni bir PHP açığı çıktı. Henüz güncellemediyseniz bugün ne yapmalısınız? Netleşen bilgileri ve belirsiz kalanları ayırarak anlatıyoruz.

Kısaca: 21 Ekim'de yamalanan PHP2Shell açıkları (CVE-2026-109618 ve CVE-2026-109619) için durum değişti. 26 Ekim 2026'da hem SecurityWeek hem BleepingComputer, Perplexity'de tespit ve müdahale sorumlusu Adel Karimi'nin honeypot (tuzak sunucu) verilerine dayanarak açıkların artık gerçek sunuculara karşı çalışan kabuklarla kullanıldığını bildirdi. Karimi'nin sensörleri 24 Ekim'de üç honeypot'ta 35 kabuk kaydetti; saldırı, bellek tüketme, bellek sızdırma ve kabuk komutundan oluşan dört aşamalı bir HTTP istek zinciriydi ve kamuya açık bir kavram kanıtı (PoC) istismarıyla yakından uyuşuyordu. Karimi ve Expel'den Marcus Hutchins sonucu dikkatle yorumladı: test, tek işçili bir Apache mod_php profiline ait ve diğer yapılandırmalarda güvenilirliği gösterilmedi. BleepingComputer ayrıca yamasız yeni bir RCE açığı, CVE-2026-115560, bildirdi; yalnızca belirli yapılandırma ve uygulama kodu birleşiminde istismar edilebiliyor ve düzeltme gelene kadar PHP session.upload_progress.enabled=0 ayarını öneriyor. VirusTotal tahminlerine göre 5,1 milyondan fazla PHP sunucusu internete açık. Bu yazı 26 Ekim 2026 itibarıyla SecurityWeek ve BleepingComputer haberlerine dayanır.

Son güncelleme: 26 Ekim 2026

Önceki yazının devamı

PHP2Shell yazımızda açığı, etkilenen sürümleri ve ilk adımları anlatmıştık. O zaman sömürü denemeleri vardı ama başarılı kod çalıştırma teyit edilmemişti. Bugünkü gelişme, “henüz kimse başarıyla kullanmıyor” rahatlığının sona erdiği anlamına geliyor.

Yeni bilgiler: Ne netleşti?

Konu	Bilgi
Gerçek sömürü kanıtı	Karimi, Apache mod_php + PHP 8.4.26 çalışan bir honeypot'ta onaylanmış uzaktan kod çalıştırma raporladı. Yanıtta 800 KiB'lık çözülmüş bir çerez dökümü vardı ve bu dökümden türetilen bir fonksiyon adresi sonraki bir yükte görüldü
Honeypot verisi (24 Ekim)	Üç honeypot'ta 35 kabuk; bir IP 3 kabuk, bir diğeri üç sunucuda toplam 32 kabuk başlattı
Saldırı zinciri	Dört aşamalı HTTP istekleri: bellek tüketme, bellek sızdırma, kabuk komutu. Trafik kamuya açık bir PoC ile yakından eşleşiyor
İkinci aşama yük	İndirilen bir ikinci aşama yük gözlenmedi
Uzman yorumu	Marcus Hutchins (Expel) bunu vahşi doğada PHP2Shell sömürüsünün gördüğü “en kaliteli doğrulama” olarak nitelendirdi
CISA	23 Ekim'de uyarısını bir Sigma tespit kuralıyla güncelledi; başarılı sömürü gözlemlemediğini belirtti. 26 Ekim sabahı itibarıyla açıklar KEV (bilinen sömürülen açıklar) kataloğunda değildi
Yama	PHP, yamaları 21 Ekim'de yayınladı
Maruz kalma	PHP web sitelerinin yaklaşık %70'inde kullanılıyor; VirusTotal tahminine göre 5,1 milyondan fazla PHP sunucusu internette açık, yaklaşık 3,8 milyonunda en az bir port saldırıya açık

Hâlâ belirsiz olanlar

Güvenilirlik: Karimi, sonucun tek işçili mod_php profilinde elde edildiğini ve diğer yapılandırmalardaki (ör. PHP-FPM) güvenilirliği göstermediğini vurguladı. Yani “her sunucu aynı kolaylıkla ele geçirilir” sonucuna varamayız; ama güvenli olduğunu da söyleyemeyiz.
Geniş çaplı ele geçirme: Honeypot dışında başarılı bir ele geçirme BleepingComputer ve SecurityWeek haberlerinde doğrulanmadı.
Diğer kaynakların iddiaları: Bazı kaynaklar Mirai botnet operatörlerinin saldırıya katıldığını ve Cloudflare'ın milyonlarca deneme gözlediğini yazıyor. Bunları birincil kaynaktan doğrulayamadım; SecurityWeek haberinde bunlar ilgili bağlantı başlığı veya anılan veri olarak geçmiyor.

Yamasız yeni açık: CVE-2026-115560

BleepingComputer'a göre yeni bir RCE açığı var ve henüz düzeltmesi yok. Yalnızca belirli bir yapılandırma ve uygulama kodu birleşiminde istismar edilebiliyor. PHP, düzeltme gelene kadar şu ayarı öneriyor:

session.upload_progress.enabled = 0

PHP.net'in 21 Ekim duyurusu da aynı ayarı PHP2Shell için “geçici önlem” olarak (güvenli kılmadığını belirterek) listelemişti. Yeni açık için resmî duyuruyu ve php.net güvenlik sayfasını takip edin; ayrıntıları henüz doğrulayamadım.

Bugün yapmanız gerekenler: 8 adım

Yamayı uygulayın: PHP 8.5.12, 8.4.27, 8.3.36 veya 8.2.35 (ya da sağlayıcınızın yamalı paketi). Hâlâ yapmadıysanız bu bir “bu hafta” değil, bugün işi.
Sürümü doğrulayın: php -v ile çıktıyı kaydedin; konteynerler ve staging dahil tüm PHP kurulumlarına bakın.
mod_php kullanıyorsanız öncelik verin: Sömürü doğrulamasının mod_php üzerinde yapıldığı bildirildi; PHP-FPM'e geçiş uzun vadeli bir iyileştirme olabilir (bunu yaparken sistem yöneticinizle planlayın).
Geçici ayarı uygulayın (yama ile birlikte düşünülebilir): session.upload_progress.enabled = 0. Yeni yamasız açık için PHP bunu öneriyor. Uygulama özelliklerini etkileyip etkilemediğini test edin (dosya yükleme ilerleme çubuğu kullanıyorsanız etkilenir).
Günlükleri inceleyin: Olağandışı multipart istekleri, bellek sınırı hataları, tekrarlayan HTTP 500, büyük/bozuk PHPSESSID çerezleri, açıklanamayan işçi süreci yeniden başlamaları. CISA'nın yayımladığı Sigma kuralını güvenlik ekibiniz kullanabilir.
Sırları yenilemeyi planlayın: Süreç belleğinden parola, token ve anahtar sızdırma potansiyeli bildirilmişti. Özellikle internete açık ve yamasız çalışmış sunucularda .env, veritabanı, API ve SMTP sırlarını yenilemeyi değerlendirin.
WAF'a güvenmeyin: WAF kuralları ek korumadır, çözüm değildir.
Desteklenmeyen sürümlerde plan yapın: PHP 8.1 ve eskisi resmî yama almıyor; PHP 8.2'nin desteği 31 Aralık 2026'da bitiyor.

Ayrıntılı kontrol listesi ve “etkilenip etkilenmediğinizi nasıl anlarsınız” için ilk yazımıza bakın. Acil yama düzeni kurmak için yama yönetimi yazımıza göz atın.

İşletme sahibi için sade mesaj

Gecikmenin bedeli artık somut: Açık duyurulduktan beş gün sonra çalışan kabuklar gözlendi. Bu, yama gecikmesinin soyut değil gerçek bir risk olduğunu gösteriyor.
Hosting firmanızdan yazılı onay isteyin: “PHP2Shell yamasını uyguladınız mı, hangi sürümdeyiz, yeni CVE-2026-115560 için ne yapıyorsunuz?”
Panik değil öncelik: Önce internete açık, PHP çalışan, hassas veri taşıyan sistemler.

Aktaş Digital ile bakım ve güvenlik

Web uygulamalarında sürüm envanteri, acil yama takibi ve yükseltme sonrası test, bakım planının parçasıdır. Sitenizin güvenlik durumunu değerlendirtmek için teklif formumuzu kullanabilirsiniz. İlgili hizmetlerimiz: web çözümleri.

Sık Sorulan Sorular

PHP2Shell gerçekten kullanılıyor mu?

SecurityWeek ve BleepingComputer, Perplexity'den Adel Karimi'nin honeypot verilerine dayanarak çalışan kabukları bildirdi. Honeypot dışında geniş çaplı başarılı ele geçirme bu haberlerde doğrulanmadı.

Yama yaptım; hâlâ risk var mı?

PHP2Shell için yama uygulanmış sunucularda bu açıklar kapanır. Ancak yamadan önce sömürüldüyse sırlar etkilenmiş olabilir; ayrıca yeni CVE-2026-115560 için geçici ayar önerisini değerlendirin.

CVE-2026-115560 benim için geçerli mi?

BleepingComputer'a göre yalnızca belirli bir yapılandırma ve uygulama kodu birleşiminde istismar edilebiliyor. Bu birleşimin ayrıntılarını doğrulayamadım; yazılım ekibinizin resmî duyuruya bakmasını isteyin.

PHP-FPM kullanıyorum, daha güvenli miyim?

Honeypot sonucu mod_php üzerinde elde edildi ve araştırmacılar PHP-FPM gibi yapılandırmalardaki güvenilirliğin gösterilmediğini belirtti. Bu yüzden “güvendeyim” demeyin; yamayı uygulayın.

Tüm PHP sitelerim bu yüzden kapalı mı olmalı?

Hayır. Yamalı sürümlerde sorun yok. Yamalayamıyorsanız ve site yüksek risk taşıyorsa geçici olarak bakım moduna almak makul bir önlemdir.

Sonuç

PHP2Shell “teorik” olmaktan çıktı: çalışan kabuklar gözlendi, yamasız yeni bir açık da gündemde. Siteniz PHP çalıştırıyorsa bugün yapacağınız en önemli iş, yamalı sürüme geçmek ve bunu yazılı olarak doğrulamak. İlk adım: tüm PHP kurulumlarınızın sürümünü listeleyip yamalı olmayanları öncelik sırasına koymak.