PHP2Shell: PHP'deki Kritik Açık WordPress ve Laravel Sitelerini Nasıl Etkiliyor? Hemen Yapmanız Gerekenler

Kısaca: 21 Ekim 2026'da PHP projesi, kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya (RCE) izin verebilen iki kritik açık için acil güvenlik sürümleri yayınladı: CVE-2026-109618 ve CVE-2026-109619. Açıklar “PHP2Shell” adıyla anılıyor. PHP'nin web isteği karşılayan tüm kurulumları (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed) risk altında; yani WordPress, Drupal, Joomla, Magento, Laravel ve özel PHP uygulamaları hangi sürümde olduğuna bağlı olarak etkilenebilir. Düzeltilmiş sürümler: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. PHP ekibine göre tam çözüm güncellemedir; geçici ayarlar bir sunucuyu güvenli yapmaz. Bu yazı 23 Ekim 2026 itibarıyla yayımlanmış kaynaklara dayanır; gelişmeler hızlı olduğu için aşağıdaki resmî kaynakları kontrol edin.

Son güncelleme: 23 Ekim 2026

Ne oldu?

• 21 Ekim 2026: PHP projesi, iki kritik açık için güvenlik duyurusu ve düzeltilmiş sürümleri yayınladı ve tüm kullanıcılardan hemen güncelleme yapmasını istedi (php.net duyurusu).
• Açıkların teknik özeti: PHP, bellek yetersizliği (OOM) gibi ölümcül hatalardan sonra bir isteğin durumunu hatalı temizleyebiliyor. Bu da bozuk bellek durumunun sonraki bir istekte kullanılmasına yol açıyor ve saldırgan için kod çalıştırma kapısı açabiliyor.
• Açık bilgisi resmî duyurudan önce, 20 Ekim'de sızdı; güvenlik firması Patchstack'in aktardığına göre barındırma sağlayıcıları sahada aktif sömürü denemeleri bildirdi. Amazon'un tehdit istihbarat ekibi ise denemelerin 17 Ekim'e kadar uzandığını belirtti (ABC News).
• Güvenlik şirketi Wiz, WordPress, Drupal ve Joomla'nın güncel konteyner imajlarında kimlik doğrulamasız kod çalıştırmayı gösterdiğini yayımladı (Wiz araştırması).
• Bazı kurumlar önlem olarak hizmetlerini geçici kapattı; haberlere göre aralarında Hollanda devlet siteleri, bazı Japon platformlar ve Moodle siteleri vardı. ABD Ulusal Güvenlik Ajansı (NSA) PHP kullanan kurumlara hemen güncelleme yapmalarını ya da yama gelene kadar sistemlerini kapatmalarını önerdi (TechCrunch).

