PHP2Shell Açığı Nedir ve Nasıl Kapatılır?

PHP2Shell Açığı Nedir ve Nasıl Kapatılır?

Son güncelleme: 22 Ekim 2026. Durum hâlâ gelişiyor; yeni bilgiler geldikçe bu yazıyı güncelleyeceğiz.

21 Ekim 2026'da PHP projesi, PHP motorundaki iki kritik açık için acil güvenlik güncellemeleri yayınladı. Birlikte PHP2Shell olarak anılan CVE-2026-109618 ve CVE-2026-109619, bir saldırganın giriş yapmadan sunucuda kod çalıştırmasına izin verebilir; ayrıca şifreler, API anahtarları ve token'lar gibi bellekte tutulan verileri açığa çıkarabilir. PHP2Shell'i sıra dışı kılan, sorunun bulunduğu yerdir: bir eklentide veya framework'te değil, PHP'nin kendisinde. Bu da iyi yazılmış bir Laravel uygulamasının, özenle bakımı yapılan bir WordPress sitesinin ve özel bir PHP sisteminin, sunucu yamasız bir PHP sürümü çalıştırıyorsa aynı şekilde risk altında olduğu anlamına gelir. İstismar denemeleri resmi açıklamadan önce bile başladı; bu yüzden PHP çalıştıran her ekip bunu acil durum olarak ele almalı. Bilmeniz gerekenler ve tam olarak ne yapmanız gerektiği aşağıda.

PHP2Shell Nedir?

PHP2Shell, PHP çalışma ortamındaki iki ayrı açığın ortak adıdır. Her ikisi de CVSS v4 ölçeğinde 9.2 (Kritik) puan almıştır. Resmi yayından önce internette dolaşan 10.0 puanı, PHP'nin verdiği puan değildir.

• CVE-2026-109618, PHP bir isteği işlerken belleği tükendiğinde tetiklenen bir bellek bozulması açığıdır. Ardından gelen temizlik sırasında PHP, yarım hazırlanmış istek verilerini geçerliymiş gibi işleyebilir.
• CVE-2026-109619 bir use-after-free açığıdır. Bir istekten kalan veriler, daha önce serbest bırakılmış belleği gösterebilir ve aynı PHP worker'ının işlediği sonraki bir istek bu veriyi kullanabilir. PHP, bu açığın bellek içeriğini de sızdırabildiğini doğruluyor.

Açıklı kod on yılı aşkın süredir mevcut; etkilenen kodun izi PHP 5.4'e kadar uzanıyor. Açıklar Wiz Research, Calif ve OpenAI'ın Codex Security ekibi tarafından bulunup bildirildi.

PHP2Shell Neden Bu Kadar Ciddi?

Üç etken PHP2Shell'i sıradan bir açıktan daha tehlikeli kılıyor. Birincisi, kimlik doğrulama gerekmiyor: saldırganın tek yapması gereken bir web sitesine istek göndermek. İkincisi, açıklar motorun içinde olduğu için güvenli uygulama kodu sizi korumuyor; bazı yapılandırmalarda açıklı yola uygulama kodu hiç çalışmadan bile ulaşılabiliyor. Üçüncüsü, bellek sızıntısı nedeniyle başarısız bir ele geçirme denemesi bile sunucudan hassas bilgi sızdırabilir.

Zamanlama da aciliyeti artırıyor. Amazon'un tehdit istihbaratı ekibi ilk istismar denemesini açıklamadan dört gün önce, 17 Ekim'de gözlemledi; 21 Ekim'de ise birden fazla saldırgandan yeni denemeler geldi. watchTowr ve Cloudflare de saldırılar bildirdi; Cloudflare, saldırganların güvenlik duvarı kurallarını atlatmak için payload'larını değiştirdiğini gözlemledi. CISA acil yama çağrısı yapan bir uyarı yayınladı. Bu güncelleme itibarıyla kamuoyuna doğrulanmış başarılı bir sızma yok, ancak bu hızla değişebilir.

Kimler Etkileniyor?

PHP projesine göre web isteği sunan her PHP kurulumu risk altında. Bu, PHP'yi çalıştırmanın tüm yaygın yollarını kapsıyor:

• Apache mod_php: en yüksek riskli olarak değerlendiriliyor, çünkü gösterilen saldırı uygulama kodu çalışmadan başarılı olabiliyor.
• PHP-FPM: Nginx ile ve tipik Laravel kurulumları dahil modern barındırma ortamlarının çoğunda kullanılıyor.
• php-cgi, FrankenPHP ve LiteSpeed.

