Proje
frontend.usefulLinks
frontend.officeAddress

Aşağıdaki iletişim formunu doldurarak bizimle iletişime geçin

info@orhunajans.com

PHP2Shell: Kritik PHP Açığına Karşı Acil Önlem Rehberi (2026)

PHP2Shell: Kritik PHP Açığına Karşı Acil Önlem Rehberi (2026)
 Güvenlik
 
 29
Paylaş :

İnternetin yaklaşık %70’ini ayakta tutan PHP motorunda Heartbleed / Log4Shell ölçeğinde bir olay yaşanıyor. Açık WordPress eklentinizde veya Laravel kodunuzda değil; PHP’nin kendi bellek yönetimi ve hata işleme katmanında. Eklenti güncellemek veya WAF kuralı eklemek yetmez — PHP runtime sürümünü yükseltmek zorundasınız.

Bu yazıda neler var?
  1. PHP2Shell nedir?
  2. Kimler etkileniyor?
  3. Güvenli PHP sürümleri
  4. 15 dakikalık müdahale planı
  5. Geçici önlemler
  6. İzleme checklist’i
  7. Sık sorulan sorular
9.2CVSSv4 kritik skor
(her iki CVE)
~%70Web siteleri PHP
üzerinde çalışıyor
2 CVEOOM bozulması +
use-after-free
ŞimdiTek tam çözüm:
hemen yama

PHP2Shell nedir?

Wiz, Calif ve OpenAI araştırmacılarının (AI destekli analizle) ortaya çıkardığı bu açıklar, PHP çekirdeğindeki on yıldan uzun süredir var olan bellek güvenliği zafiyetlerine dayanıyor. Saldırgan özel HTTP istekleriyle kimlik doğrulaması olmadan sunucuda keyfi kod çalıştırabilir; bazı senaryolarda diğer isteklere ait şifre, token ve API anahtarlarını bellekten okuyabilir.

Risk en yüksek Apache + mod_php kurulumlarında: istismar, uygulama kodu bile çalışmadan tetiklenebiliyor. PHP-FPM, php-cgi, FrankenPHP ve LiteSpeed de etkileniyor.

CVE-2026-109618

OOM bozulması ile RCE

İstek memory_limit sınırına kritik anda ulaşırsa kısmen başlatılmış dahili veri geride kalabiliyor. Temizlik aşamasında bu veri “geçerli” sayılıp bellek bozuluyor → uzaktan kod çalıştırma.

CVE-2026-109619

Eski global durum ile RCE

Ölümcül bir hata, worker’ın önceki isteğe ait belleğe işaret etmesine yol açabiliyor. Sonraki istek bu serbest bırakılmış belleği kullanıyor (use-after-free) — RCE ve bellek sızıntısı doğrulandı.

Orhun Ajans notu: Bu açık CMS’ten bağımsız. WordPress, Laravel, Magento veya özel yazılım fark etmez — savunmasız PHP sürümü çalışıyorsa risk aynıdır. Yönettiğimiz sunucularda yama önceliklendirilmiştir; kendi hosting’iniz varsa aşağıdaki planı hemen uygulayın.

Kimler etkileniyor?

  • PHP 5.4’ten itibaren neredeyse tüm sürümler Desteklenen hatlarda yama geldi; 8.1 ve öncesi resmi sürüm almıyor (kaynak backport var).
  • WordPress, Drupal, Joomla, Laravel, Magento… Uygulama güvenli olsa bile runtime savunmasızsa risk devam eder. Eklenti/tema güncellemesi bu CVE’leri kapatmaz.
  • Hosting, VPS, shared sunucu, appliance’lar PHP gömülü cihazlar ve yönetim panelleri de risk altında.

Güvenli sürümler (hemen buraya çıkın)

Mevcut hatDurumHedef sürüm
PHP 8.5.x (< 8.5.12)Savunmasız8.5.12
PHP 8.4.x (< 8.4.27)Savunmasız8.4.27
PHP 8.3.x (< 8.3.36)Savunmasız8.3.36
PHP 8.2.x (< 8.2.35)Savunmasız8.2.35
PHP 7.4 – 8.1EOL / resmi yokKaynak backport veya desteklenen hatta geçiş
PHP ≤ 7.3EOL, yama yokDesteklenen PHP 8.x’e migrate

