Hızlı cevap: PHP core içinde iki kritik uzaktan kod çalıştırma açığı yayımlandı, gayriresmi adıyla PHP2Shell. CVE-2026-109618 ve CVE-2026-109619, ikisi de CVSS v4.0 9.2 kritik seviyesinde. Erken ve henüz doğrulanmamış PoC raporlarına göre kök neden çok parçalı (multipart) yükleme işlemede ve session.upload_progress işleyicisinde ortaya çıkan iki heap use after free hatasıdır. Desteklenen 8.2 ile 8.5 arası dallar 2026-10-21 günü yama aldı, 8.0 ve 8.1 ise ömrünü tamamladığı için yama almaz. Yama sürümlerini php.net duyurusundan teyit ederek bugün güncelleyin.

PHP hâlâ dünyadaki web sitelerinin büyük çoğunluğunu çalıştıran dildir. WordPress, WooCommerce, Laravel ve Magento üzerine kurulu kurumsal sistemlerin tamamı bu çekirdeğin üzerinde durur. 21 Ekim 2026 günü php.net üzerinden duyurulan iki açık, tam da bu geniş tabanı hedef alıyor. Embargo yayından önce sızdığı için sürüm öne çekildi ve savunucuların eline çok dar bir zaman penceresi kaldı. Bu yazıda sadece PHP core açığına odaklanıyoruz, abartısız ve kanıt temelli şekilde ne olduğunu, kimin etkilendiğini ve bugün ne yapmanız gerektiğini anlatıyoruz.

PHP2Shell nedir ve neden kritik

PHP2Shell, iki ayrı CVE için güvenlik topluluğunda dolaşan gayriresmi bir takma addır, resmi bir marka değildir. İki kayıt da PHP core içinde uzaktan kod çalıştırmaya yol açabilen bellek bozulması sınıfındadır. CVSS v4.0 puanları 9.2 olarak verildi, bu kritik aralığın üst ucudur ve genellikle kimlik doğrulaması gerektirmeyen, ağ üzerinden tetiklenebilen, etkisi yüksek açıkları işaret eder.

Erken teknik raporlar, kök nedeni iki heap use after free olarak tarif ediyor. Önemli uyarı şudur, bu raporlar henüz doğrulanmamış ve erken aşamadadır. Anlatıma göre birinci hata session.upload_progress işleyicisinde, yani ext/session/session.c içindeki php_session_rfc1867_callback yolunda bulunuyor ve çok parçalı yükleme sırasında erişiliyor. İkinci hata multipart ayrıştırıcının kendisinde, yani multipart/form-data gövdesi taşıyan herhangi bir POST isteğinde tetiklenebiliyor. watchTowr ekibi CVE-2026-109618 için bir üretim sürecini bildirdi. Buradaki dürüst sınır şudur, use after free hatasından güvenilir kod çalıştırmaya giden tam zincir kamuya tam olarak gösterilmedi. Kullanılabilirlik gerçek, ancak silahlaştırmanın ne kadar kolay olduğu yayın anında açık değildi.

Kim etkileniyor

Bu açığın yüzeyi istisnai derecede geniştir çünkü sorun bir eklentide veya çerçevede değil, dilin çekirdeğindedir. Multipart ayrıştırıcıyı ilgilendiren ikinci hata özellikle dikkat çeker, çünkü dosya yükleme kabul etmeyen bir uç nokta bile multipart/form-data gövdesi alırsa ayrıştırma yoluna girebilir.