Araştırmacılar WordPress, Drupal, Joomla ve Magento'nun belirli sürümlerine karşı girişsiz uzaktan kod çalıştırmayı doğruladı. Laravel için ayrı bir açıklama yapılmadı; ancak açıklar PHP motorunda olduğundan Laravel uygulamaları, üzerinde çalıştıkları PHP sürümüyle tam olarak aynı ölçüde risk altında.

Yamalı PHP Sürümleri

PHP projesi düzeltmeleri 21 Ekim 2026'da yayınladı. Bu dallardaki daha eski tüm sürümler açıklıdır:

• PHP 8.5: 8.5.12'de düzeltildi
• PHP 8.4: 8.4.27'de düzeltildi
• PHP 8.3: 8.3.36'da düzeltildi
• PHP 8.2: 8.2.35'te düzeltildi
• PHP 7.4, 8.0 ve 8.1: resmi sürüm yok; PHP projesi yalnızca sınırlı kaynak kod yamaları yayınladı
• PHP 7.3 ve öncesi: destek süresi dolmuş, PHP projesinden düzeltme gelmeyecek

Linux dağıtımları ve uzun süreli destek sağlayıcıları yamaları önceden aldı ve çoğu zaman bunları daha eski görünen sürüm numaralarıyla yayınlıyor. PHP'yi dağıtımınızın paketlerinden kuruyorsanız yalnızca sürüm numarasına güvenmek yerine paket değişiklik kaydında (changelog) CVE numaralarını arayın. Ayrıca PHP 8.2'nin desteği 31 Aralık 2026'da sona eriyor; bu, bir yükseltme planlamak için iyi bir an.

Sunucunuzun Etkilenip Etkilenmediğini Nasıl Kontrol Edersiniz?

İşe, PHP'nin çalıştığı her yerin eksiksiz bir listesini çıkararak başlayın: canlı ortam, test ortamı, iç araçlar ve unutulmuş eski siteler dahil. Saldırganlar tüm interneti tarar; küçük bir test sunucusu da ana uygulamanız kadar hedeftir. Ardından her birini kontrol edin:

• php -v komutunu ve PHP-FPM kullanılıyorsa php-fpm -v komutunu çalıştırın. Komut satırı ve FPM sürümleri her zaman aynı olmayabilir.
• Dağıtım paketleri için kurulu PHP paketinin değişiklik kaydında CVE-2026-109618 ve CVE-2026-109619'u arayın.
• Docker ve diğer container'lar için her temel imajın PHP sürümünü kontrol edin. İmaj etiketini güncellemek yetmez; imajlar yeniden derlenmeli ve container'lar yeniden dağıtılmalıdır.
• Paylaşımlı hosting, Plesk, cPanel veya yönetilen platformlar için sağlayıcınızın güvenlik duyurularını takip edin ve hangi PHP sürümlerinin yamandığını doğrulayın.
• composer update çalıştırmanın PHP2Shell'i düzeltmediğini unutmayın. Düzeltme uygulamanızın paketlerinde değil, PHP çalışma ortamındadır.

PHP2Shell Nasıl Düzeltilir?

PHP projesi, eksiksiz tek çözümün güncelleme olduğunu açıkça belirtiyor. Genel adımlar şunlar:

• PHP'yi yamalı bir sürüme güncelleyin veya dağıtımınızın yamalı paketini kurun.
• Tüm PHP süreçlerini yeniden başlatın: PHP-FPM havuzları, Apache ve uzun süre çalışan tüm worker'lar. Eski programı hâlâ bellekte çalıştıran bir sunucu hâlâ açıktır.
• PHP içeren tüm container imajlarını yeniden derleyin ve dağıtın.
• Çalışan sürümü tekrar kontrol ederek ve yamalı paketin aktif olduğunu doğrulayarak sonucu teyit edin.
• Yamadan sonra memory_limit ve post_max_size ayarlarını gözden geçirin. Düzeltme, sınıra ulaşıldığında süreci sonlandıran katı bir bellek sınırı getiriyor; alışılmadık derecede düşük sınırlar bellek yoğun işlerde yeni hatalara yol açabilir.

PHP 8.1 veya daha eski bir sürüm kullanıyorsanız en güvenli yol desteklenen bir dala yükseltmektir. Desteği sona ermiş bir sürüme resmi olmayan kaynak kod yamaları uygulamak mümkündür, ancak bu kısa vadeli bir önlem olarak görülmelidir.

Hemen Yama Yapamıyorsanız Geçici Önlemler

Hemen güncelleme mümkün değilse PHP projesi riski azaltan yapılandırma değişiklikleri öneriyor. Bunlar sunucuyu güvenli hale getirmez ve yamanın yerini tutmaz:

