PHP2Shell: Kritik PHP Açığından Korunmak İçin Yapılacaklar

Ne oldu: iki kritik açık, tek bir istekle

PHP projesi 21 Ekim 2026’da olağan takvimin dışında bir güvenlik sürümü yayımladı: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Bu sürümler, güvenlik araştırmacılarının PHP2Shell adını verdiği iki açığı kapatıyor: CVE-2026-109618 ve CVE-2026-109619.

İki açık da kritik olarak sınıflandırıldı ve CVSS 4.0 ölçeğinde 9.2 puan aldı. Etkisi aynı: kimlik doğrulaması gerekmeden, uzaktan, sunucuda kod çalıştırmak. Google’ın güvenlik ekibine göre bunlara bazı durumlarda sunucu belleğindeki bilgilerin sızması da ekleniyor ve etkilenen aralık PHP 5.4’ten 8.5.11’e kadar uzanıyor.

Resmî duyuruya göre web isteği karşılayan tüm PHP kurulumları risk altında: PHP-FPM, Apache ile mod_php, php-cgi, FrankenPHP ve LiteSpeed. En yüksek risk mod_php kurulumlarında; burada saldırının, uygulama kodu daha hiç çalışmadan tek bir istekle tetiklenebildiği gösterildi.

Neden bu kadar ciddi

Alışık olduğumuz PHP açıkları çoğunlukla bir eklentide, bir temada ya da uygulama kodunda olur. PHP2Shell ise yorumlayıcının kendisinde. Bu yüzden uygulamanızın ne kadar özenli yazıldığı, hangi çatıyı kullandığı ya da giriş ekranınızın ne kadar güçlü olduğu sonucu değiştirmiyor: WordPress, Laravel, Joomla ya da tamamen özel yazılmış bir uygulama aynı ölçüde etkileniyor.

Açıkların teknik özü yüksek seviyede şöyle: birinde, bellek yetersizliği anında yarım kalmış istek verisi temizlik sırasında geçerliymiş gibi işleniyor; diğerinde, bir isteğe ait iç durum, belleği serbest bırakıldıktan sonra aynı işçi sürecindeki bir sonraki isteğe taşınabiliyor. Ayrıntı vermiyoruz; korunmak için bundan fazlasını bilmeniz gerekmiyor.

Zaman baskısı gerçek. Amazon’un tehdit istihbaratı ekibi, açıklar kamuya duyurulmadan dört gün önce, 17 Ekim’de tuzak sunucularında bir istismar denemesi kaydettiğini bildirdi. Bazı kurumlar ilk gün gerçek saldırı görmediğini açıklarken, birkaç güvenlik firması 21 ve 22 Ekim’de saldırı girişimleri gözlediğini duyurdu. İngiltere’nin ulusal siber güvenlik merkezi, hemen güncellenemeyen sistemlerin geçici olarak kapatılmasını değerlendirmeyi öneriyor.

Önce envanter: PHP nerede çalışıyor?

"Bizde PHP yok" cevabı çoğu zaman eksiktir. Kendi ürünlerimiz .NET üzerinde çalışıyor; yine de bu yazıyı hazırlarken sunucumuzdaki tüm konteynerleri tek tek taradık. Ana uygulamalarımızın hiçbiri PHP kullanmıyordu ama hazır imajla kurulmuş yardımcı bir web arayüzünün içinde etkilenen bir PHP sürümü çıktı. Önce konteynerde ele geçirilme belirtisi aradık, ardından aynı saat içinde yamalı imaja geçtik.

PHP’nin en sık saklandığı yerler şunlar: hazır Docker imajları, webmail ve veritabanı yönetim arayüzleri, izleme panelleri, unutulmuş kampanya ve eski kurumsal siteler, paylaşımlı barındırma hesapları. Ağ cihazları da listede: Palo Alto Networks, güvenlik duvarı işletim sistemi PAN-OS’un tüm sürümlerinin etkilendiğini bildirdi.

Sürüme bakmak için sunucuda php -v komutunu, konteynerlerde aynı komutu konteynerin içinde çalıştırın. Dikkat: komut satırındaki PHP ile web isteklerini karşılayan PHP-FPM aynı kurulum olmayabilir; ikisine ayrı ayrı bakın. Herkese açık bir phpinfo sayfasıyla kontrol etmeyin, varsa o sayfayı kaldırın.

Asıl çözüm: güncellemek, sonra yeniden başlatmak

PHP ekibinin cümlesi net: tam çözüm yalnız güncellemektir. Hedef sürümler 8.5 dalında 8.5.12, 8.4 dalında 8.4.27, 8.3 dalında 8.3.36, 8.2 dalında 8.2.35 ve üzeri.

