PHP2Shell: Kritik PHP açıkları – web siteniz güncellendi mi?

01PHP2Shell nedir?

PHP, örneğin WordPress ve Joomla için web sitesi kodunu sunucuda çalıştırır. PHP2Shell raporlarına katkıda bulunanlar arasında Wiz, OpenAI ve Calif de yer alıyor. Açıkların kimlikleri CVE-2026-109618 ve CVE-2026-109619. PHP güvenlik duyuruları, her ikisini de CVSS v4.0’a göre 10 üzerinden 9,2 puanla kritik olarak değerlendiriyor. Bu puan, sitenizin ele geçirilme olasılığını değil, açığın ciddiyetini gösterir.

Hatalar, bellek yönetimi ve yarıda kesilen isteklerle ilgili: PHP, tam olarak hazırlanmamış verileri kullanmaya devam edebilir veya serbest bırakılmış belleğe erişebilir. Özel olarak hazırlanmış istekler bu nedenle kod çalıştırılmasına, veri sızıntısına ya da çökmelere yol açabilir. Güncel eklentiler ve güçlü parolalar önemini korur, ancak PHP’nin kendi içindeki bu hataları gidermez.

PHP; PHP-FPM, mod_php kullanan Apache, php-cgi, FrankenPHP ve LiteSpeed’i kontrol edilmesi gereken çalışma biçimleri olarak sıralıyor. mod_php’de web sitesi kodu çalıştırılmadan önce saldırı yapılabildiği gösterildi. FPM için PHP Foundation, uygulama içindeki yollar üzerinden kod çalıştırılabildiğini bildiriyor; OOM duyurusunda buna yönelik eksiksiz bir exploit henüz belgelenmiş değil. İkinci hata için belirli uygulama koşullarında FPM üzerinden bir saldırı yolu doğrulandı. Bu nedenle FPM kullanmak tek başına güvende olduğunuz anlamına gelmez.

Wiz’e göre etkilenen sürümler PHP 5.4’e kadar uzanıyor: her birinde en az bir açık geçerli. Her saldırı her yapılandırmada çalışmaz. Belirleyici olan, fiilen kullanılan PHP çalışma ortamının düzeltilmesidir.

02Risk gerçekte ne kadar ciddi?

Başarılı bir saldırı, PHP işçi sürecinin yetkileriyle kod çalıştırabilir. Hangi dosya veya veri tabanlarına erişilebildiği bu yetkilere bağlıdır; sunucu üzerinde tam yönetici yetkisi otomatik olarak elde edilmez. Wiz ayrıca parolalar, token’lar ve API anahtarları gibi hassas süreç verilerinin okunabildiğini gösterdi. Örneğin giriş bilgileri ve müşteri verileri bu şekilde tehlikeye girebilir.

Cloudflare, açıkların zamanından önce duyulmasıyla bağlantılı saldırı trafiği ve değişen saldırı kalıpları bildiriyor. watchTowr, açıkları kullanmaya yönelik aktif girişimler olduğunu belirtiyor. CERT-EU derhâl güncelleme yapılmasını, bu mümkün değilse herkese açık uygulamaların izole edilmesinin değerlendirilmesini öneriyor. Hollanda NCSC de benzer öneriler yayımladı. BSI uyarıda bulundu; CERT-Bund’da WID-SEC-2026-4055 bildiriminin varlığı doğrulanmış durumda.

Saldırı girişimleri, sistemlerin başarıyla ele geçirildiğini henüz kanıtlamaz. Kaynaklarda ele geçirilmiş sistemlerin güvenilir bir toplam sayısı bulunmuyor. Bildirilen girişimler güncellemeyi acil hâle getiriyor; ancak sitenize ne zaman saldırılacağını bunlardan çıkarmak mümkün değil.

03Hangi PHP sürümleri bu açıkları gideriyor?

Değiştirilmemiş PHP dağıtımlarında her sürüm dalı için aşağıdaki asgari sürümler geçerlidir. Sağlayıcılar düzeltmeleri eski paketlere aktarabilir: bu tür backport’lar için üretici kanıtı gerekir. Bu bilgiler, sitenizin genel güvenliğine değil, söz konusu iki açığa ilişkindir.

• PHP 8.5: 8.5.12 ve sonrası.
• PHP 8.4: 8.4.27 ve sonrası.
• PHP 8.3: 8.3.36 ve sonrası.
• PHP 8.2: 8.2.35 ve sonrası. Düzenli güvenlik desteği 31 Aralık 2026’da sona eriyor; desteklenen bir sürüm dalına geçişi planlayın.
• PHP 8.1, 8.0 ve 7.4 artık PHP projesinden düzenli güncelleme almıyor. Bunlar için istisnai olarak kaynak kodu yamaları ve sağlayıcı paketleri mevcut. Plesk, Linux için 8.1.34, 8.0.30 ve 7.4.33 sürümlerinin 21 Ekim tarihli düzeltilmiş derlemelerini belirtiyor. Görünen PHP sürümü aynı kalabilir. cPanel ve Ubuntu’da tam paket kimlikleri esas alınmalıdır.
• Daha eski sürüm dalları için de bazı sağlayıcı backport’ları var: Hetzner, kendi web barındırma hizmeti ve yönetilen sunucuları için PHP 5.6 ve 7.3’ün düzeltildiğini bildiriyor. Bu, tüm kurulumlar için geçerli değil. Düzeltme teyit edilmemişse güncelleme, sürüm değişikliği veya geçici erişim engeli konusunu netleştirmeniz gerekir.

