PHP2Shell açığı: PHP için acil yama ve korunma rehberi

GÜVENLİK HABERİ · TEKNİK ANALİZ

PHP ekibi, iki kritik güvenlik açığı için acil güncelleme hazırlıyor. PHP2Shell adıyla gündeme gelen olayda sunucu yöneticilerinin önceliği, çalışan PHP kurulumlarını belirlemek ve güvenlik paketleri çıkar çıkmaz güncellemeyi doğrulamak. İlk yayımlanan bazı teknik açıklamalar ve geçici çözüm önerileri ise güvenilirliğini kaybetmiş durumda.

Son kaynak kontrolü: 21 Ekim 2026, 14.41 TSİ

PHP2Shell açığı, PHP’de bildirilen CVE-2026-109618 ve CVE-2026-109619 güvenlik sorunları için kullanılan isim. CERT-EU, olayın kimlik doğrulaması olmadan uzaktan kod çalıştırma riski taşıyabileceğini bildiriyor. PHP’nin doğruladığı önem derecesi, her iki açık için CVSS v4.0 9.2. Bu puan, olayın kritik öncelikle ele alınmasını gerektiriyor. CERT-EU güvenlik bildirimi

Bir uygulamanın güncel olması, altında çalışan PHP paketinin de güncel olduğunu göstermiyor. Bu nedenle olay; site sahiplerini, paylaşımlı hosting işletmelerini ve kendi sunucusunu yöneten ekipleri aynı soruyla karşı karşıya bırakıyor: İnternetten gelen isteği gerçekte hangi PHP sürümü işliyor?

PHP2Shell nedir, saldırgan ne yapabilir?

RCE, İngilizce Remote Code Execution ifadesinin kısaltmasıdır. Uzaktan kod çalıştırma açığı, saldırganın etkilenen sistemde kendi belirlediği işlemleri yaptırmasına yol açabilir. Kimlik doğrulamasız bir saldırı yolu bulunması, önceden siteye üye olmanın veya yönetici parolasını bilmenin gerekmeyebileceği anlamına gelir.

Başarılı bir istismarın etkisini, ele geçirilen sürecin yetkileri belirler. PHP’nin okuyabildiği yapılandırma dosyaları, veritabanı bağlantı bilgileri ve yazabildiği dizinler risk alanına girebilir. Site dosyalarının değiştirilmesi, veri sızıntısı veya sonradan erişim sağlayan bir webshell bırakılması olası sonuçlardır. Bunlar, kod çalıştırma elde edilmesi hâlindeki teknik risk değerlendirmesidir; her PHP2Shell girişiminin bu sonuçları doğurduğuna ilişkin bir vaka listesi değildir.

RCE, otomatik olarak root yetkisi demek değildir. Ayrı site kullanıcıları ve doğru dosya izinleri hasarın yayılmasını sınırlayabilir. Aynı işletim sistemi kullanıcısıyla çalışan, birbirlerinin dosyalarına erişebilen sitelerde ise tek bir uygulamanın ele geçirilmesi daha geniş bir soruna dönüşebilir.

Hangi PHP sürümleri ve uygulamalar risk altında?

CERT-EU, etki alanının PHP 5 ve sonrasına uzanabileceğini belirtiyor. Ancak bu, her sürümün her yapılandırmada aynı yöntemle istismar edilebildiğini kanıtlayan bir uyumluluk tablosu değil. Kesin sürüm aralıkları, saldırı koşulları ve düzeltmelerin eşleştirilmesi için üreticinin ayrıntılı duyurusu esas alınmalı.

Destek bilgileri: PHP Supported Versions. Bu tablo, herhangi bir sürümü PHP2Shell karşısında güvenli ilan etmez.

WordPress, XenForo, Laravel tabanlı uygulamalar ve özel PHP servisleri altyapı envanterine dâhil edilmeli. Bir ürünün bu listede bulunması, o ürüne özgü ayrı bir açık doğrulandığı anlamına gelmez. Değerlendirilmesi gereken, uygulamanın kullandığı PHP çalışma ortamıdır. Yalnızca WordPress çekirdeğini veya bir forum eklentisini güncellemek, sunucudaki PHP paketini kendiliğinden yamalamaz.

Unutulan alt alan adları, eski test kurulumları ve yönetim araçları da gözden geçirilmeli. Ana sitenin yeni PHP sürümüne geçirilmesi, başka bir sanal sunucuya bağlı eski uygulamanın aynı değişikliği aldığı anlamına gelmeyebilir.

Açığın çalışma biçimi hakkında ne biliniyor?

İlk teknik paylaşımlar, dosya yükleme ilerlemesini oturum verisine kaydeden session.upload_progress özelliğini işaret etti. PHP belgelerine göre bu bilgi, uygulamanın PHP betikleri çalıştırılmadan önce yazılır. Bu katmandaki bir hata, uygulamanın oturum kontrolü veya dosya doğrulaması devreye girmeden işlenebilir. Ancak bu mimari bilgi, iki CVE’nin kök nedeninin kesin olarak belirlendiği anlamına gelmiyor. PHP upload progress belgesi

Use-after-free iddiasındaki önemli düzeltme

Use-after-free, serbest bırakılmış bir bellek alanının hâlâ geçerliymiş gibi kullanılmasıdır. PHP2Shell hakkında yayılan açıklamalardan biri, yükleme sırasında saklanan bellek işaretçilerinin serbest bırakılan oturum verisine eriştiğini ileri sürdü.

Bu açıklamanın yayımlandığı araştırma yazısında daha sonra düzeltme yapıldı: Z_TRY_ADDREF(progress->data) işleminin referans sayısını artırdığı, dolayısıyla serbest bırakıldığı varsayılan dizinin yaşamaya devam ettiği belirtildi. Yazar, o yol için önceki use-after-free yorumunu geri çekti. Aynı sayfadaki başka bir bellek hatası iddiası da çalışan RCE olarak doğrulanmış değil. Araştırmacının düzeltme notu

Bu düzeltme, PHP’nin duyurduğu iki kritik açığın bulunmadığını göstermiyor. Gösterdiği şey, internette dolaşan bir teknik açıklamanın bu açıkların güvenilir tarifi olarak kullanılamayacağı.

Bir PoC’nin gerçekten kanıtlaması gereken şey

İncelenen 0x4148 laboratuvar deposu, belirli bir kod yoluna erişildiğini bildirirken çökme veya kod çalıştırma elde edilmediğini de açıkça söylüyor. Bu nedenle araçta görünen “vulnerable” benzeri bir etiket, bağımsız RCE doğrulaması yerine geçmez. Laboratuvar deposunun sınırlamaları

Bir pentest raporunda teknoloji tespiti, saldırı yüzeyine erişim, bellek hatası ve kod çalıştırma ayrı bulgulardır. Belirli bir CVE’ye bağlanabilen güçlü doğrulama; kök nedenin eşleşmesini, tekrar üretilebilir sonucu ve ilgili düzeltmeden sonra aynı sorunun ortadan kalkmasını gerektirir. Sadece PHP sürümünü okuyan bir tarayıcı bu kanıt zincirini kuramaz.

Aktif saldırı var mı, Cloudflare koruyor mu?

Cloudflare CTO’su Dane Knecht, 21 Ekim’de erken saldırılar gözlemlediklerini ve bilinen saldırı yolları için ilk WAF kurallarını devreye aldıklarını açıkladı. Kuralların ücretsiz plan dâhil müşterilere sunulduğu belirtildi. Bu açıklama, saldırı girişimlerinin başladığını gösteriyor; başarılı ihlallerin toplam sayısını veya tüm saldırı biçimlerinin engellendiğini göstermiyor. Cloudflare açıklaması

