PHP2Shell yamaları çıktı: Siteler neden kapandı ve 17 Ekim'den bu yana sunucunuzu neden kontrol etmelisiniz?

Dün, 21 Ekim 2026'da PHP ekibi PHP2Shell adı verilen iki kritik açığı (CVE-2026-109618 ve CVE-2026-109619) kapatan sürümleri yayımladı. Önceki yazımızda sızan ambargoyu ve yamaya nasıl hazırlanılacağını konuşmuştuk. Artık yamalar elimizde; ancak geçen 24 saat, bu olayın yalnızca bir “güncelle ve unut” vakası olmadığını gösterdi. Avrupa'da kamu siteleri kapatıldı, büyük topluluklar servislerini durdurdu ve Amazon, ilk saldırı denemesinin açıklamadan dört gün önce yapıldığını duyurdu.

Bu yazıda neler olduğunu, neden bu kadar ciddiye alındığını ve özellikle paylaşımlı hosting ya da kendi VPS'ini yöneten Türk geliştiriciler için somut adımları toparlıyorum.

Kısaca ne oldu?

İki açık da PHP motorunun kendisinde, yani uygulamanızın kodunda değil. PHP güvenlik ekibi ikisine de CVSS v4.0 ölçeğinde 9.2 (kritik) puan verdi ve ikisinin de kimlik doğrulaması olmadan uzaktan istismar edilebildiğini söylüyor.

• CVE-2026-109618: PHP, istek verisi henüz yarım hazırlanmışken bellek sınırına takılırsa (out-of-memory), sonraki temizlik aşaması bu yarım veriyi geçerliymiş gibi işleyebiliyor.
• CVE-2026-109619: Bir isteğe ait iç durum, belleği serbest bırakıldıktan sonra worker'da kalabiliyor. Aynı worker'a düşen sonraki bir istek bu bayat veriyi kullanabiliyor; klasik bir use-after-free.

Araştırmacılara göre kusurlu kod yolları PHP 5.4'e kadar uzanıyor ve varsayılan yapılandırmalar etkileniyor. Açığı bulan ekiplerden Calif, WordPress, Drupal, Joomla ve Magento'nun belirli sürümlerinde girişsiz uzaktan kod çalıştırmayı gösterdi. Wiz araştırmacıları da hataların yıllardır orada olduğunu, ancak istismar zincirinin çok karmaşık olduğunu ve yapay zeka modellerinin bu bariyeri ciddi ölçüde düşürdüğünü belirtiyor. Bence olayın asıl kalıcı dersi de bu: eskiden “teorik” sayılan bellek hataları artık çok daha hızlı silaha dönüşebiliyor.

Hangi sürümler güvende?

| Dal | Durum |
|---|---|
| 8.5 | 8.5.12 ile düzeltildi |
| 8.4 | 8.4.27 ile düzeltildi |
| 8.3 | 8.3.36 ile düzeltildi |
| 8.2 | 8.2.35 ile düzeltildi |
| 7.4, 8.0, 8.1 | Resmi sürüm yok; yalnızca kaynak kod düzeyinde asgari backport |
| 5.4 – 7.3 | Ömrünü doldurmuş, PHP projesinden düzeltme yok |

Risk en yüksek Apache mod_php kurulumlarında: tek bir girişsiz istek, uygulama kodu hiç çalışmadan saldırıyı tetikleyebiliyor. Ama PHP-FPM, php-cgi, FrankenPHP ve LiteSpeed de kapsam içinde. Yani “ben FPM kullanıyorum, bana bir şey olmaz” rahatlığına yer yok.

Siteler neden kapandı?

Ambargo 20 Ekim'de Hacker News ve sosyal medya üzerinden delindi. PHP ekibi 22 Ekim'e planladığı yayını bir gün öne çekti ve 21 Ekim 14:00 UTC'de sürümleri çıkardı. Cloudflare ise yamadan saatler önce, 07:43 UTC civarında ilk saldırıları gördüğünü bildirdi.

Bu arada yöneticiler kötü bir seçimle karşı karşıyaydı: yaması henüz olmayan bir açığa karşı açık kalmak ya da siteyi kapatmak. Birleşik Krallık NCSC'si, hemen güncellenemeyen sistemlerin çevrim dışı alınmasını önerdi. Sansec'in aktardığına göre Hollanda'da Tweakers, Temsilciler Meclisi, Hollanda NCSC'si ve Security.NL önlem olarak kapatıldı. Wikipedia'daki derlemeye göre Wikimedia Vakfı destek servislerinin bir kısmını (Phabricator dahil) durdurdu; 4chan ve Something Awful gibi forumlar da bir süre erişilemez oldu.

Bu tablo bize şunu söylüyor: PHP'nin ne kadar yaygın olduğunu biliyorduk, ama “yamasız bir motor açığı” senaryosunda kapatmanın meşru bir savunma seçeneği olduğunu büyük kurumlar ilk kez bu kadar görünür biçimde uyguladı.

Ambargo öncesi saldırı iddiası