Yamasız tüm 8.x kurulumları risk altında kabul edilmelidir. Sürüm eşleşmesinin etkilenebilirlik anlamına geldiğini, kesin açık demek olmadığını hatırlatmak isteriz, çünkü bazı dağıtımlar düzeltmeleri geriye taşımış (backport) veya ek sertleştirme uygulamış olabilir. Ömrünü tamamlamış 8.0 ve 8.1 hatları için resmi yama yoktur, bu da onları yapısal bir risk haline getirir. 5.x ve 7.x hatlarının da etkilendiği iddia edildi, ancak bu iddia doğrulanmadı ve bu dallar için zaten yama yayımlanmıyor. Ömrünü tamamlamış çalışma zamanlarının neden ayrı bir tehdit kategorisi olduğunu ömür sonu runtime riski ve sürüm göçü rehberimizde ayrıntılı ele aldık.

Hangi sürüm güvenli, zorunlu sürüm matrisi

Aşağıdaki tablo hangi dalın yama aldığını özetler. Tam sürüm numaralarını güncellemeden önce mutlaka php.net üzerindeki resmi duyurudan teyit edin, çünkü bu rakamlar tek kaynaklı ve yayın günü yayımlandı.

PHP dalı Mevcut durum Yamalı sürüm Durum
8.5 Desteklenen 8.5.12 Yama alır, hemen güncelleyin
8.4 Desteklenen 8.4.27 Yama alır, hemen güncelleyin
8.3 Desteklenen 8.3.36 Yama alır, hemen güncelleyin
8.2 Desteklenen 8.2.35 Yama alır, hemen güncelleyin
8.1 Ömrünü tamamladı Yok Yama yok, göç şart
8.0 Ömrünü tamamladı Yok Yama yok, göç şart

Çalışan sürümünüzü öğrenmek için sunucuda php dash v çıktısına veya barındırma panelinizin PHP sürüm bilgisine bakın. Sürümünüz yukarıdaki yamalı sayıdan eskiyse etkilenebilir kabul edin ve güncelleyin. Konteyner kullanıyorsanız yalnız paketi güncellemek yetmez, imajı yeniden oluşturup dağıtmanız gerekir.

Ne yapmalı, aciliyet ve azaltma

Öncelik yamadır. Desteklenen bir daldaysanız bugün güncellemeyi planlayın. Yamayı hemen uygulayamıyorsanız risk yüzeyini daraltacak geçici azaltmalar vardır, ancak bunların hiçbiri yamanın yerine geçmez.

Birinci azaltma, php.ini içinde session.upload_progress.enabled değerini Off yapmaktır. Bu yalnızca şüpheli yollardan birini kapatır, multipart ayrıştırıcıyı ilgilendiren ikinci hatayı kapatmaz. İkinci azaltma, yükleme kabul etmeyen uç noktalarda multipart/form-data taşıyan POST isteklerini WAF veya ters vekil (proxy) katmanında sınırlamak veya incelemektir. Bu bir uzaktan kod çalıştırma sınıfı olduğu için temel korunma mantığını komut enjeksiyonu ve RCE korunma yazımızda bulabilirsiniz.

Aciliyet konusunda açık olalım. Embargo yaklaşık 20 Ekim 2026 civarında erken sızdı ve yayın bu yüzden öne çekildi. Yaygın ve aktif sömürü yayın anında kesin olarak teyit edilmedi, bu bilgi şu an için tek kaynaklıdır. Yine de CVSS 9.2 seviyesi, çekirdek bellek bozulması ve embargo sızıntısının bir araya gelmesi, bu açığı bekleyemeyecek sınıfa koyar. Yama penceresinin daralması saldırganlar lehine çalışır.

Kurumsal WordPress kurulumlarını sertleştirme ve olası bir ihlal sonrası temizlik için kurumsal WordPress güvenliği rehberimize, çevrim içi satış tarafında PCI DSS ve Magento ya da WooCommerce özelinde ise elektronik ticaret veri kurtarma yazımıza göz atabilirsiniz. Daha geniş bir yama disiplini kurmak istiyorsanız yama yönetimi rehberimiz süreci baştan sona anlatır.

