PHP güvenlik açığı PHP2Shell: Sitelerin yüzde 70'ini tehdit eden iki kritik açık ve yapılması gerekenler

PHP'nin çekirdeğinde bulunan ve "PHP2Shell" adı verilen iki kritik PHP güvenlik açığı, saldırganların hiçbir kullanıcı adı ya da parola gerekmeden sunucuda kod çalıştırmasına izin veriyor. PHP ekibi 21 Ekim 2026'da 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleriyle açıkları kapattı ve tüm kullanıcıları hemen güncellemeye çağırdı. Sorunu bağımsız olarak bulan ekiplerden Wiz Research'e göre PHP, dünyadaki web sitelerinin yaklaşık yüzde 70'inin arkasındaki dil. WordPress, Joomla, Drupal ve Wikipedia'yı çalıştıran MediaWiki de bu dil üzerine kurulu. Açıkların bir kısmı PHP 5.4'e, yani 2012'ye kadar geriye uzanıyor.

PHP2Shell nedir? İki ayrı açık, aynı sonuç

PHP2Shell tek bir hata değil, birbirine bağlı iki açığın ortak adı. İkisinin de kökü, PHP'nin bir isteği işlerken yarıda kesilmesi durumunda kendi iç belleğini nasıl temizlediğine dayanıyor. CVSS 4.0 ölçeğinde ikisi de 10 üzerinden 9,2 puanla "kritik" olarak sınıflandırıldı.

• CVE-2026-109618 (bellek tükenmesi kaynaklı bozulma): PHP, bir isteğin işlenmesi sırasında bellek sınırına (memory_limit) ulaştığında işi yarıda bırakıyor. Sorun şu ki bu kesinti, isteğe ait bazı iç veriler henüz tam hazırlanmamışken yaşanabiliyor. İstek kapatılırken PHP bu yarım kalmış veriyi geçerli sanıp kullanıyor. Saldırgan, özel hazırlanmış bir dosya yükleme isteğiyle (multipart form verisi) belleği bilerek tüketip bu durumu tetikleyebiliyor. GitHub'daki teknik bildirime göre beyan edilmiş içerik uzunluğu olmayan istekler, tek bir parçaya sınırsız sayıda başlık eklemek ya da boş dosya alanlarını iç içe alan adlarıyla çoğaltmak bu yollardan bazıları.
• CVE-2026-109619 (eskimiş genel durum): PHP işçileri (worker) aynı süreçte art arda birçok isteğe hizmet veriyor. Bir istek ölümcül bir hatayla ya da bellek tükenmesiyle kesildiğinde, o isteğe ait bazı durum bilgileri silinmesi gerekirken işçinin hafızasında kalabiliyor. Aynı işçiye gelen bir sonraki istek, belleği çoktan serbest bırakılmış bu bilgiye dokununca "use-after-free" denen hata ortaya çıkıyor. Doğrulanmış saldırı yollarından biri, PHP'de varsayılan olarak açık gelen oturum yükleme ilerlemesi (session upload progress) özelliğinden geçiyor. Uygulamanın session_start() çağırması bile gerekmiyor.

Bu PHP güvenlik açığı neden bu kadar ciddi?

Bu açıkları sıradan güvenlik hatalarından ayıran üç nokta var. Birincisi, açık uygulamanın kodunda değil PHP'nin kendisinde. Wiz'in ifadesiyle sitenizin kodu kusursuz olsa bile, etkilenen bir PHP sürümünde çalışan basit bir "Merhaba Dünya" sayfası bile savunmasız kalabiliyor. İkincisi, saldırı için giriş yapmak gerekmiyor; internetten gelen tek bir anonim istekle başlıyor. Üçüncüsü, PHP projesine göre Apache'nin mod_php modülünde saldırı, uygulama kodu daha çalışmaya başlamadan tetiklenebiliyor. Bu yüzden PHP ekibi riski en yüksek ortam olarak mod_php'yi gösteriyor. Ancak PHP-FPM, php-cgi, FrankenPHP ve LiteSpeed de etkilenenler listesinde.

