Konuyu Okuyanlar: 1 Ziyaretçi

PHP2Shell Küresel Alarm: Devletler Siteleri Kapattı, Yama ve Kontrol Listesi

PHP2Shell Küresel Alarm: Devletler Siteleri Kapattı, Yama ve Kontrol Listesi
[Resim: attachment.php?aid=338]

Selamlar,

Forumda daha önce PHP2Shell açıklarının (CVE-2026-109618 ve CVE-2026-109619) teknik tarafına değinmiştik. Son 24 saatte konu "bir PHP açığı" olmaktan çıktı ve küresel bir olaya dönüştü: Almanya, Fransa, Belçika, Hollanda, Finlandiya ve Çekya'da bazı kamu siteleri önlem amaçlı kapatıldı, ABD NSA nadir görülen bir kamuya açık uyarı yayınladı, Japonya Başbakanı Sanae Takaichi sosyal medyadan site sahiplerine "bu gece harekete geçin" çağrısı yaptı. Bu yazıda olayın son durumunu, kimin ne yaptığını ve kendi sunucunuz için uygulanabilir kontrol listesini topluyorum.

Konuda anlatılacaklar
  1. PHP2Shell neden bu kadar büyük yankı yaptı?
  2. Dünyada kim ne yaptı: NSA, CISA, NCSC, Avrupa kamu kurumları
  3. Yamalı sürümler ve EOL dallar için durum
  4. Sunucu sahibi için adım adım kontrol listesi
  5. Yama sonrası iz arama ve sır (secret) rotasyonu

Kısa özet: ne oldu?
PHP güvenlik ekibi 21 Ekim 2026'da iki kritik, kimlik doğrulamasız uzaktan kod çalıştırma (RCE) açığı için acil yama yayınladı. BleepingComputer'ın aktardığına göre iki açık da aynı temel soruna dayanıyor: bir istek anormal biçimde sonlandığında PHP belleği bozuk bir durumda bırakabiliyor. Etkilenen kurulumlar web isteği sunan tüm PHP kurulumları: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. PHP ekibi riski en yüksek gördüğü yapıyı mod_php olarak belirtiyor; burada uygulama kodu hiç çalışmadan, tek bir kimlik doğrulamasız istekle saldırının tetiklenebildiği gösterilmiş.

Tenable ve Carthage Electronics özetlerine göre iki CVE de CVSS 4.0 ile 9.2 puan aldı. Açıklar Ağustos ayında Wiz ve Calif araştırmacıları tarafından, OpenAI ile birlikte yapay zeka destekli araştırma sırasında bildirildi.

Dünyada kim ne yaptı?
  • NSA (ABD): BBC'ye göre ajans, hemen yama yapamayan kurumlara sistemleri çevrim dışı almalarını tavsiye etti ve açığın veritabanına "doğrudan bir yol" sağlayabileceğini söyledi.
  • CISA (ABD): 21 Ekim tarihli uyarıda kurumlara PHP sürümlerini envanterlemelerini, internete açık sistemlerden başlayarak hemen yamalamalarını, PHP 8.1 ve öncesini kullananların sistemleri yama yapılana kadar çevrim dışı almalarını ve PHP worker süreçlerinin kabuk başlatması gibi şüpheli davranışları izlemelerini istedi. Yayın anında CISA kendi tarafında istismar gözlemlemediğini not etti.
  • NCSC (İngiltere): Kurumların hemen güncellemesini ya da yama yapılana kadar sistemleri kapatmasını, ayrıca saldırganın bıraktığı arka kapıları kontrol etmesini istedi.
  • Avrupa: Al Jazeera'ya göre Almanya Dijital Dönüşüm Bakanlığı bazı siteleri önlem olarak kapattı, Fransa İçişleri Bakanlığı yerel idare sitelerini devre dışı bıraktı; Belçika, Hollanda, Finlandiya ve Çekya da yama için siteleri kapattığını açıkladı.
  • Wikimedia: BBC'ye göre önlem amaçlı bazı sistemlerini kapattı.
  • Amazon: BBC'nin aktardığına göre kamuya açıklamadan günler önce birden fazla istismar denemesiyle hedef alındığını söyledi.

Cloudflare tarafında ise BleepingComputer'a göre şirket bilinen istismar yöntemlerine karşı WAF kuralları devreye almıştı; ancak şirketin CTO'su da bu korumaların geçici olduğunu ve kalıcı çözümün yama olduğunu vurguladı.