En rahatsız edici gelişme Amazon'dan geldi. Amazon Threat Intelligence, MadPot bal küpü ağında 17 Ekim'de, yani açıklamadan dört gün önce, PHP2Shell istismar denemesi kaydettiğini açıkladı. Deneme ticari bir anonimleştirme servisine bağlı bir IP'den gelmiş; saldırganın bilgiye nasıl ulaştığı bilinmiyor. watchTowr da her iki açığa yönelik aktif denemeler gördüğünü söylüyor.

Öte yandan PHP Vakfı, sızıntı sonrası ortaya çıkan PoC'ları incelediğini ve yayın anında çalışan bir istismar bulmadığını belirtti. Tenable da dolaşımdaki “exploit” kodlarının doğrulanmadığını ve zararlı yazılım içerebileceğini hatırlatıyor. Merak edip GitHub'dan rastgele PoC indirip çalıştırmak, kendi makinenizi riske atmak demek.

Pratik sonuç: Amazon, incelemelere 17 Ekim'den itibaren başlanmasını öneriyor. Yamayı bugün kursanız bile, o tarihten bu yana sunucunuzda ne olduğuna bakmanız gerekiyor.

Adım adım ne yapmalı?

1. Web'e hizmet veren PHP'yi tespit edin

Komut satırındaki PHP ile web'e yanıt veren PHP aynı olmayabilir. İkisine de bakın:

php -v
php-fpm8.3 -v          # dağıtımınıza göre adı değişir
apache2ctl -M | grep -i php   # mod_php yüklü mü?

Docker kullanıyorsanız temel imajınızdaki sürümü kontrol edin. Dağıtım paketleri düzeltmeyi sürüm numarasını değiştirmeden backport edebilir; bu yüzden Debian, Ubuntu, RHEL gibi dağıtımların güvenlik duyurularına da bakın.

2. Güncelleyin ve worker'ları yeniden başlatın

8.2 ve üzeri için ilgili yama sürümüne geçin. Ardından PHP-FPM ve Apache'yi yeniden başlatın; eski kod bellekte çalışmaya devam ediyorsa yama işe yaramaz. Konteynerlerde imajı yeniden derleyip yeniden dağıtın. Remi deposunu kullananlar dikkat: 21 Ekim itibarıyla depoda güncelleme yoktu; dağıtım paketlerine geçmek ya da kaynaktan derlemek öneriliyor.

3. Paylaşımlı hosting kullanıyorsanız

cPanel veya Plesk panelinizde seçili PHP sürümüne bakın ve 8.1 ya da daha eskiyse desteklenen bir dala geçin. Asıl motoru hosting firması günceller; firmanıza yazıp yamanın uygulandığını açıkça teyit ettirin. “Sitem küçük, kimse uğraşmaz” düşüncesi burada geçerli değil, çünkü bu tür açıklar otomatik taramalarla toplu olarak istismar ediliyor.

4. Hemen güncelleyemiyorsanız

Resmi geçici önlemler var ama PHP ekibi bunların hiçbirinin tam koruma sağlamadığını açıkça söylüyor:

• session.upload_progress.enabled=0
• memory_limit=-1 (uygulamanın ezemeyeceği şekilde; bunun yerine konteyner veya cgroup bellek sınırı kullanın)
• PHP 8.5'te ayrıca fatal_error_backtraces=0
• Değişikliklerden sonra tüm worker'ları yeniden başlatın.

Cloudflare, bilinen saldırı vektörleri için ücretsiz plan dahil tüm müşterilerine WAF kuralı yayımladı; ama bu yalnızca Cloudflare üzerinden geçen trafiği kapsıyor. Yamalayamadığınız ve kritik olan bir sistem varsa, NCSC ve CERT-EU'nun önerdiği gibi internetten izole etmek ya da geçici olarak kapatmak hâlâ en güvenli yol.

5. 17 Ekim'den bu yana izleri arayın

watchTowr, değişiklik yapmadan önce logları ve şüpheli dosyaları yedeklemeyi öneriyor. Ardından şunlara bakın:

• Web dizinlerinde yeni veya değişmiş PHP dosyaları (web shell)
• Beklenmeyen cron işleri ve yeni kullanıcı hesapları
• PHP hata logunda “Unknown on line 0” ile biten bellek tükenmesi hataları
• Apache loglarında worker segfault'ları
• Web worker'ının sh veya bash başlatması (en güçlü istismar işareti)

Datadog'un analizine göre çok büyük alan adları içeren form POST'ları da şüpheli trafiğin göstergesi olabilir.

Son söz

PHP2Shell, PHP 8.1 ve öncesinde kalan projeler için bir uyarıdan çok bir fatura. Ömrünü doldurmuş sürümde çalışan her site artık yalnızca teknik borç değil, açık bir güvenlik riski. Bu haftanın yapılacaklar listesi net: sürümü tespit et, güncelle, worker'ları yeniden başlat ve 17 Ekim'den bu yana logları incele. Eski sürüme bağlı kalmış projeleriniz varsa, yükseltme planını artık ertelemeyin.