Wiz Research ekibi bu açıkları tek bir istismar betiğinde birleştirdi. Betik, WordPress, Drupal ve Joomla'nın en güncel resmî kapsayıcı (container) imajlarında kimlik doğrulaması olmadan kod çalıştırmayı başardı. Kod çalıştırmaya gerek kalmadan PHP işçisinin belleğini okuyabildiklerini de gösterdiler. Bu bellekte başka ziyaretçilere ait parolalar, oturum anahtarları, API anahtarları ve sertifikalar bulunabiliyor. Wiz, PHP2Shell'i 2014'teki Heartbleed ve 2021'deki Log4Shell ile aynı kategoride görüyor.

Açıklar nasıl ortaya çıktı?

Açıklar, Calif adlı güvenlik şirketindeki araştırmacılar ile Wiz Research tarafından birbirinden bağımsız olarak bulunup PHP ekibine bildirildi. Wiz, araştırma boyunca kendi aracı Wiz Atlas'ın yanında Google'ın Gemini 4 Argon modelinden ve OpenAI'ın GPT-5.6 Sol modelinden yararlandığını açıkladı. Şirkete göre hatalı kod on yılı aşkın süredir PHP'nin içindeydi. Ancak bunu çalışan bir saldırıya dönüştürmek; birden fazla hatayı zincirlemeyi ve her hedefin bellek düzenine göre ayar yapmayı gerektiriyordu. Bu da insan araştırmacılar için neredeyse pratik olmayacak kadar uğraştırıcıydı. Wiz, büyük yapay zekâ modellerinin bu engeli ciddi ölçüde düşürdüğünü vurguluyor. Yapay zekânın yazılımlarda açık bulma hızının nasıl arttığını daha önce Chrome örneğiyle ele almıştık. Yıllarca fark edilmeden kalan çekirdek açıklarının bir başka örneği de Linux'taki Dirty Frag olmuştu.

Koordineli açıklama aslında 22 Ekim'e planlanmıştı. Ancak watchTowr'un aktardığına göre ayrıntılar 20 Ekim'de sosyal medyaya sızdı. Bunun üzerine PHP ekibi acil bir güvenlik sürümü duyurdu ve yamaları 21 Ekim'de Türkiye saatiyle 17.00 civarında yayımladı. Linux dağıtımlarına ve uzun süreli destek sağlayıcılarına yamalar önceden iletilmişti.

Saldırılar başladı mı?

Güvenlik şirketi watchTowr, yamaların çıktığı 21 Ekim'den itibaren kendi tuzak (honeypot) ağında gerçek saldırı girişimleri gördüğünü açıkladı. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA) ise 22 Ekim itibarıyla iki açığı da istismar edilen açıklar kataloğuna (KEV) eklemiş değil. Wiz; Cloudflare, Akamai, Fastly, AWS ve Microsoft gibi altyapı şirketlerinin, yama yapamayan müşterileri için geçici koruma kuralları hazırladığını belirtiyor. Bu kurallar yalnızca zaman kazandırır. PHP ekibinin net ifadesiyle tam koruma sağlamanın tek yolu güncellemek. Üstelik sunucuya CDN üzerinden değil doğrudan gelen trafik bu filtrelerin hiçbirinden geçmiyor.

Hangi PHP sürümleri etkileniyor?

Burada önemli bir ayrıntı var: Sürüm numarası tek başına yeterli bir ölçüt değil. Ubuntu gibi dağıtımlar yamaları eski sürüm numarasını koruyarak paketlerine ekliyor. Örneğin Ubuntu'nun 21 Ekim tarihli USN-8948-1 bildirimine göre Ubuntu 24.04'te düzeltme 8.3.6-0ubuntu0.24.04.13, Ubuntu 22.04'te ise 8.1.2-1ubuntu2.28 paket sürümüyle geldi. Yani php -v komutu 8.3.6 dese bile paket yamalı olabilir. Asıl bakılması gereken paket sürümü. PHP ekibi ayrıca gönüllü olarak sürdürülen Remi deposunu kullananları uyardı: Bu deponun yaması 21 Ekim'de hazır değildi.