Yamalı sürümler
Kod:
PHP 8.5 -> 8.5.12 PHP 8.4 -> 8.4.27 PHP 8.3 -> 8.3.36 PHP 8.2 -> 8.2.35 PHP 8.1 / 8.0 / 7.4 -> resmi sürüm yok; PHP ekibi minimal kaynak backport'ları yayınladı
PHP 8.1 ve öncesi artık PHP projesinden güncelleme almıyor. Dağıtım veya LTS sağlayıcınız backport yayınlamış olabilir; aksi halde desteklenen bir sürüme geçmek gerekiyor.

Sunucu sahibi için kontrol listesi
  1. Envanter: CLI'daki sürüm ile web sunucusunun kullandığı sürüm farklı olabilir. İkisine de bakın.
  2. Güncelleme: Resmi sürüme ya da dağıtımınızın yamalı paketine geçin. Debian/Ubuntu/RHEL ailesinde backport'lar eski sürüm numarasını koruyabildiği için paket changelog'unda CVE numaralarını arayın.
  3. Yeniden başlatma: Paket güncellemesi, eski süreçler yaşadıkça işe yaramaz. Apache, PHP-FPM havuzları, LiteSpeed/lsphp, FrankenPHP ve uzun ömürlü worker'ları (kuyruk işçileri, Octane, Swoole) yeniden başlatın.
  4. Konteyner: Eski imajı yeniden başlatmak yetmez; yamalı base imajla yeniden build edip deploy edin.
  5. Paylaşımlı hosting: WordPress veya eklenti güncellemek PHP'yi güncellemez. Barındırma firmanızdan sitenizi sunan PHP sürümünün 21 Ekim düzeltmesini içerdiğini yazılı olarak teyit edin.

Kod:
# Sürüm kontrolü (kendi sunucunuz) php -v php-fpm8.3 -v 2>/dev/null || true # Debian/Ubuntu: changelog'da CVE ara apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961(8|9)" | head # RHEL ailesi rpm -q --changelog php-fpm 2>/dev/null | grep -E "CVE-2026-10961(8|9)" | head # Servisleri yeniden başlat (örnek) sudo systemctl restart php8.3-fpm apache2

Hemen yama yapamıyorsanız
Carthage Electronics'in derlediği özete göre PHP ekibi geçici ayarlar önerdi: php.ini veya FPM havuzunda session.upload_progress.enabled=0, uygulamaların değiştiremeyeceği şekilde ayarlanmış bir memory_limit, makul bir post_max_size ve web sunucusu/proxy katmanında istek boyutu limitleri. PHP 8.5 için ayrıca fatal_error_backtraces=0. PHP ekibi bu ayarların yalnızca riski azalttığını, sunucuyu güvenli yapmadığını özellikle vurguluyor. Bu arada siteyi WAF arkasına almak da geçici bir katman olabilir.

Yama sonrası: iz arama ve sır rotasyonu
Açıklardan biri bellek ifşasına da izin verdiği için, yamasız dönemde internete açık kalan sunucularda veritabanı parolaları, API anahtarları ve oturum bilgilerinin sızmış olabileceğini varsaymak mantıklı. Önerilen adımlar:
  • Bellek limiti hatalarıyla biten olağandışı multipart POST istekleri ve ani HTTP 500 dalgaları için erişim/hata loglarını tarayın.
  • Upload ve cache dizinlerinde tanımadığınız .php dosyalarını, yeni yönetici hesaplarını kontrol edin.
  • Veritabanı parolalarını, API anahtarlarını ve WordPress salt değerlerini yenileyin, tüm kullanıcı oturumlarını sonlandırın.

Neden bu olay önemli?
BBC'ye konuşan araştırmacılar, açıkların on yıldan uzun süredir kodda durduğunu ve değişenin "bulma kabiliyetimiz" olduğunu söylüyor. PHP Foundation da yapay zeka araçlarının hem savunucular hem saldırganlar için hata bulmayı hızlandırdığını ve rapor sayısının artmaya devam edeceğini belirtti. Yani önümüzdeki dönemde "eski ama yeni bulunmuş" kritik açıklar daha sık gündeme gelecek; yama hızınız artık doğrudan güvenlik seviyeniz demek.

Sizin barındırma firmanız yamayı ne zaman uyguladı, teyit alabildiniz mi? Yorumlarda (hassas bilgi vermeden) paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar


Ek DosyalarEkran Görüntüleri
   
Cevapla



Hızlı Menü: