Sık sorulan sorular
Hangi PHP sürümleri etkileniyor?
Desteklenen dallarda 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 öncesindeki tüm sürümler. PHP 8.1 ve öncesinin desteği bitmiştir ve PHP projesinden sürüm almaz; sağlayıcınız backport edilmiş bir düzeltmeyi teyit etmedikçe bunları etkilenmiş kabul edin.
Sitem PHP sürümü göstermiyor. Güvende miyim?
Şart değil. Sürümü gizlemek (expose_php = Off) iyi bir uygulamadır ama hiçbir şeyi yamalamaz. Sunucuda php -v ile kontrol edin ya da sağlayıcınıza sorun.
Araç eski bir sürüm gösteriyor ama hosting firmam yamalı olduğunu söylüyor. Hangisi doğru?
Muhtemelen ikisi de. Debian, Ubuntu ve RHEL gibi Linux dağıtımları güvenlik düzeltmelerini çoğu zaman sürüm numarasını değiştirmeden backport eder. Hosting firmanıza hangi paket derlemesinin kurulu olduğunu ve changelog’unda CVE-2026-109618 ile CVE-2026-109619’un geçip geçmediğini sorun.
WordPress, Laravel veya kullandığım CMS etkileniyor mu?
Açıklar PHP’nin kendisinde olduğu için etkilenen bir PHP üzerinde çalışan her uygulama risk altındadır. Araştırmacılar WordPress, Drupal ve Joomla’ya karşı kimlik doğrulaması gerektirmeyen saldırılar gösterdi, ancak bunlar yalnızca örnekti — sade bir “Hello World” sayfası bile yeterlidir. WordPress’i veya eklentileri güncellemek sorunu çözmez; PHP güncellenmelidir.
Hiç kod çalıştırılmadan da veri sızabilir mi?
Evet. CVE-2026-109619, saldırgan kod çalıştırmadan PHP süreç belleğini — başka isteklere ait parolaları, oturum token’larını, API anahtarlarını ve sertifikaları — açığa çıkarabilir. Bu tür sızıntılar geride dosya bırakmaz ve tespit edilmesi zordur; bu yüzden etkilenen bir sürümü internette çalıştırmış her sitenin gizli bilgilerini değiştirin.
session.upload_progress’i kapatmak sorunu çözer mi?
Hayır. php.net session.upload_progress.enabled=0 ayarını CVE-2026-109619’un doğrulanmış bazı yolları için kısmi bir önlem olarak listeliyor. Tüm varyantları kapsamaz ve CVE-2026-109618 için hiçbir etkisi yoktur.
Bir web uygulama güvenlik duvarı yeterli mi?
Bir WAF veya istek sınırları güncelleyene kadar riski azaltabilir, ancak sorunlar PHP’nin istekleri ve belleği nasıl işlediğinde. Güncelleme yine de gereklidir.
Güncellemeden sonra bir şeyi yeniden başlatmam gerekiyor mu?
Evet. PHP-FPM, Apache, LiteSpeed ve uzun süre çalışan işçi süreçler yeniden başlatılana kadar eski kodu çalıştırmaya devam eder. Container’lar yeni imajdan yeniden oluşturulmalıdır.
Bu araç tam olarak ne yapıyor?
Girdiğiniz adrese tek bir HEAD isteği (HEAD kabul edilmezse GET) gönderir, en fazla üç yönlendirmeyi izler ve X-Powered-By ile Server gibi yanıt başlıklarını okur. Asla istismar yükü, büyük istek veya dosya yüklemesi göndermez ve başka yolları taramaz.
Herhangi bir web sitesini kontrol etmek yasal mı?
Yalnızca sahibi olduğunuz veya değerlendirme yetkiniz olan siteleri kontrol edin. İstek normal bir ziyaretle aynıdır, ancak sorumlu kullanım sizin sorumluluğunuzdadır. Kontrolleri ağ başına ve site başına sınırlıyoruz.
PHP 8.5.12 tamamen düzeltildi mi?
22 Ekim 2026’da 8.5.12’de bir çökme olduğuna dair raporlar dolaştı, ancak uzaktan istismar edilebilir bir açık olarak doğrulanmadı. php.net’i takip ediyoruz; yeni bir sürüm çıkarsa bu site güncellenecek ve “son doğrulama” tarihi değişecek.
Resmî ayrıntıları nerede okuyabilirim?
php.net üzerinde ve PHP projesinin GitHub duyurularında: GHSA-w8hw-w9fx-j79w ve GHSA-6wmf-4rv5-p3rp. Araştırma ekibi (Wiz Research, OpenAI Codex Security ve Calif) bulgularını php2shell.com adresinde yayımladı.
Açıkları kim buldu?
Wiz Research, OpenAI Codex Security ve Calif’ten araştırmacılar; düzeltmeleri hazırlayan PHP güvenlik ekibiyle koordineli bildirim (coordinated disclosure) yoluyla. Sürümle ilgili ayrıntılar için The PHP Foundation’ın yazısına bakın.