Site sahipleri ne yapmalı?

1. Sürümünüzü öğrenin: WordPress kullanıyorsanız yönetim panelinde Araçlar > Site Sağlığı > Bilgi > Sunucu bölümünde PHP sürümü yazıyor. cPanel, Plesk veya CyberPanel gibi hosting panellerinde PHP sürüm yöneticisinden de görebilirsiniz.
2. Paylaşımlı hosting kullanıyorsanız sunucuyu siz yönetmediğiniz için güncellemeyi hosting firmanız yapmalı. Firmanıza destek talebi açıp PHP2Shell yamalarının (CVE-2026-109618 ve CVE-2026-109619) uygulanıp uygulanmadığını yazılı olarak sorun.
3. Kendi sunucunuzu yönetiyorsanız yüklü olan her PHP dalını, OPcache dahil tüm modülleriyle birlikte güncelleyin. CyberPanel'in açıklamasına göre PHP çekirdeğini güncelleyip eski OPcache modülünü bırakmak eksik bir düzeltme. Aynı açıklamaya göre CyberPanel panelin kendisi için ayrı bir PHP kopyası kullanıyor (/usr/local/lscp/fcgi-bin/lsphp). Bu kopya paket güncellemesiyle kendiliğinden yenilenmediği için ayrıca değiştirilmesi gerekiyor.
4. Tüm PHP işçilerini yeniden başlatın. Bellekte çalışmaya devam eden eski işçiler güncellemeden sonra da açık kodla hizmet vermeyi sürdürebilir. Sonrasında gerçek bir web isteğiyle hangi sürümün çalıştığını doğrulayın.

Hemen güncelleyemeyenler için geçici önlemler

PHP projesi aşağıdaki ayarların yalnızca belirli saldırı yollarını kapattığını, kurulumu güvenli hâle getirmediğini özellikle vurguluyor:

• session.upload_progress.enabled = 0 ayarı doğrulanmış oturum saldırı yolunu kapatıyor. Bu ayar ini_set() veya .user.ini ile değil, ana php.ini ya da FPM havuz yapılandırmasıyla verilmeli ve ardından tüm işçiler yeniden başlatılmalı. PHP ekibi bu özelliğin yamadan sonra da kapalı tutulmasının akıllıca olabileceğini belirtiyor; çoğu site zaten kullanmıyor.
• PHP 8.5'te fatal_error_backtraces = 0 ayarı, doğrulanmış istismarda kullanılan yollardan birini kapatıyor.
• Dosya yükleme kullanmayan uygulamalarda post_max_size değerini 8M'ye, yükleme gerekiyorsa 32M'ye çekmek öneriliyor. upload_max_filesize bunun altında kalmalı.
• memory_limit = -1 ayarı bellek tükenmesi kaynaklı yolu kapatıyor ama yan etkisi büyük: tek bir istek sunucunun tüm belleğini tüketebilir. Bu yüzden ancak sunucu düzeyinde başka bir bellek sınırıyla birlikte düşünülmeli. PHP ekibi RLIMIT_AS veya RLIMIT_DATA kullanılmamasını özellikle istiyor; bu sınırlar açığı tetikleyen bellek hatasını kendileri doğurabiliyor.
• Hata gösterimini kapatmak (display_errors, error_reporting ya da @ işareti) koruma sağlamıyor.

WordPress siteleri için eklenti kaynaklı açıklar da her zamanki gibi gündemde. Popüler WordPress eklentilerini hedef alan saldırıları anlattığımız yazıda olduğu gibi, eklentileri güncel tutmak ve kullanılmayanları kaldırmak bu dönemde daha da önemli. Bu PHP güvenlik açığı ise eklentiden bağımsız, doğrudan dilin kendisinde olduğu için tek kalıcı çözüm sunucudaki PHP'nin güncellenmesi.