WAF, gelen istekleri inceleyen bir güvenlik katmanıdır. Korumanın işe yaraması için trafiğin bu katmandan geçmesi gerekir. Doğrudan origin sunucuya ulaşan istekler, proxy dışında bırakılan alt alan adları ve devre dışı kurallar ayrıca kontrol edilmeli. Bu nedenle Cloudflare kullanmak, PHP güncellemesini ertelemek için yeterli bir gerekçe değildir.

Dosya yükleme formunu kaldırmak veya tek bir multipart isteğini engellemek de kapsamlı çözüm sayılmamalı. Bir kontrolün belirli isteği durdurması, iki açığın bütün yollarını kapattığını göstermez. CERT-EU, hemen yama uygulanamayan internet bağlantılı uygulamaların geçici olarak izole edilmesini değerlendirmeyi öneriyor.

İzolasyon seçilecekse erişim PHP çalışmadan önce kesilmeli. Uygulamanın içine eklenen bir bakım ekranı, PHP işleyicisinin istek almaya devam ettiği bir kurulumda aynı güvenceyi sağlamaz.

PHP2Shell güncellemesi nasıl uygulanır ve doğrulanır?

Güncellemenin tamamlandığını gösteren ölçüt, paketin indirilmesi değil, web isteğini karşılayan sürecin düzeltmeyi içermesidir. Uygulanacak işlem, PHP’nin nasıl kurulduğuna ve hangi işleyiciyle çalıştığına göre değişir.

1. Kurulumları çıkarın. Domainleri, alt alan adlarını, kullanılan PHP dallarını, paket kaynaklarını ve web işleyicilerini kaydedin. Birden fazla sunucu veya konteyner varsa her örneği listeleyin.
2. Düzeltmeyi paketle eşleştirin. Resmî PHP duyurusunu ve dağıtım ya da hosting sağlayıcısının güvenlik notunu kontrol edin. Eski sürüm numarasını koruyan geri taşınmış bir yama için paket revizyonunu esas alın.
3. Uygun güncellemeyi uygulayın. Destekli dalın güvenlik paketine geçin. Eski uygulamayı daha yeni PHP dalına taşımak gerekiyorsa tema, eklenti ve bağımlılık uyumluluğunu ayrıca kontrol edin.
4. Çalışan süreçleri yenileyin. FPM, Apache modülü, LSPHP veya konteyner için kullanılan işletim yöntemine uygun yeniden başlatma ya da yeniden oluşturma işlemini uygulayın.
5. Web tarafında doğrulayın. Yetkili bir sistem bilgi ekranından çalışan PHP sürümünü ve işleyicisini kontrol edin. Sonra oturum açma, dosya yükleme ve kritik iş akışlarını deneyin.

Terminaldeki PHP sürümü neden yeterli değil?

php -v, çağırdığınız PHP ikilisinin sürümünü verir. Web sitesi farklı bir PHP ikilisi veya işleyici kullanabilir. PHP’nin resmî belgeleri de CLI, FPM ve LiteSpeed gibi farklı SAPI değerlerini tanımlar. Bu yüzden terminal çıktısını sanal sunucu yapılandırması ve web üzerinden çalışan ortamla eşleştirmek gerekir. PHP SAPI belgesi

OpenLiteSpeed ve CyberPanel’de LSPHP ayrıntısı

OpenLiteSpeed’in detached mode çalışma biçiminde PHP süreçleri web sunucusundan bağımsız kalabilir. Yalnızca OpenLiteSpeed’i yeniden başlatmak, eski PHP süreçlerinin de sonlandığını garanti etmez. Kullanımdaki LSPHP paketleri güncellendikten sonra bu süreçlerin yenilendiği ayrıca kontrol edilmeli.

OpenLiteSpeed’in resmî belgesi, sunucu genelindeki detached PHP süreçlerini sonraki kullanımda yenilemek için aşağıdaki işaret dosyasını tarif ediyor:

touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt

Bu komut yama kurmaz. Standart kurulum yolunu varsayar; ilgili işleyici yeniden kullanıldığında süreç yenilemesini tetikler. OpenLiteSpeed detached mode belgesi

Sunucuda ihlal olup olmadığı nasıl araştırılır?