Not olarak, aynı gün Node.js tarafında da bir güvenlik sürümü çıktı. DSET altyapısı Next.js ve Node üzerinde çalıştığı için bizi doğrudan PHP değil o sürüm ilgilendirdi, detayları Node.js Ekim 2026 güvenlik güncellemesi rehberinde ve kardeş bir uzaktan kod çalıştırma açığını Node.js Brotli RCE yazısında bulabilirsiniz.

KAOS ve DSET yaklaşımı

DSET bünyesindeki yerel yapay zekâ motoru KAOS, bu tür bir açığı değerlendirirken kanıt temelli ve ölçülü bir yol izler. İlk adım sürüm tespitidir, yani hedef sistemin çalıştırdığı PHP dalının ve sürümünün pasif ve aktif yöntemlerle belirlenmesi. İkinci adım bu sürümün bilinen CVE kayıtlarıyla eşleştirilmesidir. Üçüncü adım ise KEV listeleri ve sömürü olasılığı gibi girdilerle önceliklendirmedir.

Burada vurgulamak istediğimiz ilke şudur, sürüm eşleşmesi bir hipotezdir, kanıt değildir. KAOS içindeki abartı freni, bir sürüm eşleşmesini otomatik olarak doğrulanmış açık ilan etmez. Backport yapılmış olabilir, azaltma uygulanmış olabilir veya uç nokta hiç multipart isteği kabul etmiyor olabilir. Kesin teyit, yetki dahilinde yapılan aktif doğrulama ister ve bu açık özelinde kod çalıştırma zinciri kamuya tam gösterilmediği için doğrulama da aynı ölçüde dikkatli yürütülür. Amacımız panik değil, doğru önceliklendirme ve yamanın hızla uygulanmasıdır.

Sık sorulan sorular

PHP2Shell resmi bir isim mi ve bir açık mı yoksa iki açık mı? PHP2Shell gayriresmi bir takma addır, php.net veya NVD tarafından verilmiş resmi bir ad değildir. Arkasında iki ayrı CVE vardır, CVE-2026-109618 ve CVE-2026-109619, ikisi de PHP core içinde uzaktan kod çalıştırma sınıfındadır ve CVSS v4.0 9.2 ile kritik olarak derecelendirildi. İsim topluluk tarafından türetildiği için farklı kaynaklarda küçük farklarla geçebilir, kesin referans her zaman CVE kimlikleridir.

Yama uygulayamıyorum, session.upload_progress kapatmak yeterli mi? Hayır, tek başına yeterli değildir. session.upload_progress.enabled değerini Off yapmak erken raporlarda tarif edilen iki yoldan yalnız birini kapatır. İkinci hata multipart ayrıştırıcının kendisinde tarif edildiği için multipart/form-data taşıyan herhangi bir POST isteğiyle tetiklenebilir ve bu ayar o yolu kapatmaz. Bu nedenle session ayarı sadece geçici bir risk azaltmadır, asıl çözüm desteklenen bir dalda yamalı sürüme geçmektir.

Eski PHP 7 veya PHP 8.1 kullanıyorum, ne yapmalıyım? Bu dallar ömrünü tamamlamıştır ve resmi yama almazlar. 7.x hatlarının etkilendiği iddiası doğrulanmadı, ancak doğrulansa bile yama gelmeyeceği için sonuç değişmez. Tek güvenli yol desteklenen bir dala, yani 8.2 ve üzerine göç etmektir. Bu göç yalnız bu açık için değil, sürekli gelen diğer düzeltmeleri de alabilmeniz için gereklidir, çünkü ömrünü tamamlamış bir çalışma zamanı kalıcı ve birikerek büyüyen bir risktir.

Kaynaklar

PHP tabanlı kurumsal sisteminizin bu açığa karşı durumunu değerlendirmek, yama planını çıkarmak ve geçici azaltmaları doğru kurmak için DSET ile iletişime geçin. Ekibimiz Ankara Hacettepe Teknokent yerleşkesinden sızma testi, olay müdahale ve güvenlik danışmanlığı hizmetleri sunar.