php2shell: Sızdırılan iki kritik PHP açığı ve acil yamaya hazırlık rehberi

PHP güvenlik ekibi 20 Ekim akşamı kısa bir duyuru yayımladı. Bugün, 21 Ekim 2026 saat 14:00 UTC'de (Türkiye saatiyle 17:00) olağan takvimin dışında bir güvenlik sürümü çıkacak ve bu sürüm iki kritik açığı kapatacak. Duyuruda ayrıntı neredeyse yok. Açıklar CVSS v4.0'da 9,2 puan almış, etkilenen ve düzeltilen sürümler de yamayla birlikte açıklanacak. Ekip, ayrıntılar kamuya sızarsa ya da aktif istismar görülürse sürümü öne çekebileceğini de ekliyor.

Bu tür haberler genellikle bir sonraki yama gününe kadar bekleyebilir. Bu sefer neden acil olduğunu anlamak için duyurunun hangi koşullarda yazıldığına bakmak gerekiyor.

Ne oldu?

Olay, 20 Ekim'de Hacker News'te paylaşılan bir gönderiyle başladı. Gönderi, PHP'de iki uzaktan kod çalıştırma (RCE) açığı bulunduğunu, bunların 22 Ekim Perşembe günü açıklanacağını ve PHP 5'ten bu yana tüm sürümleri etkilediğini iddia ediyordu. Paylaşan kişi kanıtı olmadığını kendisi de kabul ediyordu, gönderi kısa süre sonra kaldırıldı. Ekran görüntüleri ise o arada sosyal medyaya yayılmıştı.

Sonra iş ciddileşti:

• Güvenlik araştırma şirketi watchTowr, sızıntının gerçek olduğunu ve açıkların ambargo altında beklediğini doğruladı. Huntress'in aktardığına göre watchTowr, açıklardan birini (CVE-2026-109618) yeniden üretmeyi de başardı.
• Aynı gün PHP ekibi yukarıdaki ön duyuruyu yayımlayarak yamayı sızıntıdaki tarihten bir gün öne çekti.
• Araştırmacılar açıklara php2shell adını verdi. Bu, PHP'nin resmî adlandırması değil. Sansec'in paylaştığı bir ekran görüntüsünde aynı adı taşıyan bir istismar aracı görünüyor.

Açıklar CVE-2026-109618 ve CVE-2026-109619 numaralarıyla takip ediliyor. Bu numaralar sızan gönderide de geçiyordu. PHP'nin kendi duyurusunda ise CVE numarası yok.

Neyi biliyoruz, neyi bilmiyoruz?

Bu olayda en sık yapılan hata, söylentiyi doğrulanmış bilgi gibi aktarmak. Bu yüzden ikisini ayırmak istiyorum.

Doğrulananlar

• İki açık var ve PHP ekibi ikisini de kritik olarak sınıflandırıyor (CVSS v4.0: 9,2).
• Bağımsız bir araştırma ekibi açıkların uzaktan kod çalıştırmaya imkân verdiğini doğruluyor.
• Yama bugün 14:00 UTC'de çıkacak. Resmî düzeltmeler yalnızca desteklenen dallara gelecek: 8.2, 8.3, 8.4 ve 8.5.
• Bu yazı yazılırken bilinen bir istismar yok. Huntress, 20 Ekim itibarıyla müşteri ortamlarında saldırı görmediğini söylüyor. Açıklar CISA'nın aktif istismar edilen açıklar (KEV) listesinde de değil.

Henüz belirsiz olanlar

• Hangi sürümler etkileniyor? Sızıntıda PHP 5'ten itibaren tüm sürümler, ekran görüntüsündeki araçta 5.4.0 ve sonrası yazıyor. Bunların hiçbiri resmî bir duyuruyla doğrulanmış değil.
• Hangi bileşen? PHP açığın çekirdekte mi yoksa bir eklentide mi olduğunu açıklamadı. Belirli bir yapılandırma gerekip gerekmediği de bilinmiyor.
• Puan: Sızıntıda geçen 10,0 puanı PHP'ye ait değil. Resmî değerlendirme 9,2.

İnternette açığın hangi fonksiyonda olduğuna dair tahminler dolaşıyor. Resmî açıklama gelmeden bunlara göre yapılandırma değiştirmenizi önermem. Yanlış bir varsayım, yanlış bir güven duygusu yaratabilir.

Bu neden bu kadar önemli?

Birkaç nedeni var:

1. Yaygınlık: PHP hâlâ webin önemli bir kısmının altında çalışıyor. WordPress, Magento, Drupal, Laravel uygulamaları, cPanel ve Plesk gibi kontrol panelleri, hatta bazı donanım cihazları ve Windows yazılımları gömülü PHP içeriyor. Açık uygulama kodunda değil de PHP'nin kendisindeyse, kodunuz ne kadar temiz olursa olsun etkilenebilirsiniz.
2. Hazırlık süresi kısaldı: Normalde koordineli bir açıklamada üreticiler yamayı hazırlar, büyük dağıtımlar ve barındırma şirketleri paketlerini önceden hazırlar. Sızıntı bu süreci bozdu. Saldırganlar da savunmacılar da aynı anda harekete geçiyor.
3. Yama, saldırı için bir yol haritası: Yama yayımlandığında kod değişikliği herkese açık olacak. Sansec, yamadan sonraki dakikalar içinde kitlesel saldırılar beklediğini söylüyor. Tarih de bu endişeyi destekliyor. Akamai, Haziran 2024'teki PHP CGI açığı CVE-2024-4577 kamuya açıklandıktan sonraki 24 saat içinde istismar denemeleri gördüğünü raporlamıştı.
4. Eski sürümler büyük bir sorun: Mallory'nin Shodan verisine dayanan analizine göre, 20 Ekim'de sürüm bilgisi veren yaklaşık 1,5 milyon PHP sunucusunun yüzde 59'u (yaklaşık 884 bin) 8.1 veya daha eski bir sürüm bildiriyor. Bunlar banner sayıları, yani hepsinin açığa sahip olduğu anlamına gelmiyor. Yine de destek dışı PHP'nin ne kadar yaygın olduğunu gösteriyor. 8.1 ve öncesi resmî yama almayacak.

Pratikte bugün ne yapmalı?

Henüz bilinen bir geçici çözüm yok. Yapılacak şeylerin çoğu hazırlık ve hız ile ilgili.

1. Envanter çıkarın

Nerede PHP çalıştığını gerçekten biliyor musunuz? Sadece ana uygulama sunucularınıza değil; eski kampanya sitelerine, iç araçlara, CI imajlarına, Docker base image'larına ve üçüncü taraf ürünlere de bakın. Hızlı bir kontrol için:

php -v
# Container imajlarında
docker run --rm <imaj> php -v
# Debian/Ubuntu tabanlı sistemlerde kurulu paketler
dpkg -l | grep -i php

2. Yamaya hazır olun

Yama çıktığında önce internete açık sistemleri güncelleyin. Dağıtım paketlerini kullanıyorsanız (Debian, Ubuntu, RHEL, Alpine) bakımcıların backport'larını takip edin. Bunlar resmî PHP sürüm numarasından farklı numaralarla gelebilir. Resmî Docker imajlarını kullanıyorsanız imajları yeniden çekip build alın, eski bir tag'e sabitlenmiş Dockerfile'lar yamayı kendiliğinden almaz.

3. Barındırma sağlayıcınızla konuşun

Paylaşımlı hosting veya yönetilen bir platform kullanıyorsanız PHP'yi siz güncellemiyorsunuz. Sağlayıcınıza bugün yama planını sorun.

4. Destek dışı sürümler için karar verin

8.1, 8.0, 7.x veya 5.x üzerindeyseniz resmî yama gelmeyecek. Seçenekleriniz kısıtlı: desteklenen bir sürüme geçmek, sistemi internetten çekmek ya da en azından VPN veya WAF arkasına almak. CERT-EU de yama gelene kadar internete açık uygulamaları izole etmeyi öneriyor.

5. İzleyin

php-fpm, php-cgi, apache2 veya httpd süreçlerinin kabuk, yorumlayıcı ya da curl/wget gibi indirme araçları başlatması normal değildir. Bu tür alt süreçleri izlemek erken uyarı sağlar. Şüpheli bir durumda sunucuyu izole edin, logları saklayın ve web kök dizininde yeni dosya, web shell, cron işi ya da yeni kullanıcı hesabı olup olmadığını kontrol edin.

Son söz

php2shell, sorumlu açıklama sürecinin ne kadar kırılgan olabileceğini gösteriyor. Tek bir gönderi, PHP ekibinin takvimini bir gün öne çekmesine yetti. Asıl ders ise bu olaydan bağımsız: PHP sürümünüzü güncel tutmak "bir ara yaparız" denecek bir iş değil. Altyapınızda 8.1 veya daha eski bir sürüm varsa bu olay iyi bir uyarı. Bir sonraki kritik açıkta yamayı uygulayabilmek için önce desteklenen bir sürümde olmanız gerekiyor.

Yama yayımlandığında etkilenen sürümler ve teknik ayrıntılar netleşecek. O zamana kadar en iyi strateji envanteri hazır tutmak, güncelleme yolunu test etmek ve resmî kaynakları takip etmek.