15 dakikalık müdahale planı

  1. Sürümü tespit edinSSH veya hosting panelinden çalışan PHP sürümünü kontrol edin.php -v
    # veya: <?php echo PHP_VERSION; ?>
  2. Yamalı sürüme yükseltinapt / yum / remi / ondrej PPA / CloudLinux selector / cPanel MultiPHP ile yamalı sürüme geçin. Dağıtım paketi kullanıyorsanız vendor advisory’yi kontrol edin.
  3. Tüm PHP worker’larını yeniden başlatınAksi halde eski process’ler savunmasız kalır.sudo systemctl restart php8.3-fpm
    sudo systemctl restart apache2 # veya nginx + fpm
  4. DoğrulayınCanlı ortamda sürümün gerçekten yamalı olduğunu teyit edin. Staging smoke test → production.
  5. 17 Ekim’den itibaren logları tarayınAmazon Threat Intelligence’a göre ilk deneme 17 Ekim’de görüldü. Worker’ların shell spawn etmesi, beklenmeyen outbound bağlantılar, yeni şüpheli .php dosyaları ve ani crash/OOM spike’larına bakın.

Yama öncesi geçici önlemler

Önemli: Bunlar riski azaltır ama kurulumu güvenli yapmaz. PHP ekibi tek tam çözümün güncelleme olduğunu belirtiyor. Güncelleyemiyorsanız internete açık sistemleri izole edin.

  • CVE-2026-109618 memory_limit=-1 (uygulamanın override edemeyeceği şekilde). Yan etki: bellek kontrolü zayıflar.
  • CVE-2026-109619 session.upload_progress.enabled=0 ve PHP 8.5’te fatal_error_backtraces=0. Sonra tüm worker’ları restart edin.
  • WAF (Cloudflare vb.) Bilinen vektörlere karşı kurallar yayımlandı; yalnızca WAF trafiği için ve sadece geçici bariyer.

İzleme checklist’i

  • Worker → shell php-fpm / httpd sürecinin sh, bash, curl, wget başlatması.
  • Web root’ta yeni dosyalar Özellikle webshell .php, gizli dizinler, 17 Ekim sonrası değişen dosyalar.
  • Anormal istek kalıpları Büyük POST body, OOM’a zorlayan istekler, tekrarlayan fatal error / worker crash.

Sık sorulan sorular

Sitem WordPress / Laravel; eklenti güncellemesi yeterli mi?
Hayır. Açık PHP motorunda. Tema, eklenti veya framework güncellemesi bu CVE’leri kapatmaz. Hosting paneli veya sunucudan PHP runtime’ını yükseltin.
Shared hosting kullanıyorum, ne yapmalıyım?
Hemen sağlayıcıya ticket açın. MultiPHP varsa yamalı sürümü seçin. Paket yoksa bakım modu + WAF + izolasyonu değerlendirin.
WAF tek başına korur mu?
Hayır. Bilinen kalıpları keser; yeni vektörler ve doğrudan IP trafiği için yetersizdir. Yama şart.
Eski PHP 7.4 / 8.0 / 8.1 ne olacak?
Resmi binary yok; minimal kaynak backport paylaşıldı. Dağıtımınız backport veriyorsa uygulayın — uzun vadede desteklenen 8.2+ hatta geçin.
Sömürü aktif mi?
Evet. Amazon, Cloudflare ve watchTowr erken / yaygın denemeler bildirdi. İlk deneme 17 Ekim’de (açıklamadan 4 gün önce) honeypot’ta görüldü.

Sunucunuzda PHP yaması mı gerekiyor?

Orhun Ajans olarak yönettiğimiz projelerde PHP2Shell yamasını önceliklendiriyoruz. Kendi sunucu veya hosting hesabınız için sürüm kontrolü, güvenli yükseltme ve sonrası izleme desteği sunuyoruz.

Destek alın

Kaynaklar: PHP Advisory · PHP Foundation · CISA · Wiz · NCSC-NL

Yeni Yorum Ekle