Not: Açığı kimin bulduğu konusunda kaynaklar farklı ekiplere atıf yapıyor (Wiz kendi araştırmasını yayımlarken ABC, ABD'li Calif firmasını anıyor). Ortak nokta, keşifte yapay zekâ modellerinin kullanılmış olması; bunun işletmeler açısından anlamını ayrı bir yazıda ele aldık.

Kimler etkilenir?

PHP'nin kendisinde olduğu için sorun, uygulamanızın kodundan bağımsızdır:

Patchstack'in değerlendirmesine göre en yüksek risk Apache mod_php kurulumlarında; çünkü gösterilen sömürüde yalnızca kimliksiz bir istek yetiyor.

Hangi PHP sürümleri güvenli?

PHP ekibi 7.4, 8.0 ve 8.1 için de asgari kaynak kodu yamaları paylaştı; ancak bunları kendiniz derlemek yerine, mümkünse desteklenen bir sürüme geçmek daha sağlıklıdır.

Bugün yapmanız gereken 7 adım

1. Envanter çıkarın. PHP çalışan her yeri listeleyin: canlı site, test/staging ortamları, Docker konteynerleri, eski paneller, ajansın kurduğu unutulmuş siteler.
2. Sürümü öğrenin. Sunucuda php -v; hosting panelinde PHP sürümü ekranı. Emin değilseniz sağlayıcıya sorun.
3. Güncelleyin. Yukarıdaki düzeltilmiş sürümlere ya da sağlayıcınızın yamalı paketine geçin. Yeni sürüme geçerken önce test ortamında deneyin; ama güncellemeyi günlerce ertelemeyin.
4. PHP 8.1 ve eskisindeyseniz sağlayıcınızdan yazılı olarak yama kapsamını isteyin; yoksa 8.4 veya 8.5'e geçişi planlayın.
5. Paylaşımlı hostingdeyseniz firmanıza “PHP2Shell yamasını uyguladınız mı, hangi sürümdeyiz?” diye yazılı sorun.
6. Hemen güncelleyemiyorsanız ve site yüksek risk taşıyorsa, güncelleme gelene kadar siteyi bakım moduna alın ya da kapatın. PHP projesi, güncellenemeyen durumlar için bazı geçici ayarlar paylaştı (örn. session.upload_progress.enabled = 0 ve belirli bellek/yükleme limiti ayarları) ancak bunların sistemi güvenli hale getirmediğini açıkça belirtiyor. Ayrıntılar için resmî duyuruya bakın. Bellek sınırlaması için RLIMIT_AS/RLIMIT_DATA kullanmayın; duyuruya göre bunlar açığın tetiklenmesine yol açabilir.
7. Resmî olmayan “çözüm” eklentilerinden ve kopyala-yapıştır kod parçalarından uzak durun. Bu tür olaylarda sahte düzeltmeler de dolaşır.

Saldırıya uğradığınızı nasıl anlarsınız?

Wiz ve Patchstack'in önerdiği izleme işaretleri:

• Ardından bellek sınırı hataları veya tekrarlayan HTTP 500 yanıtları gelen olağandışı multipart (dosya yükleme) istekleri
• Anormal derecede büyük veya bozuk biçimli PHPSESSID çerezleri
• Açıklanamayan PHP işçi (worker) süreçlerinin yeniden başlaması

Bu belirtileri görüyorsanız ele geçirilmiş varsayın: sunucunun tuttuğu tüm sırları (veritabanı şifreleri, API anahtarları, .env dosyaları, SMTP ve ödeme sağlayıcı anahtarları) temiz bir makineden yenileyin, günlükleri inceleyin ve gerekirse bir güvenlik uzmanına başvurun. Wiz, açığın kod çalıştırma olmadan bile işlem belleğinden parola, token ve anahtar sızdırabildiğini de gösterdi; bu yüzden yama sonrasında sır yenilemesi düşünülmeye değer.

WAF yeter mi?

Cloudflare ve diğer sağlayıcılar erken kurallar yayınladı; ancak bu kurallar ek koruma, çözüm değil. Patchstack'in ifadesiyle tam düzeltme yalnızca güncellemedir. WAF kuralı, açığın henüz bilinmeyen varyantlarını yakalamayabilir; Wiz de başka varyantların muhtemel olduğunu belirtti.

İşletme sahibi olarak ne sormalısınız?

Yazılım ajansınıza ya da hosting firmanıza şunları yazılı sorun:

1. Hangi sitelerimiz/uygulamalarımız PHP kullanıyor, hangi sürümde?
2. Düzeltilmiş sürüme ne zaman geçilecek / geçildi?
3. Bu olay için izleme ve günlük incelemesi yapıldı mı?
4. Sunucuda tutulan sırlar yenilenecek mi?
5. Bu tür acil yamalar için bakım sözleşmenizde süre taahhüdü var mı? Bakım ve SLA'nın ne olması gerektiğini bakım ve destek rehberimizde, genel güvenlik önlemlerini güvenlik rehberimizde anlattık.

Aktaş Digital olarak ne yapıyoruz?

Güncel olmayan bileşenler, web uygulamalarında en sık karşılaşılan risklerden biridir. Bakım kapsamındaki projelerde bu tür acil duyuruları takip etmek, etkilenen bileşenleri belirlemek ve müşteriye net bir yol haritası sunmak gerekir. Yeni projelerde teknoloji seçimini ve bakım planını baştan birlikte yapıyoruz: bkz. teknoloji yığını seçimi rehberimiz. Mevcut sitenizin bakım ve güvenlik durumunu değerlendirtmek isterseniz teklif formumuzdan ulaşabilir ya da iletişim sayfamızı kullanabilirsiniz; ilgili hizmetlerimiz için web çözümleri sayfasına göz atın.

Sık Sorulan Sorular

Sitem WordPress; ne yapmalıyım?

WordPress'in kendisini güncellemek bu açığı kapatmaz; sorun PHP'dedir. Hosting panelinizden veya sağlayıcınızdan PHP sürümünüzün düzeltilmiş sürümde olduğunu doğrulayın.

Paylaşımlı hostingdeyim, kendim güncelleyemiyorum.

PHP'yi hosting firması yönetiyor olabilir. Firmaya yazılı soru sorun; yamayı ne zaman uygulayacağını öğrenin. Yama gecikiyorsa sitenizi geçici olarak kapatmayı veya yedekten başka bir ortama taşımayı değerlendirin.

Laravel kullanıyoruz; framework'ü güncellemek yeter mi?

Hayır. Açık framework'te değil, PHP çalışma zamanındadır. Sunucudaki/konteynerdeki PHP sürümü güncellenmelidir.

Next.js sitem de etkilenir mi?

Next.js uygulamaları PHP kullanmaz; bu açıktan doğrudan etkilenmez. Ancak aynı sunucuda PHP çalışan başka servisler varsa onlar etkilenebilir. Next.js ve Node.js için bu hafta ayrı güvenlik güncellemeleri çıktı: Next.js ve Node.js yazılarımıza bakın.

Güncelledim; sır yenilemem gerekir mi?

Sistem açık süresince sömürüldüyse sunucudaki sırlar ele geçirilmiş olabilir. İzleme işaretlerini görmediyseniz bile, özellikle yüksek değerli anahtarlar için yenilemeyi değerlendirin.

Bu haber ne kadar güncel?

Konu hızla gelişiyor. Bu yazı 23 Ekim 2026 itibarıyla yayımlanan php.net duyurusuna ve basın/araştırma kaynaklarına dayanır; kararınızı vermeden önce resmî duyuruyu kontrol edin.

Sonuç

PHP2Shell, “siteniz kimsenin ilgisini çekmez” varsayımının geçerli olmadığı bir olay: kimlik doğrulaması gerektirmeyen, PHP çalışan her sistemi etkileyen ve sahada denendiği bildirilen bir açık. Bugün yapabileceğiniz ilk iş: hangi sitelerinizin PHP kullandığını ve hangi sürümde olduğunu öğrenmek, sonra düzeltilmiş sürüme geçişi yazılı olarak talep etmek.