PHP2Shell: İki kritik PHP zafiyeti ve hemen yapmanız gerekenler
PHP2Shell (CVE-2026-109618, CVE-2026-109619) kimlik doğrulamasız RCE’ye yol açıyor. Etkilenen sürümler, yamalar, geçici önlemler ve tespit adımları.
PHP’de kimlik doğrulaması olmadan uzaktan kod çalıştırmaya (RCE) imkân veren iki kritik zafiyet, ambargo bitmeden sızdı ve PHP projesi 21 Ekim 2026’da acil güvenlik sürümlerini yayımladı. Huntress’in “PHP2Shell” olarak andığı bu açıklar, uygulama kodunuz daha çalışmadan tetiklenebiliyor. Bu yazıda neyin etkilendiğini, nasıl yamalayacağınızı, yamalayamıyorsanız ne yapabileceğinizi ve saldırı izlerini nasıl arayacağınızı özetliyoruz.
Ne oldu?
PHP güvenlik ekibi iki zafiyeti de kritik olarak sınıflandırıyor; Huntress’e göre CVSS v4.0 puanı 9.2.
| CVE | Danışma | Kısaca |
|---|---|---|
| CVE-2026-109618 | GHSA-w8hw-w9fx-j79w | Bellek yetersizliği (OOM) hata yönetimi, istek verisi yarım oluşturulmuşken PHP’yi kesebiliyor. İstek temizliği bu bozuk veriyi geçerli sanıyor. |
| CVE-2026-109619 | GHSA-6wmf-4rv5-p3rp | İsteğe ait iç durum, belleği serbest bırakıldıktan sonra da kalabiliyor. Aynı worker’ın işlediği sonraki istek bu bayat durumu, normal başlatma onu sıfırlamadan önce kullanabiliyor. |
Saldırı HTTP üzerinden ve kimlik doğrulaması gerektirmeden yapılıyor. PHP’ye göre mod_php’ye gönderilen tek bir istek, hiçbir uygulama kodu çalışmadan saldırıyı tetikleyebiliyor. Tam RCE, varsayılan PHP girdi ve bellek limitleriyle, birden fazla worker’lı standart prefork yapılandırmasında doğrulanmış. Başarılı bir saldırı, web worker’ının yetkileriyle kod çalıştırma anlamına geliyor.
Etkilenen bileşenler: PHP’nin açıklamasına göre web isteği işleyen tüm kurulumlar risk altında: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Risk en yüksek mod_php’de.
Zaman çizelgesi
- 20 Ekim: Hacker News’te iki açığın kamuya açıklanacağını iddia eden bir paylaşım yapıldı; paylaşım kaldırıldı ama ekran görüntüleri yayıldı. watchTowr sızıntıyı doğruladı.
- 20 Ekim: PHP ön duyuru yayımladı ve sürümleri 21 Ekim 14:00 UTC’ye planladı; ayrıntılar açığa çıkarsa daha erken yayımlayabileceğini belirtti.
- 21 Ekim: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 yayımlandı.
Güncelleme (25 Ekim): Datadog’a göre AWS istismar girişimlerini 17 Ekim’de, açıklamadan önce görmüştü; 21 Ekim’den itibaren aktif istismar ve toplu tarama bildiriliyor. Sunucunuzun saldırıya uğrayıp uğramadığını nasıl anlayacağınızı PHP2Shell saldırı tespiti yazımızda anlattık.
21 Ekim itibarıyla Huntress kendi müşteri tabanında istismar görmediğini, herkese açık bir istismar kodundan da haberdar olmadığını bildiriyor. Bazı kaynaklar saldırıların başladığını öne sürüyor, ancak bu henüz bağımsız olarak doğrulanmış değil. Kısa bir istismar videosu yayımlanıp kaldırıldı. Ayrıntılar açıklandıkça bu tablo hızla değişebilir; beklemek için bir neden yok.
Hangi sürüme geçmelisiniz?
| Dal | Yamalı sürüm | Not |
|---|---|---|
| 8.5 | 8.5.12 | Mümkünse tercih edilecek dal |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | 31 Aralık 2026’da destek dışı kalıyor |
| 8.1 ve öncesi | — | PHP projesi artık güncelleme yayımlamıyor |
PHP 7.4, 8.0 ve 8.1 için yalnızca kaynak kod düzeyinde minimal yama geri taşımaları yayımlandı. Linux dağıtımları ve LTS sağlayıcıları yamaları önceden aldı; bu yüzden sürüm numarası değişmeden de yamalı paket gelmiş olabilir. Sürüm numarasına değil, dağıtımınızın güvenlik bildirimine bakın.
Adım adım güncelleme
1. Envanter çıkarın. Yalnızca kendi uygulamalarınızı değil; kontrol panellerini, CMS’leri, hazır yazılımların içinde gelen PHP’leri ve container imajlarını da listeleyin. İnternete açık olanları öne alın.
2. Web tarafında çalışan sürümü doğrulayın. Komut satırındaki php -v ile web sunucusunun kullandığı PHP farklı olabilir. PHP-FPM kullanıyorsanız ilgili binary’yi de kontrol edin:
php -v
php-fpm8.4 -v # dağıtıma göre adı değişebilir: php-fpm, php84-php-fpm…3. Paketleri güncelleyin ve worker’ları yeniden başlatın. Debian/Ubuntu tabanlı bir sunucuda örnek akış:
sudo apt update
sudo apt install --only-upgrade 'php8.4*'
sudo systemctl restart php8.4-fpm # mod_php kullanıyorsanız: sudo systemctl restart apache2Yeniden başlatma şart: eski worker süreçleri bellekte çalışmaya devam ettiği sürece yama devreye girmez.
4. Container imajlarını yeniden build edin. Base imajı yamalı etiketle güncelleyin, imajı yeniden üretin ve çalışan pod’ları yenileyin. Yalnızca latest etiketine güvenmeyin; hangi PHP sürümünün çalıştığını imajın içinde doğrulayın.
5. Barındırma sağlayıcınıza sorun. Paylaşımlı hosting ya da yönetilen platform kullanıyorsanız güncellemenin ne zaman yapıldığını yazılı olarak teyit edin.
Kendi sunucularınızı yönetmiyorsanız ya da envanter çıkarmak için zamanınız yoksa Sunucu & BT Yönetimi ekibimiz bu süreci sizin için yürütebilir.
Hemen güncelleyemiyorsanız: geçici önlemler
PHP projesi şunu açıkça söylüyor: tam bir geçici çözüm yok, tek güvenli seçenek güncellemek. Aşağıdaki ayarlar yalnızca bilinen bazı saldırı yollarını daraltır ve güncellemeye kadar zaman kazandırır.
CVE-2026-109618 için:
memory_limit=-1ayarlayın; tercihen FPM havuzunda ya da Apache yapılandırmasındaphp_admin_valueile. İlk bakışta ters gelebilir: amaç, açığın tetiklendiği PHP içi bellek yetersizliği yolunu kapatmak. Bellek sınırını bunun yerine container ya da cgroup düzeyinde koyun;RLIMIT_ASveyaRLIMIT_DATAile ikame etmeyin.post_max_sizedeğerini düşük tutun: dosya yükleme yoksa8M, varsa32M.upload_max_filesizebunun altında kalmalı.
CVE-2026-109619 için:
session.upload_progress.enabled=0ayarlayın ve tüm worker’ları yeniden başlatın. Ayarıphp.ini, FPM havuzu ya da sunucu yapılandırmasında yapın;ini_set()veya FPM.user.inidosyasına güvenmeyin.- PHP 8.5 kullanıyorsanız
fatal_error_backtraces=0ayarını da ekleyin.
Örnek bir FPM havuz yapılandırması:
; /etc/php/8.4/fpm/pool.d/www.conf — yalnızca güncelleyene kadar
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5: php_admin_flag[fatal_error_backtraces] = offDestek dışı bir PHP sürümü kullanıyorsanız sunucuyu VPN ya da WAF arkasına alın veya internetten çıkarın. Araştırmacıların hazırladığı gayriresmî yamalar dolaşıyor, ancak etkinlikleri doğrulanmış değil.
Saldırı izlerini nasıl ararsınız?
Yazının yayımlandığı sırada doğrulanmış bir saldırı göstergesi (IOC) yok. Huntress’in önerdiği en güçlü sinyal, PHP worker süreçlerinin beklenmeyen alt süreçler başlatması:
- Ebeveyn süreçler:
php-fpm,php-cgi,php-cgi.exe,httpd,apache2 - Kabuklar:
sh,bash,cmd.exe,powershell.exe - Yorumlayıcılar:
python,perl - İndirme ve ağ araçları:
curl,wget,nc,certutil.exe - Komut satırında:
/dev/tcp/,fsockopen,mkfifo - Web sunucusundan çalışan keşif komutları:
whoami,id,uname -a,ipconfig
EDR olmayan Linux sunucularda Florian Roth’un process-watcher aracını gözlem modunda çalıştırmak öneriliyor. Sigma ve YARA kuralları teknik ayrıntılar açıklandıkça yayımlanacak.
Saldırıdan şüpheleniyorsanız: sunucuyu ağdan izole edin, web sunucusu ve PHP loglarını koruyun; web kök dizininde yeni dosyalar ve webshell’ler, yeni cron işleri, zamanlanmış görevler ve yeni kullanıcı hesapları arayın. Olay müdahalesi ve adli inceleme için Siber Güvenlik ekibimizle çalışabilirsiniz.
Bu olaydan çıkarılacak ders
PHP2Shell, yama yönetiminin bir “bakım işi” değil, güvenlik süreci olduğunu bir kez daha gösteriyor. Sızıntı ile yama arasında bir günden az zaman vardı; hazırlıklı olan ekipler bu sürede yalnızca güncelleme yaptı, olmayanlar ise önce sunucularının nerede olduğunu bulmaya çalıştı.
- Envanter: Hangi sunucuda hangi PHP’nin çalıştığını tek bir yerden görebilmek.
- Destekli sürüm politikası: 8.2’nin 31 Aralık 2026’da destek dışı kalacağını şimdiden takvime koymak.
- Değiştirilemez imajlar: Container’larda sürümü sabitlemek ve yeniden build’i otomatikleştirmek.
- İzleme: Web worker’larının alt süreç başlatmasını alarm olarak tanımlamak.
Bu adımları geliştirme sürecinize nasıl yerleştireceğinizi Güvenli Yazılım & DevSecOps sayfamızda anlatıyoruz.
Sonuç
PHP2Shell, kimlik doğrulaması olmadan ve uygulama kodu çalışmadan tetiklenebilen iki kritik açık. Yapılacak iş net: PHP’yi 8.5.12, 8.4.27, 8.3.36 veya 8.2.35’e güncelleyin, worker’ları yeniden başlatın, güncelleyemiyorsanız geçici önlemleri uygulayın ve sunucuyu internetten uzak tutun. Ardından loglarda ve süreç ağacında saldırı izi arayın.
Sunucularınızın envanterini çıkarmak, güncellemeyi planlamak ya da bir saldırı şüphesini incelemek için bize yazın.
Kaynaklar: PHP güvenlik duyurusu, 21 Ekim 2026 ve Huntress: PHP2Shell. Bilgiler 21 Ekim 2026 itibarıyla günceldir.
This article is also available in English — Read in English →
Sıkça Sorulan Sorular
Web isteklerine yanıt veren her PHP kurulumu risk altında. Sunucunuzdaki PHP sürümü 8.5.12, 8.4.27, 8.3.36 veya 8.2.35’ten eskiyse ve dağıtımınız yamayı geri taşımamışsa güncelleme yapmanız gerekir. CLI ile web sunucusunun kullandığı PHP farklı olabilir; sürümü PHP-FPM ya da web sunucusu tarafında da kontrol edin.
Sunucuda web isteği işleyen bir PHP kurulumu yoksa bu zafiyet sizi doğrudan etkilemez. Yine de kontrol panelleri, CMS’ler ve hazır yazılımlar kendi PHP’lerini getirebilir; envanter çıkarırken bunları atlamayın.
Hayır. PHP projesi geçici önlemlerin yalnızca bazı saldırı yollarını daralttığını, kurulumu güvenli hâle getirmediğini açıkça belirtiyor. Tek tam çözüm yamalı sürüme geçmek.