04Web sitemin etkilenip etkilenmediğini nasıl kontrol ederim?

Paylaşımlı barındırmada birden fazla müşteri sunucu altyapısını paylaşır; PHP paketlerini barındırma sağlayıcısı yönetir. Çoğu zaman sürüm dalını seçebilirsiniz, ancak güvenlik güncellemesini kendiniz kuramazsınız. Her alan adı, alt alan adı ve ek PHP uygulaması için durumu teyit ettirin. Bir ajansın hazırladığı site de başka bir sağlayıcıda barındırılıyor olabilir.

• WordPress: Araçlar → Site sağlığı → Bilgi → Sunucu bölümünde PHP sürümü gösterilir. Yukarıda belirtilenden daha düşük bir sürüm numarası da backport sayesinde düzeltilmiş olabilir. Bunun için paket kimliğini ve ilgili güvenlik duyurusunu isteyin.
• Plesk: Alan Adları → alan adınız → PHP Ayarları → “phpinfo() sayfasını görüntüle”. Sürümü ve “Build Date” bilgisini, ilgili pakete ait Plesk duyurusuyla karşılaştırın. Herhangi bir yeni derleme tarihi, düzeltmenin bulunduğunu kanıtlamaz. Erişiminiz yoksa barındırma sağlayıcınıza sorun.
• cPanel: Software → MultiPHP Manager, sağlayıcınız bu işlevi açmışsa her alan adının sürümünü gösterir. İlgili tüm alan adlarını kontrol edin; farklı PHP sürümleri kullanıyor olabilirler.
• Hostinger: hPanel → Websites → Dashboard → PHP Info. Hostinger, 21 Ekim 2026 veya sonrasına ait bir derleme tarihini yalnızca kendi güncellenmiş paketleri için yeterli kabul ediyor. Yönetilen barındırma hizmetindeki işlemlerin tamamlandığına ilişkin duyuru, 22 Ekim 06:44 UTC, yani Orta Avrupa yaz saatiyle (MESZ) 08:44 tarihli. VPS müşterileri PHP’yi kendileri yönetir.
• Hetzner, web barındırma hizmeti ve yönetilen sunucular için PHP 7.4 ile 8.0–8.5 güncellemelerinin 21 Ekim saat 19:50 MESZ’de, 5.6 ve 7.3 güncellemelerinin ise 22 Ekim saat 06:32 MESZ’de tamamlandığını bildiriyor. Sağlayıcının bu açıklamaları, müşterilerin kendilerinin yönettiği fiziksel veya bulut sunucularının durumunu otomatik olarak teyit etmez.
• Diğer sağlayıcılar: Alan adınız için teyit isteyin. Kamuya açık bir duyuru bulunamaması, yamanın eksik olduğunu kanıtlamaz. SSH erişiminiz varsa `php -v` komut satırı sürümünü gösterir; web sitesi farklı bir PHP süreci kullanıyor olabilir.

05Barındırma sağlayıcıma ne yazmalıyım?

Barındırma desteğine veya sitenizin bakımını yapan kişiye yazın. Site başka bir sağlayıcıda barındırılıyorsa ajans, sunucu işletmecisini de sürece dâhil etmelidir. Şu mesajı kopyalayabilirsiniz:

“Alan adlarımın [Domains] kullandığı tüm PHP sürümleri için CVE-2026-109618 ve CVE-2026-109619 giderildi mi? Lütfen fiilen kullanılan web PHP sürümlerini, tam paket/derleme kimliklerini, varsa backport kanıtını, ayrıca etkinleştirme zamanını ve tüm PHP işçi süreçlerinin yeniden başlatıldığını teyit edin. Yönetim arayüzü ve PHP tabanlı web posta da güncellendi mi? Açık kalan bir işlem varsa düzeltme ne zaman yapılacak ve o zamana kadar herkese açık erişim PHP dışında nasıl engellenecek?”

İlgili pakete ait kanıt isteyin. Güncellemeden sonra çalışan PHP süreçleri, düzeltilmiş kodu kullanabilmeleri için yeniden başlatılmalıdır. Genel bir durum duyurusu bu teyidin yerini tutmaz.

Web sitesinin PHP’si ile panelin dâhilî PHP’si ayrı ayrı kontrol edilmelidir. Plesk için üretici, sw-engine düzeltmesi olarak 18.0.81 Update 4 veya 18.0.80 Update 11’i belirtiyor. cPanel/WHM için 11.110.0.153, 11.134.0.66, 11.136.0.50 ve 11.138.0.18 sıralanıyor. Ayrıca web sitelerinin PHP paketlerinin de güncellenmesi gerekiyor.

