Ne oldu
21 Ekim'de PHP projesi iki güvenlik açığı için düzeltme yayınladı: CVE-2026-109618 ve CVE-2026-109619. İkisi de CVSS 9.2 puanına sahip ve Arctic Wolf'un analizine göre, kimliği doğrulanmamış bir saldırganın PHP ile web isteklerini işleyen bir sunucuda kod çalıştırmasına izin verebilir.
Hatalar bir framework'te ya da eklentide değil, PHP'nin kendi istek işleme yaşam döngüsünde bulunuyor:
- CVE-2026-109618, istek verisi yalnızca kısmen hazırlanmışken bir bellek yetersizliği durumu PHP'yi kestiğinde tetiklenen bir bellek bozulmasıdır.
- CVE-2026-109619 bir use-after-free hatasıdır: bir isteğe ait durum hayatta kalabilir ve aynı worker üzerindeki sonraki bir istek tarafından okunabilir; bu da bellek içeriğinin sızmasına yol açabilir.
İkinci nokta üzerinde durmaya değer. Qualys, sızan worker belleğinin parolalar, token'lar ve API key'leri içerebileceğini belirtiyor. Yani kimse sunucunda shell elde etmese bile secret'lar dışarı sızabilir.
Yamadan sonra olaylar hızlı gelişti ve ölçek büyük: The Hacker News, Censys'in tahminine göre 32 milyondan fazla PHP hizmetinin hâlâ etkilenen bir sürüm çalıştırdığını aktarıyor.
- BleepingComputer'ın aktardığına göre Amazon'un tehdit istihbaratı ekibi, hedeflemenin düzeltmeler yayınlanmadan dört gün önce başladığını söyledi.
- 24 Ekim'de Perplexity'den bir araştırmacı honeypot'lara karşı başarılı kod çalıştırmayı doğruladı (The Hacker News).
- 26 Ekim'de CISA iki CVE'yi de Known Exploited Vulnerabilities kataloğuna ekledi ve ABD federal kurumlarına düzeltmeleri için 29 Ekim'e kadar süre verdi.
Bu neden küçük uygulamalar için de önemli
Saldırganlar burada hedefleri şirket büyüklüğüne göre seçmiyor. İnterneti PHP gibi yanıt veren her şey için tarıyor ve exploit'i deniyorlar. Bir VPS üzerinde unutulmuş bir yan proje, büyük bir e-ticaret sitesi kadar erişilebilir.
Birkaç ayrıntı bu durumu özellikle harekete geçmeye değer kılıyor:
- Senin koduna bağlı değil. Arctic Wolf, açıklar PHP'nin istek işlemesinde olduğu için maruz kalmanın hangi uygulamayı çalıştırdığına bağlı olmadığını vurguluyor. Eski bir PHP build'i üzerinde kusursuz yazılmış bir Laravel uygulaması da açıkta.
- Birçok sunucu yapılandırması kapsamda. En yüksek risk Apache + mod_php olarak görülüyor, ancak PHP-FPM, php-cgi, FrankenPHP ve LiteSpeed de etkilenenler arasında sayılıyor; PHP'yi içinde barındıran ürünler ve cihazlar da öyle.
- Eski PHP yaygın. Qualys, sürümünü tespit edebildiği PHP kurulumlarının yaklaşık %71'inin zaten destek ömrünü doldurmuş olduğunu bildiriyor. 8.1 veya daha eskisini kullanıyorsan, senin için düzenli bir upstream düzeltme yok.
Uygulamanı nasıl kontrol edersin
Her sunucu için tek bir yanıt arıyorsun: PHP ile web istekleri sunan bir şey var mı ve tam olarak hangi sürüm?
1. Barındırdığın her şeyi listele. Sadece ana uygulamayı değil. Pazarlama sitelerini, blogları, dokümantasyonu, staging ortamlarını, yönetim araçlarını ve bir subdomain'deki her şeyi dahil et. Asıl tehlikeli olanlar unutulmuş olanlardır.
2. Yanıt header'larına bak. Birçok PHP kurulumu kendini bir X-Powered-By veya Server header'ında ele verir. Header olmaması PHP olmadığı anlamına gelmez (expose_php = Off ile kapatılabilir), ama bir header hızlı bir evet demektir. Ayrıntılı hata sayfaları da ele verir: production'daki bir PHP stack trace'i saldırgana tam olarak ne çalıştırdığını söyler.
curl -sI https://your-site.example | grep -i -E 'x-powered-by|server'
# X-Powered-By: PHP/8.3.20 <- PHP, and an old patch level3. Sadece CLI'yi değil, web trafiğini sunan sürümü kontrol et. Sunucudaki php -v, Apache veya PHP-FPM'in gerçekte kullandığından farklı bir build bildirebilir; Qualys bunu özellikle vurguluyor. FPM binary'sini veya web sunucunun PHP modülünü kontrol et ya da hosting sağlayıcına sor.
php-fpm8.3 -v # or php-fpm -v, depending on your distro
apache2ctl -M | grep php # is mod_php loaded?4. Düzeltilmiş sürümlerle karşılaştır. PHP'yi Linux dağıtımından kuruyorsan, düzeltme daha eski görünen bir sürüm numarasına sahip bir pakete backport edilmiş olabilir; bu yüzden yalnızca sürüm metnine değil, dağıtımının güvenlik bültenine bak. Aksi halde en az şunlara ihtiyacın var:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
5. Yönetilen hosting mi kullanıyorsun? Yönetilen bir WordPress hosting'inde veya bir PaaS üzerindeysen, durum sayfalarında ya da changelog'larında bir PHP2Shell duyurusu ara. Çoğu yamayı senin yerine uygular, ama "çoğu" "hepsi" demek değildir ve kendi yönettiğin bir VPS tamamen senin sorumluluğundadır.
Nasıl düzeltilir
Yamala, sonra yeniden başlat. PHP'yi güncellemek tek eksiksiz düzeltmedir.
Yeniden başlatma önemli: çalışan worker'lar değiştirilene kadar eski kodu bellekte tutar. Docker kullanıyorsan güncel bir base image (örneğin güncel bir php:8.3-fpm tag'i) üzerinde yeniden build al ve yeniden deploy et. Eski container'ı sadece yeniden başlatmakla yetinme.
PHP-FPM kullanan Debian veya Ubuntu'da genellikle şuna benzer:
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # if you use mod_phpBugün yamalayamıyorsan, Qualys PHP'nin geçici önlemlerini özetliyor. Bunlar riski azaltır ama yamalanmamış bir sunucuyu güvenli hale getirmez. Bunları php.ini veya FPM pool yapılandırmasında ayarla (.user.ini veya ini_set ile değil), ardından tüm worker'ları yeniden başlat.
Yamalanmamış bir hizmetin herkese açık olması gerekmiyorsa, onu bir VPN veya IP allowlist arkasına al ya da güncelleyene kadar çevrimdışı bırak.
; php.ini or FPM pool config (not .user.ini or ini_set)
session.upload_progress.enabled = 0
post_max_size = 8M ; 32M if you need uploads
upload_max_filesize = 6M ; keep below post_max_sizePHP 8.1 veya daha eskisindeysen yükseltmeyi şimdi planla. Bazı eski dallar için sınırlı backport'lar var, ama böyle bir şey her çıktığında şansa güveniyorsun.
İhlal belirtilerini ara. Beklenmedik süreçleri, web root'larındaki yeni dosyaları, tanımadığın cron job'ları ve web sunucusundan giden bağlantıları kontrol et. Arctic Wolf ayrıca loglardaki birçok "PHP2Shell" isteğinin eski teknikleri yeniden kullandığını belirtiyor; yani korkutucu görünen bir log satırı otomatik olarak başarılı bir saldırı anlamına gelmez.
Açıktaysan secret'larını yenile. CVE-2026-109619 worker belleğini sızdırabildiği için, yamalanmamış ve internete açık bir PHP sürecinden geçmiş secret'ları görülmüş olabilir say: veritabanı parolaları, API key'leri, oturum imzalama anahtarları ve ödeme sağlayıcısı anahtarları. Laravel ve benzeri framework'ler bunları .env içinde tutar; bu yüzden o dosyanın hiçbir zaman web üzerinden erişilebilir olmadığını da doğrula.
Hızlı kontrol listesi
Sahip olduğun her domain için bunu gözden geçir:
- Eski pazarlama ve staging siteleri dahil, sahip olduğun her domain ve subdomain listelendi.
- Hangilerinin PHP çalıştırdığını ve web trafiğini sunan tam sürümü biliyorsun.
- Her biri 8.5.12, 8.4.27, 8.3.36, 8.2.35 veya sağlayıcı tarafından yamalanmış bir build üzerinde.
- Güncellemeden sonra PHP worker'ları ve web sunucuları yeniden başlatıldı.
- Yamalanmamış her şey kısıtlandı veya çevrimdışı, geçici önlemler uygulandı.
- Açıktaki host'lardaki secret'lar yenilendi.
- Production artık PHP sürümünü ilan etmiyor ve stack trace göstermiyor.
Daha büyük ders
PHP2Shell birkaç hafta içinde yamalanıp unutulacak. Ama örüntü kalacak. "Düzeltme yayınlandı" ile "istismar ediliyor" arasındaki süre artık günlerle ölçülüyor, bazen negatif. Küçük ekipler bunu kahramanlıkla geride bırakamaz. İşe yarayan, ne çalıştırdığını bilmek ve onunla ilgili bir şey değiştiğinde bunu hızla fark etmektir.
AI ile yapılan uygulamalar için hazırladığımız yayın kontrol listesinin arkasındaki düşünce de aynı: gerçek dünyadaki olayların çoğu, kontrol etmesi kolay olan şeylerden kaynaklanıyor; tabii gerçekten kontrol edersen.
AppSafe canlı siteni dışarıdan, bir saldırganın göreceği şekilde tarar. Eksik güvenlik header'ları, stack'ini sızdıran bir X-Powered-By header'ı, açıkta kalan dosyalar ve ayrıntılı hatalar gibi sorunları arar ve sana sade bir dille düzeltmeler sunar. Yamaladıktan sonra, diğer kolay kazanımları da yakalamak için her domain'inde ücretsiz bir tarama çalıştır.