• CVE-2026-109618 için memory_limit=-1 ayarını uygulamaların ezemeyeceği şekilde sunucu veya FPM havuzu seviyesinde yapın ve post_max_size değerini uygulamanızın izin verdiği kadar düşük tutun.
• CVE-2026-109619 için session.upload_progress.enabled=0 ayarını yapın. PHP 8.5'te ek olarak fatal_error_backtraces=0 ayarlayın.
• Bu ayarları php.ini, FPM havuzu veya web sunucusu yapılandırmasında uygulayın. Uygulama içinden ini_set() ile veya .user.ini dosyasıyla yapılan değişiklikler işe yaramaz, çünkü çok geç devreye girer.
• Değişikliklerden sonra tüm PHP worker'larını yeniden başlatın.
• İstek boyutlarını web sunucusu veya reverse proxy seviyesinde sınırlayın; uygulamanız dosya yükleme kullanmıyorsa multipart istekleri PHP'ye ulaşmadan engelleyin.
• İnternete açık kritik PHP uygulamalarını yamalanana kadar ek erişim kontrollerinin arkasına almayı veya geçici olarak kapatmayı düşünün.

Cloudflare'in devreye aldığı kurallar gibi web uygulama güvenlik duvarı (WAF) kuralları geçici bir çözüm olarak yardımcı olur; ancak yalnızca o servis üzerinden geçen trafiği korur ve saldırganlar payload'larını şimdiden uyarlıyor.

PHP2Shell Laravel Uygulamaları İçin Ne Anlama Geliyor?

Laravel'in kendisi PHP2Shell için bir kod değişikliğine ihtiyaç duymuyor; ancak her Laravel uygulaması altındaki PHP sürümüne bağlı. Laravel ekipleri için pratik kontrol listesi şöyle:

• Laravel uygulamanızı çalıştıran her sunucunun, kuyruk worker'ının ve container'ın PHP sürümünü belirleyin ve yalnızca web sunucularını değil, hepsini yamalayın.
• Yönetilen bir platform üzerinden dağıtım yapıyorsanız sağlayıcınızdan PHP çalışma ortamlarının güncellendiğini teyit edin ve gerekirse yeniden dağıtın.
• Yamadan sonra kuyruk worker'larını ve Horizon veya Octane gibi uzun süre çalışan süreçleri yeniden başlatın ki yeni PHP programını yüklesinler.
• PHP2Shell belleği açığa çıkarabildiği için, internete açık ve yamasız kalmış bir sunucu varsa hassas gizli bilgileri değiştirmeyi düşünün: APP_KEY, veritabanı şifreleri ve Stripe, Xero veya QuickBooks gibi servislerin API anahtarları. APP_KEY şifrelenmiş verileri ve oturumları etkilediği için değiştirilmesi dikkat gerektirir.

Sunucunuzun Hedef Alınmış Olabileceğine Dair İşaretler

Araştırmacılar istismar denemelerine işaret edebilecek bazı örüntüler paylaştı. Hiçbiri tek başına bir sızmayı kanıtlamaz ve temiz bir log da sunucunun güvende olduğunu kanıtlamaz; yine de gözden geçirilmeye değer:

• Ardından bellek sınırı hataları gelen alışılmadık multipart istekler
• Belirgin bir nedeni olmayan, tekrarlayan HTTP 500 yanıtları
• Alışılmadık derecede büyük PHPSESSID cookie'leri
• Açıklanamayan PHP worker çökmeleri veya yeniden başlamaları
• Web sunucusunda beklenmeyen süreçler, dosyalar veya dışarıya giden ağ bağlantıları

Bir sızma belirtisi bulursanız etkilenen sunucuyu izole edin, inceleme için logları saklayın, kimlik bilgilerini değiştirin ve ele geçirilmiş olabilecek bir sistemi temizlemeye çalışmak yerine bilinen temiz bir durumdan yeniden kurun.

PHP2Shell Zaman Çizelgesi

• 17 Ekim 2026: Amazon, honeypot ağında ilk istismar denemesini gözlemledi.
• 20 Ekim 2026: CVE numaraları kamuoyuna sızdı. PHP, bir gün öne çekilen acil bir sürüm duyurdu.
• 21 Ekim 2026: PHP, 14:00 UTC'de 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerini yayınladı. Kısa süre sonra watchTowr her iki CVE'ye yönelik istismar denemeleri bildirdi; CISA acil yama çağrısı yaptı.

Sıkça Sorulan Sorular

PHP2Shell nedir?

