PHP2Shell: Duyuru tarihi, riskin başladığı tarih değil

PHP2Shell adıyla anılan CVE-2026-109618 ve CVE-2026-109619, etkilenen PHP kurulumlarında kimlik doğrulama olmadan uzaktan kod çalıştırılmasına yol açabilen iki kritik açık. Güvenlik güncellemeleri 21 Ekim 2026'da yayımlandı. Ancak bu haberde benim dikkatimi en çok çeken ayrıntı, takvimin daha önce başlaması: tuzak sunucu kayıtlarında 17 Ekim'e uzanan bir istismar girişimi bulunuyor.

Bana göre bu, güncelleme süresini yalnızca duyuru anından itibaren ölçmenin eksik kaldığını gösteriyor. Bir açık hakkında ayrıntıların henüz kamuya açıklanmamış olması, saldırganların o açığı bilmediği anlamına gelmiyor. Savunma planının hem bugünkü açığı kapatması hem de geçmişte ne olmuş olabileceğini araştırması gerekiyor.

Girişim görmek ile ele geçirilmek aynı şey değil

Duyurudan önceki girişimlerin gözlemlenmesi önemli; fakat bu kayıtlar, hedef alınan her gerçek sistemin başarıyla ele geçirildiğini kanıtlamıyor. Erken girişimlerin gerçek sistemlerde başarılı olup olmayacağına ilişkin teknik belirsizlik sürüyor.

Ben bu ayrımı korumayı önemli buluyorum. “Herkes ele geçirildi” demek de “bizim uygulamada sorun görünmüyor” diyerek beklemek de eldeki bulgulardan çıkarılabilecek sağlıklı sonuçlar değil. Benim önceliğim, etkilenen kurulumları belirlemek, yamayı uygulamak ve günlük incelemesini en az 17 Ekim'e kadar geriye götürmek olurdu.

Sürüm numarasından çalışan uygulamaya

İki açık için yayımlanan ilk düzeltilmiş sürümler PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Desteklenen dallarda bu sürümlere veya ilgili düzeltmeleri içeren daha yeni paketlere geçiş esas çözüm. Dağıtımların geriye taşıdığı güvenlik yamaları varsa, durumu yalnızca görünen PHP sürüm numarasıyla değerlendirmemek gerekiyor.

Buradaki operasyonel ders benim için somut: sunucuda bir paketi güncellemek, bütün uygulamaların o paketi kullandığını göstermiyor. Web isteklerini karşılayan PHP sürecini, konteyner içindeki çalışma ortamını ve ayrı uygulama havuzlarını da doğrulamak gerekir. Komut satırında görülen sürüm, tek başına bütün sitelerin güncellendiğinin kanıtı değil.

ARM64 bulgusu, diğer sunucular için erteleme izni değil

İlk teknik değerlendirmeler, ARM64 üzerinde adres alanı yerleşimini rastgeleleştiren ASLR korumasının kaba kuvvetle daha kolay aşılabildiğini gösteriyor. x86-64 tarafında aynı koruma saldırıyı zorlaştırabiliyor. Ben bu farkı, güncelleme sırasını belirlerken hesaba katılacak bir etken olarak görüyorum; x86-64 sistemleri güvenli ilan etmek için bir gerekçe olarak görmüyorum.

Benzer biçimde, internette PoC etiketiyle bir depo bulunması da çalışan bir istismar zincirinin bağımsız olarak doğrulandığı anlamına gelmiyor. Kodu ve hedef koşullarını incelemeden bu iddiaları kesin sonuç gibi aktarmak, riski anlamayı kolaylaştırmıyor.

Geçici önlem, tamamlanmış iş anlamına gelmiyor

İstek filtreleri ve bazı PHP ayarları belirli saldırı yollarına karşı maruziyeti azaltabiliyor; fakat iki açığın tamamını kapatan bir yapılandırma çözümü bulunmuyor. Bu önlemleri uygularken dosya yükleme gibi gerçek kullanıcı işlevlerine etkisini de değerlendirmek gerekiyor.

Benim bu olaydan çıkardığım sonuç, yama sürecinin indirme tamamlandığında bitmediği. Düzeltmenin web trafiğini karşılayan süreçlerde etkin olduğunu görmek ve geçmişteki şüpheli hareketleri incelemek de işin parçası. PHP2Shell, güvenlik duyurusunun bir başlangıç çizgisi değil, zaten başlamış olabilecek bir riskin görünür hâle geldiği an olabileceğini hatırlatıyor.

Kapak görseli yapay zekâ ile üretilmiş temsili bir sahnedir; gerçek bir saldırının fotoğrafı değildir.