E-postayı unutmayın: cPanel’in dâhilî PHP’si, Roundcube web posta için de kullanılır. Web sitesinin güncellenmiş olması, web posta erişiminin düzeltildiğini teyit etmez. Diğer panellerde de web postanın çalışma ortamını ayrıca kontrol ettirin. PHP açıkları, ne her posta kutusunun ele geçirildiğini ne de posta hizmetlerinizin güvenli olduğunu kanıtlar.

Güncellemeden sonra: PHP’nin durumunu ve yeniden başlatmayı teyit ettirin; oturum açma, iletişim formu ve sipariş gibi önemli işlemleri kontrol edin. Dosya ve veri tabanı yedeklerinin mevcut olup olmadığını ve bunlardan geri yükleme yapılıp yapılamadığını netleştirin. Yedek, yamanın yerini tutmaz. Şüpheli değişiklikler varsa bakım sorumlusu temizlikten önce dosyaları ve günlükleri korumaya almalı, olayı incelemeli ve temizlikten sonra etkilenen giriş bilgilerini yenilemelidir. Yama tek başına daha önce yerleştirilmiş zararlı kodu kaldırmaz.

06Güncelleme hemen yapılamıyorsa ne yapmalısınız?

Geçici izolasyonu işletmeciyle görüşün. CERT-EU, düzeltme uygulanıp doğrulanana kadar gerektiğinde herkese açık uygulamaların erişime kapatılmasını öneriyor. Web sunucusu veya güvenlik duvarındaki engel, PHP’den önce devreye girmelidir; WordPress bakım sayfası bunun için yeterli değildir. Erişimi yalnızca açıkça izin verilen IP adresleriyle sınırlandırmak erişimi daraltabilir, ancak açıkları gidermez.

PHP, yöneticiler için sınırlı geçici önlemler belirtiyor: `memory_limit=-1` ayarlayın ve mümkünse değiştirilmesini engelleyin; gerçek bellek yetersizliği tehlikeli olmaya devam eder. Dosya yüklemesi gerekmiyorsa `post_max_size=8M`, gerekiyorsa `32M` ayarlayın ve `upload_max_filesize` değerini bunun altında tutun. Ayrıca kullanılabilir bir Content-Length olmadığında da web sunucusu veya proxy üzerinde istek boyutunu ve karmaşıklığını sınırlayın. Konteyner/cgroup sınırları kullanılabilirliğin korunmasına yardımcı olabilir; `RLIMIT_AS` ve `RLIMIT_DATA` bunların yerini tutmaz. Bu, müşteri panelinde kontrol etmeden değişiklik yapmanız için bir talimat değildir.

Diğer saldırı yolları için: `session.upload_progress.enabled=0` ayarını istek okunmadan önce, örneğin php.ini veya FPM havuzunda yapılandırın; `ini_set()` ve FPM `.user.ini` yeterli değildir. PHP 8.5’te ayrıca `fatal_error_backtraces=0` ayarlayın; ardından tüm işçi süreçlerini yeniden başlatın. Hatalı ayarları, tetiklenebilen ölümcül hataları ve zaman aşımlarını bakım sorumlusu kontrol etmelidir. Hata mesajlarını gizlemek yardımcı olmaz. Bu önlemler tüm saldırı yollarını kapatmaz.

Cloudflare, 21 Ekim 03:02 UTC’den, yani 05:02 MESZ’den itibaren, sitenin WAF korumasını kullanması koşuluyla Free planında da ek kurallar sunuyor. Ücretli planlarda Cloudflare Managed Ruleset içindeki “Generic Rules – Anomalous Execution” ayarını Block modunda kontrol ettirin. Free Ruleset’te kurallar otomatik olarak etkin. PHP güncellemesi yine de gerekli.

07Müşterilerimiz için neler yaptık?

22 Ekim’deki kontrolümüzde barındırma sunucularımızda, Plesk güvenlik duyurusuyla eşleşen 21 Ekim tarihli derlemelerle Plesk-PHP 8.0 ile 8.5 arasındaki sürümlerin kurulu olduğunu gördük. 22 Ekim sabahına kadar tüm sunucularda PHP-FPM süreçleri yeniden başlatıldı. Yönetim arayüzünü ayrıca kontrol ediyoruz.

Bizim barındırma hizmetimizi kullanan siteler için kendiniz bir şey kurmanız gerekmiyor. Bu, oluşturduğumuz veya bakımını yaptığımız siteler olsa bile, başka sağlayıcılarda barındırılan siteler için kesinlikle geçerli değil: orada yama durumunu ilgili işletmeci teyit etmelidir. Sitenizdeki olağan dışı durumları bize bildirmeye lütfen devam edin.

08PHP2Shell hakkında sık sorulan sorular