Linux dağıtımları düzeltmeleri duyurudan önce aldı; sunucunuzu dağıtımın paket yöneticisiyle güncelleyin. Burada sık yapılan bir yanılgı var: dağıtım paketleri düzeltmeyi eski sürüm numarasının üzerine taşır, bu yüzden numara değişmemiş görünebilir. Kararı sürüm numarasına değil, paketin değişiklik notunda ya da dağıtımın güvenlik duyurusunda bu iki CVE numarasının geçmesine bakarak verin.

Docker kullanıyorsanız konteyneri yeniden başlatmak yetmez. İmajı yamalı temel imajla yeniden derleyin ya da yamalı imajı çekin, konteyneri yeni imajla yeniden oluşturun ve PHP sürümünü konteynerin içinde doğrulayın. Eski imajı geri dönüş için etiketleyip saklamak, bir sorun çıkarsa dakikalar kazandırır.

Güncellemeden sonra PHP çalıştıran her süreci yeniden başlatın: Apache, tüm PHP-FPM havuzları ve uzun süre çalışan işçiler. Kuyruk işçileri, Laravel Octane, RoadRunner ya da FrankenPHP’nin işçi modu gibi yapılar eski kodu bellekte tutmaya devam eder; diskteki dosyanın yenilenmesi onları korumaz.

Paylaşımlı barındırmadaysanız güncellemeyi sağlayıcınız yapar. Panelinizdeki PHP sürüm seçicisinde desteklenen bir sürümü seçin, sağlayıcınızdan yamanın uygulandığına dair yazılı teyit isteyin.

Hemen güncelleyemiyorsanız: geçici önlemler

Önce beklentiyi doğru kuralım: resmî duyuruya göre hiçbir yapılandırma değişikliği açıkları tamamen kapatmıyor. Aşağıdakiler belirli saldırı yollarını daraltır, güncellemeyi yapana kadar zaman kazandırır.

Sitenizin önünde bir web uygulaması güvenlik duvarı varsa kuralların güncel olduğundan emin olun. Cloudflare, bilinen saldırı yollarına karşı kuralları ücretsiz plan dahil tüm müşterileri için devreye aldığını duyurdu; Google da kendi bulut güvenlik duvarı için benzer öneriler yayımladı.

İstek gövdesinin boyutunu web sunucusu ya da vekil sunucu düzeyinde sınırlayın. PHP tarafında post_max_size değerini, dosya yüklemesi olmayan uygulamalarda 8M, yükleme olanlarda 32M civarına çekin ve upload_max_filesize değerini bunun altında tutun.

İkinci açık için session.upload_progress.enabled ayarını kapatın ve tüm işçileri yeniden başlatın. Bu ayar php.ini, FPM havuzu ya da sunucu yapılandırmasında yapılmalı; uygulama içinden ini_set ile ya da .user.ini dosyasıyla yapılan değişiklik işe yaramaz. PHP 8.5 kullanıyorsanız fatal_error_backtraces ayarını da kapatın.

Resmî duyuru, bellek yetersizliği yolunu daraltmak için bellek sınırının PHP’nin içinden alınıp konteyner ya da cgroup düzeyine taşınmasını öneriyor: PHP’de memory_limit sınırsız yapılır ve uygulamanın değiştiremeyeceği biçimde sabitlenir, asıl sınırı yalnız ilgili işçiyi sonlandıran bir konteyner politikası koyar. Bu ayarı konteyner sınırı olmadan tek başına uygulamayın; sunucunun tüm belleğini bir sürece açmış olursunuz. Duyuru ayrıca işletim sistemi düzeyindeki RLIMIT_AS ve RLIMIT_DATA sınırlarının bu amaçla kullanılmamasını özellikle belirtiyor.

Hata günlüğünü gizlemek bir önlem değildir. display_errors ya da error_reporting ile uyarıları susturmak işe yaramaz; istek başında uyarı üreten geçersiz veya eskimiş ayarları ise kaldırmanız gerekir.

Hiçbiri mümkün değilse erişimi daraltın: yönetim arayüzlerini IP kısıtına ya da VPN arkasına alın, kritik olmayan sistemleri güncellenene kadar kapatın.

Ele geçirilmiş olabilir misiniz? Kontrol listesi

İstismar denemeleri duyurudan önce başladığı için yalnız güncellemek yetmez; güncellemeden önceki günlerde içeri girilmiş olabilir. Konteyner kullanıyorsanız kontrolü yeniden oluşturmadan önce yapın: yeni konteyner, eskisindeki izleri de siler.