PHP2Shell, PHP motorundaki iki kritik açığa, CVE-2026-109618 ve CVE-2026-109619'a verilen addır. Kimlik doğrulaması yapılmamış bir saldırganın web sunucusunda kod çalıştırmasına ve sunucu belleğinden veri okumasına izin verebilirler. Her ikisi de CVSS v4 ölçeğinde 9.2 puan almıştır.

Web sitem PHP2Shell'den etkileniyor mu?

Web siteniz PHP ile çalışıyorsa ve sunucu PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35'e veya yamalı bir dağıtım paketine güncellenmemişse açık kabul edilmelidir. Bu durum PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed için geçerlidir.

Laravel PHP2Shell'den etkileniyor mu?

Laravel uygulamaları, üzerinde çalıştıkları PHP sürümü aracılığıyla etkileniyor. Açık PHP'nin kendisinde olduğu için Laravel veya Composer paketlerini güncellemek sorunu çözmez. Uygulamanızı çalıştıran her sunucuda ve container'da PHP'yi güncellemeniz gerekir.

WordPress PHP2Shell'den etkileniyor mu?

Evet. Araştırmacılar WordPress'in yanı sıra Drupal, Joomla ve Magento'nun belirli sürümlerine karşı girişsiz uzaktan kod çalıştırmayı doğruladı. Çözüm sunucudaki PHP sürümünü güncellemektir; yalnızca WordPress'i güncellemek yeterli değildir.

PHP2Shell aktif olarak istismar ediliyor mu?

İstismar denemeleri 17 Ekim 2026'dan beri gözlemleniyor ve yamaların yayınlandığı 21 Ekim'den sonra arttı. 22 Ekim itibarıyla kamuoyuna doğrulanmış başarılı bir sızma yoktu; ancak güvenlik firmaları denemeleri yaygın olarak nitelendiriyor.

PHP 7.4 veya 8.1 kullanıyorum. Ne yapmalıyım?

Bu sürümler için resmi bir yamalı sürüm yok. PHP projesi PHP 7.4, 8.0 ve 8.1 için sınırlı kaynak kod yamaları yayınladı; bazı dağıtımlar ve uzun süreli destek sağlayıcıları da yamalı paketler sunuyor. En güvenli çözüm, yükseltme tamamlanana kadar geçici önlemleri uygulayarak desteklenen bir PHP sürümüne geçmektir.

Cloudflare veya bir WAF beni PHP2Shell'den korur mu?

Bir web uygulama güvenlik duvarı bilinen saldırı örüntülerini engelleyebilir ve faydalı bir ek katmandır, ancak eksiksiz bir çözüm değildir. Yalnızca kendisinden geçen trafiği korur ve saldırganlar bazı kuralları atlatmak için payload'larını şimdiden değiştirdi. PHP'yi yamalamak hâlâ şart.

Yamadan sonra şifreleri ve API anahtarlarını değiştirmem gerekir mi?

Bir sunucu saldırılar aktifken internete açık ve yamasız kaldıysa, PHP2Shell bellekteki verileri açığa çıkarabildiği için hassas kimlik bilgilerini değiştirmek mantıklı bir önlemdir. Öncelik veritabanı şifrelerine, uygulama anahtarlarına ve ödeme ile muhasebe entegrasyonlarının API anahtarlarına verilmelidir.

PHP2Shell yamasını uygulamak ne kadar sürer?

Dağıtım paketlerini kullanan tek bir sunucuda PHP'yi güncellemek ve servisleri yeniden başlatmak genellikle dakikalar sürer. Çok sayıda sunucu, container ve eski PHP sürümü bulunan büyük ortamlar dikkatli bir envanter ve test gerektirir; bu yüzden hemen başlamak önemlidir.

Sonuç

PHP2Shell, son yılların en ciddi PHP açıklarından biri: motorun kendisini etkiliyor, kimlik doğrulama gerektirmiyor, bellekteki gizli bilgileri açığa çıkarabiliyor ve şimdiden hedef alınıyor. Yapılması gereken net ama acil. PHP çalıştıran her sunucuyu ve container'ı bulun; 8.5.12, 8.4.27, 8.3.36, 8.2.35'e veya yamalı bir dağıtım paketine güncelleyin; tüm PHP süreçlerini yeniden başlatın ve yamanın geciktiği her yerde geçici önlemleri uygulayın. Laravel veya başka PHP uygulamaları çalıştırıyorsanız ve sunucularınızı kontrol etmek, yamayı güvenle uygulamak ya da desteği sona ermiş bir PHP sürümünden yükseltmek için yardıma ihtiyacınız varsa, ekibimiz sistemlerinizi hızla güvence altına almanıza yardımcı olabilir.