Amazon, yama yayınlanmadan önce PHP2Shell exploit denemeleri tespit etti; yeni kontrol aracı Debian PHP sürümlerini doğruluyor

The Verge'ın aktardığı bir Amazon Threat Intelligence raporuna göre saldırganlar, düzeltmeler yayınlanmadan günler önce PHP2Shell adı verilen iki kritik PHP açığını yoklamak için faaliyete geçmişti; The Verge, bulguların daha önce Wired ve Bleeping Computer tarafından rapor edildiğini belirtiyor. Bu keşif, internet genelindeki web sitelerinin (WordPress ile kurulanlar dahil) 21 Ekim'de güncelleme yapmak için yarıştığı güvenlik krizinin zaman çizelgesini netleştiriyor.

Exploit denemeleri açıklamadan önce başladı

The Verge'ın haberine göre Amazon'un baş bilgi güvenliği sorumlusu CJ Moses, şirketin güvenlik ekibinin 17 Ekim'de bir honeypot (saldırganları cezbetmek için tasarlanmış bir izleme sistemi) aracılığıyla bir PHP2Shell exploit denemesi tespit ettiğini yazıyor. Başka denemeler ise 21 Ekim'de, yamanın çıkışından saatler önce görüldü. Moses, hedeflemenin açık hâlâ embargo altındayken anonimleştirilmiş bir IP adresinden gelmesi nedeniyle tehdit aktörü faaliyetine işaret ettiğini, ancak aktörün açıklamadan önce hatayı nasıl öğrendiğinin "hâlâ belirsiz" olduğunu yazıyor.

CVE-2026-109618 ve CVE-2026-109619 kodlu zafiyetler, web'in büyük bir bölümünü çalıştıran bir programlama dilini etkiliyor. Resmi duyuruyu özetleyen dev.to'daki bir yazı, bunların kimlik doğrulaması gerektirmeyen uzaktan kod çalıştırmaya (remote code execution) olanak tanıdığını belirtiyor. PHP Foundation yönetici direktörü Elizabeth Barron, The Verge'a, vakıflarının bilgisine göre şu ana kadar "başarılı bir uzaktan kod çalıştırma denemesi olmadığını" söylerken, etkilenen sistemleri güncellemenin "zorunlu" olduğunu vurguluyor.

İki yıllık hazırlığın sonunda gelen bir düzeltme

The Verge'ın haberine göre PHP Foundation hatayı ilk kez 2024'te teorize etti. Güvenlik ekibi düzeltmeler hazırladı, ancak bunları yayınlamak geriye dönük uyumluluğu bozma, yeni hizmet reddi (denial-of-service) sorunları açma veya o kadar çok üçüncü taraf eklentide değişiklik gerektirme riski taşıyordu ki koordinasyon uygulanabilir görünmüyordu. Bu haftaki sürüm yaklaştıkça ayrıntılar forumlara ve sosyal medyaya sızdı ve bazı güvenlik firmaları resmi duyurudan önce bilgi yayınladı; bu da açıkların kısmen kamuya açık ama hâlâ yamasız olduğu bir pencere oluşturdu. Vakıf, benzer şekilde takılan düzeltmelerden liderliği daha erken haberdar edip bunları daha hızlı bir çözüme yönlendirebilmek için süreçlerini değiştirdiğini söylüyor.

Trafiğe gerçekten hizmet edeni kontrol etmek

Güncellemenin işe yaraması yalnızca isteklere yanıt veren PHP runtime'ına ulaşmasıyla mümkündür; yeni araç tam da bu noktada devreye giriyor. dev.to yazısı, Debian 12 ve 13 için, tanınan her PHP kurulumunu (CLI, FPM, CGI ve Apache mod_php dahil) envanterleyip paket sürümlerini bilinen düzeltilmiş eşiklerle karşılaştıran salt-okunur bir açık kaynak betik olan PHP2Shell Checker'ı tanıtıyor.

Yazıya göre düzeltilmiş paket sürümleri, Debian 12 (bookworm) üzerinde PHP 8.2 için 8.2.35-1deb12u1 ve Debian 13 (trixie) üzerinde PHP 8.4 için 8.4.27-1deb13u1; bunlar Debian duyuruları DLA-4848-1 ve DSA-6574-1 ile eşleşiyor. Duyuru ayrıca PHP-FPM, Apache mod_php, CGI, FrankenPHP ve LiteSpeed gibi web hizmeti veren kurulumları da kapsıyor.

Araç üç durumdan birini raporluyor: FIXED, UPDATE veya UNKNOWN. UNKNOWN bilinçli bir seçim; çünkü satıcılar bazen en güncel upstream sürüm numarasını benimsemeden güvenlik düzeltmelerini geri taşır (backport) ve iki yönden birini tahmin etmek yanıltıcı olur. Kontrol aracı ayrıca güncellemeleri engelleyebilecek tutulmuş (held) paketleri işaretliyor, APT üzerinden kullanılabilir aday sürümleri gösteriyor ve paketlenmiş kümenin dışındaki PHP runtime'ları için rastgele dizinleri tarayabiliyor. Yalnızca Python standart kütüphanesinde çalışıyor, ağ isteği yapmıyor ve ana makinede hiçbir şey değiştirmiyor.

Yazar, dikkat edilmesi gereken iki sınırlılığa işaret ediyor. Paket meta verileri, çalışan işlemlerin yeniden başlatıldığını kanıtlamıyor; bu yüzden güncellemeden sonra PHP-FPM servisleri, mod_php altındaki Apache ve uzun süre çalışan PHP işlemlerinin yeniden başlatılması gerekiyor. Ayrıca container'lar, chroot'lar, özel derlemeler ve uygulama kodu ayrı kontroller gerektiriyor; FIXED sonucu değerlendirilen paketleri anlatır, sunucunun tamamını değil.

Neden önemli

Amazon raporu, ambargo altındaki bir zafiyetin özel bilgiden aktif exploit denemelerine, yama var olmadan önce geçebildiğini ve savunmacıların yanıt süresini günlerden saatlere sıkıştırabildiğini gösteriyor. Kontrol aracı ise en az o kadar pratik bir boşluğu ele alıyor: bir sunucuda birden fazla PHP dalı bulunabilir ve güncel bir CLI binary'si, hâlâ bir siteye hizmet veren eski PHP-FPM havuzu hakkında hiçbir şey söylemez. Debian yöneticileri için trafiği işleyen her runtime'ı doğrulamak ve ardından işlemleri yeniden başlatmak, yamanın uygulandığını varsaymak ile uygulandığını bilmek arasındaki farktır.