Web kök dizininde ve yükleme klasörlerinde son günlerde eklenmiş ya da değişmiş dosyalara bakın; özellikle yükleme klasöründe bir PHP dosyası hiç olmaması gereken bir şeydir. Geçici dizinleri, zamanlanmış görevleri ve yetkili SSH anahtarlarını kontrol edin.

Web sunucusu kullanıcısıyla çalışan beklenmedik süreçlere ve sunucudan dışarıya giden alışılmadık bağlantılara bakın. WordPress gibi sistemlerde yeni eklenmiş yönetici hesaplarını listeleyin.

Günlüklerde PHP işçilerinin çökmesi, bellek hataları ve olağandışı büyüklükte istek gövdeleri dikkat çekici işaretlerdir. Güvenlik firması Searchlight Cyber, bir sunucunun bu açıklara açık olup olmadığını test eden açık kaynak bir tarayıcı yayımladı; bu tür araçları yalnız kendi sistemlerinizde kullanın.

Bir iz bulursanız dosyayı silip geçmeyin. Sunucuyu ağdan ayırın, kanıtları saklayın, veritabanı şifreleri, API anahtarları ve e-posta hesapları dahil tüm gizli bilgileri yenileyin ve sistemi temiz bir yedekten yeniden kurun.

Kalıcı sertleştirme: bir sonraki açığa hazırlık

PHP2Shell yamalandı ama yorumlayıcı düzeyinde bir açık yine çıkacak. Asıl soru, o gün ne kadar hasar göreceğiniz. Aşağıdaki önlemler açığı kapatmaz; bir saldırgan kod çalıştırmayı başarsa bile ulaşabileceği alanı daraltır.

Mümkünse mod_php yerine PHP-FPM kullanın ve her uygulamaya kendi kullanıcısıyla çalışan ayrı bir havuz verin. Böylece bir sitedeki sorun, aynı sunucudaki diğer sitelerin dosyalarına uzanmaz. open_basedir ile her havuzun okuyabileceği dizinleri kendi klasörüyle sınırlayın.

Uygulamanız kullanmıyorsa exec, shell_exec, system, passthru, proc_open ve popen gibi işletim sistemine komut gönderen fonksiyonları disable_functions ile kapatın. Bu, yorumlayıcı düzeyindeki bir açığı engellemez ama sık kullanılan sonraki adımları zorlaştırır.

Canlı ortamda expose_php ve display_errors kapalı olsun, sunucuda unutulmuş phpinfo sayfası kalmasın. Yükleme klasörlerinde PHP çalıştırmayı web sunucusu düzeyinde tamamen kapatın.

Web sürecinin yazabildiği dizinleri yükleme ve önbellek klasörleriyle sınırlayın; uygulama kodu web kullanıcısına ait olmasın. Konteynerlerde salt okunur dosya sistemi ve yalnız gereken klasörler için yazılabilir alan bu ilkenin en temiz uygulamasıdır.

Web sunucusunun dışarıya bağlantı kurmasını gerektiği adreslerle sınırlayın. Kod çalıştırmayı başaran bir saldırganın ilk işi genellikle dışarıdan bir araç indirmektir; giden trafiği kısıtlamak bu adımı keser. Daha genel bir başlangıç listesi için sunucu sertleştirme yazımıza bakabilirsiniz.

Haberi zamanında almak ve hızlı uygulamak

Bu açıkta duyurudan istismar denemelerine kadar geçen süre günlerle değil saatlerle ölçüldü. Bu hıza yetişmek bireysel dikkatle değil, süreçle mümkün.

Hangi sunucuda, hangi konteynerde, hangi PHP sürümünün çalıştığını gösteren güncel bir envanter tutun. Envanteri olmayan ekip, kritik bir duyuru geldiğinde ilk saatlerini yamaya değil aramaya harcar.

PHP’nin duyuru listesine ve kullandığınız dağıtımın güvenlik bildirimlerine abone olun. Kritik açıklar için bir hedef süre belirleyin, örneğin kırk sekiz saat, ve bu işin kimin sorumluluğunda olduğunu yazılı hâle getirin.

Konteyner imajlarını sabit bir temel imaja bağlayın ama düzenli olarak yeniden derleyin; imaj tarayıcıları eski bileşenleri sizin yerinize fark eder. Sunucu izleme tarafında PHP işçilerinin çökmesi ve bellek hataları için uyarı tanımlamak, olağandışı bir durumu müşterinizden önce görmenizi sağlar.

Son güvence yine yedektir. Temiz bir noktaya dönebilmek, test edilmiş bir yedekleme stratejisine bağlıdır. Dışarıdan destek alıyorsanız bu adımların bakım anlaşmasında açıkça yazılı olup olmadığını kontrol edin.