Güncelleme, geçmişte gerçekleşmiş bir ihlalin etkilerini ortadan kaldırmaz. Huntress’in yayımladığı savunma önerileri, PHP süreçlerinin başlattığı alt süreçlerin izlenmesine ve şüpheli dosya hareketlerinin araştırılmasına odaklanıyor. İncelenen duyuruda henüz PHP2Shell’e özgü doğrulanmış IOC listesi bulunmuyordu. Huntress değerlendirmesi

• PHP veya web sunucusu süreçlerinin beklenmedik shell, yorumlayıcı ya da indirme aracı başlatması.
• Site dizinlerinde yeni çalıştırılabilir dosyalar veya açıklanamayan içerik değişiklikleri.
• Yeni cron görevleri, sistem hesapları veya uygulama yöneticileri.
• Olağandışı dış bağlantılar ve aynı zamana denk gelen erişim, hata veya süreç kayıtları.

Bu işaretler tek başına PHP2Shell istismarını kanıtlamaz. Meşru işler de benzer süreçler başlatabilir; değerlendirme, sistemin normal davranışı ve zaman çizelgesiyle birlikte yapılmalı. Şüpheli durumda sunucuyu izole etmek, günlükleri korumak ve değişen dosyaları güvenilir bir kopyayla karşılaştırmak gerekir. Doğrulanmış ihlalde erişilmiş olabilecek sırların yenilenmesi ve temiz ortamdan geri dönüş de müdahale planına dâhil edilmelidir.

PHP2Shell hakkında sık sorulan sorular

WordPress’i güncellersem PHP2Shell kapanır mı?

WordPress sürümünü değiştirmek, sunucudaki PHP çalışma ortamını normalde değiştirmez. Hosting panelindeki PHP paketi ve sitenin bağlı olduğu işleyici ayrıca kontrol edilmeli. WordPress güncellemesi kendi güvenlik açıkları için önemini korur.

Linux veya OpenLiteSpeed kullanmak koruma sağlar mı?

İşletim sistemi ya da web sunucusu adı, tek başına güvenlik kanıtı değildir. Bir araştırmacının belirli laboratuvar yönteminin bir işleyicide çalışmaması, iki CVE’nin o ortamı etkilemediğini göstermez. Kesin karar, resmî etki koşulları ve kurulu düzeltme üzerinden verilmeli.

HTTP yanıtındaki PHP sürümünü gizlemek yeterli mi?

Sürüm bilgisini saklamak alttaki yazılım hatasını düzeltmez. Ayrıca dışarıdan görülen başlık, paket sağlayıcısının uyguladığı güvenlik düzeltmelerini eksiksiz göstermez. Yama doğrulaması sunucudaki paket ve çalışan süreç üzerinden yapılmalı.

Bir tarayıcı “açık yok” diyorsa sunucu güvenli mi?

Taramanın hangi koşulları sınadığı bilinmeden bu sonuca varılamaz. Tek bir isteğin engellenmesi veya bir özelliğin kapalı görünmesi, bütün saldırı yollarının kapandığını kanıtlamaz. Üretici duyurusu, paket doğrulaması ve yetkili test birlikte değerlendirilmelidir.

PHP’yi tamamen kaldırmak gerekiyor mu?

Giderim, kullanılan uygulamalarla uyumlu ve ilgili düzeltmeleri içeren PHP ortamına geçmektir. Güvenlik güncellemesi uygulanamayan sistemlerde geçici erişim kısıtlaması değerlendirilebilir. Kalıcı altyapı değişikliği için uygulama gereksinimleri ayrıca ele alınmalıdır.

İki CVE aynı saldırıda birlikte mi kullanılıyor?

Bu haberin son kaynak kontrolünde, her açığın ayrı çalışma koşullarını ve aralarındaki ilişkiyi kesinleştiren resmî teknik ayrıntılar yayımlanmamıştı. İki CVE bulunması, her başarılı saldırının ikisini de zorunlu olarak kullandığını göstermez.