Kısaca
PHP'deki iki kritik açık (CVE-2026-109618 ve CVE-2026-109619) için güvenlik firmaları artık istismar girişimleri bildiriyor; bazıları saldırıların başarılı olduğunu da gözlemlediğini söylüyor. Tek tam çözüm hâlâ aynı: PHP'yi 8.5.12, 8.4.27, 8.3.36 veya 8.2.35 sürümüne yükseltmek ve tüm PHP worker'larını yeniden başlatmak. Güncellemeyi 21 Ekim'den sonra yaptıysanız, sunucunuzda saldırı izi olup olmadığını da kontrol edin. İlk gelişmeleri PHP kritik güvenlik açığı yazımızda anlattık.
Bu sayfada
Son durum: açıklar istismar ediliyor mu?
PHP 21 Ekim'de güncellemeleri yayımladığında, ekibin incelediği kavram kanıtı kodların hiçbirinin çalışır durumda olmadığını açıklamıştı. O tarihten bu yana tablo değişti:
| Kaynak | Ne bildiriyor? |
|---|---|
| Amazon Threat Intelligence | Açık duyurulmadan dört gün önce, 17 Ekim’de bir istismar girişimi gördüğünü ve açıkların artık geniş çapta istismar edildiğini bildiriyor (Tenable’ın aktarımıyla) |
| watchTowr | Tuzak sunucu ağında 21 Ekim’den bu yana iki açığın da istismar edildiğini gözlemlediğini açıkladı |
| Cloudflare | Teknoloji direktörü ilk saldırıların ortaya çıkmaya başladığını söyledi |
| CISA (ABD) | 22 Ekim itibarıyla açıkları “aktif istismar edilen açıklar” kataloğuna eklemedi |
Kaynaklar arasında “girişim” ile “başarılı istismar” ayrımında farklılık olsa da sonuç değişmiyor: internete açık, güncellenmemiş bir PHP sunucusu artık taranıyor ve hedef alınıyor. İngiltere Ulusal Siber Güvenlik Merkezi (NCSC) güncelleme yapılamıyorsa sistemlerin çevrimdışı bırakılmasını değerlendirmeyi, CERT-EU ise internete açık uygulamaların güncellenene kadar ayrı tutulmasını önerdi.
Hangi sürümler etkileniyor, hangisi güvenli?
| Sürüm | Durum | Ne yapmalı? |
|---|---|---|
| 8.5.x (8.5.12 öncesi) | Etkileniyor | 8.5.12’ye yükseltin |
| 8.4.x (8.4.27 öncesi) | Etkileniyor | 8.4.27’ye yükseltin |
| 8.3.x (8.3.36 öncesi) | Etkileniyor | 8.3.36’ya yükseltin |
| 8.2.x (8.2.35 öncesi) | Etkileniyor | 8.2.35’e yükseltin; 8.2 desteği 31 Aralık 2026’da bitiyor |
| 8.1, 8.0, 7.4 | Resmî sürüm yok | Dağıtım/LTS paketleri veya PHP’nin kaynak kod yamaları; mümkünse 8.3 ve üzerine geçin |
| 7.3 ve öncesi (5.4’ten itibaren) | Düzeltme yok | Desteklenen bir sürüme geçiş zorunlu |
Güvenlik araştırmacılarına göre sorunlu kod yolu PHP 5.4.0'a kadar uzanıyor; yani yıllardır güncellenmeyen eski siteler de risk altında.
Linux sunucularda sürüm numarası yanıltabilir
PHP projesi, Linux dağıtımlarına ve uzun süreli destek sağlayıcılarına yamaları önceden iletti. Debian, Red Hat Enterprise Linux, Fedora ve Gentoo yamalı paketleri yayımladı. Bu dağıtımlar düzeltmeyi çoğu zaman kendi paket sürümlerine uygular; bu yüzden php -v çıktısında hâlâ örneğin 8.2.20 gibi eski bir numara görebilirsiniz. Böyle sunucularda güvenli olup olmadığınızı anlamak için PHP sürüm numarasına değil, dağıtımınızın güvenlik duyurusunda bu CVE'ler için listelenen paket sürümüne bakın.
Güncellemeden sonra mutlaka yapılması gerekenler
- Tüm PHP worker'larını yeniden başlatın. PHP-FPM havuzlarını ve Apache'yi yeniden başlatmadan çalışan süreçler eski kodla devam eder.
- Çalışan sürümü doğrulayın. Komut satırındaki sürüm ile web sunucusunun kullandığı sürüm farklı olabilir. Geçici bir
phpinfo()sayfasıyla kontrol edip sayfayı hemen silin. - Birden fazla PHP sürümü kuruluysa hepsini güncelleyin. Hosting panellerinde siteler farklı sürümlere bağlı olabilir; kullanılmayan eski sürümleri kaldırın.
- Paylaşımlı hosting kullanıyorsanız firmanızdan güncellemenin yapıldığını yazılı olarak teyit edin ve sitenizin panelde güncel bir sürüme bağlı olduğunu kontrol edin.
Sunucunuzda saldırı izi var mı?
Güncellemeyi açığın duyurulmasından (21 Ekim) sonra yaptıysanız, güvenlik firması watchTowr'un önerilerine göre şu kontrolleri yapın. Değişiklik yapmadan önce günlükleri ve şüpheli dosyaları yedekleyin; delil kaybolmasın.
- Web kabukları: Site dizinlerinde son günlerde oluşturulmuş, tanımadığınız
.phpdosyaları. - Zamanlanmış görevler ve hesaplar: Yeni eklenmiş cron görevleri, sistem kullanıcıları veya sitenizde yeni yönetici hesapları.
- Günlük kayıtları: Alışılmadık büyüklükte veya çok derin iç içe alanlar içeren çok parçalı (multipart) POST istekleri, bellek yetersizliğiyle çöken PHP worker'ları.
- Ağ trafiği: PHP süreçlerinden dışarıya giden açıklanamayan bağlantılar.
Bir iz bulursanız yalnızca güncellemek yetmez: şifreleri ve API anahtarlarını değiştirin, mümkünse siteyi temiz bir yedekten yeniden kurun. Sitenin dışarıdan erişilebilir olduğunu site çalışıyor mu, sunucunun gönderdiği başlıkları HTTP başlıkları aracıyla kontrol edebilirsiniz.
Hemen güncelleyemiyorsanız: geçici önlemler
PHP'nin resmî duyurusu, güncelleme yapılana kadar riski azaltabilecek ayarları sıralıyor. PHP bu ayarların kurulumu güvenli hâle getirmediğini açıkça belirtiyor; watchTowr da .ini değişikliklerine dayanan önlemlerin etkisiz sayılması gerektiğini vurguluyor. Bunlar yalnızca güncellemeye kadar geçecek süre için düşünülmeli:
| Açık | PHP’nin önerdiği geçici ayar | Dikkat |
|---|---|---|
| CVE-2026-109619 | session.upload_progress.enabled=0 (php.ini veya FPM havuz ayarında), ardından tüm worker'ları yeniden başlatın | ini_set() veya .user.ini ile yapılan değişiklik yeterli değil |
| CVE-2026-109619 (PHP 8.5) | Ek olarak fatal_error_backtraces=0 | Hata ayrıntılarını gizlemek tek başına koruma sağlamaz |
| CVE-2026-109618 | post_max_size değerini düşürmek (ör. 8M), upload_max_filesize’ı bunun altında tutmak; istek boyutunu web sunucusunda veya proxy’de sınırlamak | PHP ayrıca memory_limit=-1 ayarını öneriyor; bu bellek sınırını kaldırdığı için yalnızca konteyner/cgroup sınırıyla birlikte kullanılmalı |
Cloudflare gibi bir hizmetin arkasındaysanız, bu hizmetlerin yayımladığı güvenlik duvarı kuralları da bilinen saldırı kalıplarını engeller; ancak yalnızca o hizmetten geçen trafiği korur ve güncellemenin yerini tutmaz.
WordPress ve hazır yazılım kullananlar
Araştırmacılar, kimlik doğrulaması olmadan uzaktan kod çalıştırmayı WordPress, Drupal, Joomla ve Magento'nun belirli sürümleri üzerinde doğruladıklarını bildirdi. Sorun bu yazılımların kendisinde değil, altta çalışan PHP'dedir; bu yüzden eklenti veya tema güncellemesi açığı kapatmaz. Sitenizin PHP sürümünü WordPress'te Araçlar → Site Sağlığı → Bilgi → Sunucu bölümünden görebilirsiniz.
Kaynaklar: PHP resmî güvenlik duyurusu, watchTowr ve Tenable (son güncelleme 23 Ekim 2026). Durum değiştikçe bu yazı güncellenecektir.
Sık sorulan sorular
PHP2Shell açıkları şu anda istismar ediliyor mu?
Amazon, watchTowr ve Cloudflare istismar girişimleri ve saldırılar gözlemlediğini bildirdi. ABD'nin CISA kurumu 22 Ekim itibarıyla açıkları aktif istismar edilenler listesine eklemedi. Güncellenmemiş sunucuların hedef alındığını varsaymak gerekir.
php -v eski sürüm gösteriyor ama dağıtımım güncellendi, güvende miyim?
Debian ve RHEL gibi dağıtımlar düzeltmeyi kendi paket sürümlerine uygular. Güvenli olup olmadığınızı dağıtımınızın güvenlik duyurusunda bu CVE'ler için listelenen paket sürümüyle karşılaştırarak anlayın.
Güncelledim, başka bir şey yapmam gerekir mi?
Tüm PHP worker'larını yeniden başlatın, web sunucusunun kullandığı sürümü doğrulayın ve güncellemeyi 21 Ekim'den sonra yaptıysanız sunucuda yeni PHP dosyaları, cron görevleri ve hesaplar gibi saldırı izlerini kontrol edin.
PHP 7.4 kullanıyorum, ne yapmalıyım?
PHP 7.4 için resmî sürüm yok; yalnızca kaynak kod yamaları ve bazı dağıtım/LTS paketleri var. En güvenli çözüm desteklenen bir sürüme, tercihen 8.3 veya üzerine geçmektir.
WordPress eklentilerini güncellemek açığı kapatır mı?
Hayır. Açık PHP'nin kendisindedir. Sunucudaki PHP sürümünün güncellenmesi gerekir; bunu hosting firmanızdan teyit edin.
