PHP2Shell: Uygulama Daha Çalışmadan Ele Geçirilen Sunucu

Bir web sunucusunun giriş sayfası var. Kullanıcı adı ve parola soruyor. Doğru bilgiyi vermeden içeri girilemez diye düşünüyoruz. Peki sunucu, bizim yazdığımız giriş kodunu çalıştırmaya hiç sıra gelmeden ele geçirilebilir mi?

21 Ekim 2026'da PHP projesi tam bu soruya "evet" cevabı veren iki açığı duyurdu. CVE-2026-109618 ve CVE-2026-109619 olarak izlenen, topluluğun PHP2Shell adını taktığı açıklar, dilin kendi çalışma zamanında. Gösterilen mod_php yolunda uygulama kodundaki bir hataya gerek yok; PHP gelen isteği hazırlarken bozulabiliyor. İki açık da CVSS v4.0 ölçeğinde 9,2 puan aldı ve kimlik doğrulaması gerektirmiyor. PHP, güvenlik duyurusu, 21 Ekim 2026

Siemens iki gün sonra SSA-566435 ile kendi yazılım ürünlerini tek tek değerlendirdi. Bu yazıda önce hatanın mantığını sade bir dille anlatacağız, sonra bunun bir OT ortamında ne anlama geldiğine bakacağız.

PHP, web sayfalarının sunucu tarafında üretilmesinde kullanılan bir programlama dilidir; birçok yönetim arayüzü, portal ve pano bu dille yazılmıştır. İşçi süreç (worker), sunucuda gelen istekleri sırayla karşılayan ve bir istek bittikten sonra bir sonrakini alan programdır. Uzaktan kod çalıştırma (RCE), saldırganın ağ üzerinden sunucuya kendi komutunu çalıştırtmasıdır. Serbest bırakılmış belleğin kullanımı (use-after-free), programın geri verdiği bir bellek bölgesini hâlâ geçerliymiş gibi okumaya devam etmesidir. CVSS, açıkların ciddiyetini 0 ile 10 arasında puanlayan ortak ölçektir.

Bir istek sunucuda ne yaşar?

Tarayıcı bir form gönderdiğinde, PHP önce bu isteği okur: form alanlarını ayrıştırır, $_POST dizisine yerleştirir, yüklenen dosyaları geçici yere yazar; yükleme ilerlemesi gibi özellikler oturum durumuna da bu aşamada erişebilir. Ancak bütün bunlar bittikten sonra uygulamanın kendi kodu, yani bizim yazdığımız giriş sayfası çalışır. İstek tamamlanınca da PHP temizlik yapar: istek için ayırdığı belleği geri verir, geçici verileri siler. Datadog Security Labs, PHP2Shell analizi

Bu sıralama önemli. Hazırlık ve temizlik aşamaları uygulamadan bağımsızdır. Giriş sayfası ne kadar sıkı yazılmış olursa olsun, isteğin ayrıştırılması ondan önce gelir. Gösterilmiş saldırı yolları uygulama kodu devreye girmeden bu aşamalara ulaşabiliyor; etki, PHP sürümüne ve çalışma biçimine göre değişiyor. PHP projesi bu yüzden en yüksek riski Apache içinde modül olarak çalışan mod_php kurulumlarına veriyor: orada uygulama kodu çalışmadan kimlik doğrulamasız kod çalıştırma gösterildi. İkinci açıktaki istekler arası yol ise aynı işçinin birden fazla isteği işlemesini gerektiriyor. PHP, güvenlik duyurusu

Birinci açık için PHP-FPM, başlangıç başarısız olduğunda çocuk süreci sonlandırır; bu nedenle mod_php üzerinde gösterilen başlangıç-temizlik zinciri FPM’ye doğrudan taşınamaz. PHP yine de web isteği karşılayan bütün kurulumları güncelleme kapsamına alıyor. PHP GHSA

Birinci açık: yarım kalan hazırlık, güvenilen hesap

PHP, bir isteğin kullanabileceği belleğe üst sınır koyar. Bu sınır aşıldığında "bellek tükendi" hatası verir ve isteği yarıda keser. Sorun, kesmenin nasıl yapıldığında: PHP bu durumda longjmp() denen bir sıçramayla o anki işi terk eder. Yarım kalan iş toparlanmaz; sadece bırakılır. Siemens ProductCERT, SSA-566435, CVE-2026-109618 açıklaması

Form alanlarının tutulduğu tabloyu düşünelim. Datadog'un incelediği sürümde PHP, yeni bir alan eklerken önce tablodaki eleman sayacını artırıyor, sonra alanın adı için bellek ayırıyordu. Bellek tam o anda tükenirse sayaç "bir eleman daha var" diyor, ama o elemanın adı ve değeri hiç yazılmamış oluyor. İstek yarıda kesildiği hâlde temizlik aşaması yine çalışıyor ve sayaca güveniyor: tabloyu sökerken o hayalet elemanı da gerçek bir PHP değeri gibi yorumluyor. Datadog Security Labs

Bir benzetmeyle: montaj hattında bir sayaç "bu panoya beş kart takıldı" diyor, ama elektrik kesildiği için beşinci kart hiç takılmamış. Sökümde beşinci yuvaya uzanan el, orada ne bulursa onu "kart" sanıp çekiyor. Temizlik, başlatılmamış veriyi geçerli kabul ettiğinde saldırganın etkileyebildiği bellek yanlış yorumlanabiliyor. Kod çalıştırmaya dönüşmesi için geçerli bellek adresleri gibi ek koşullar da gerekiyor; ASLR ve bilgi sızıntıları bu nedenle önemli.

PHP'nin danışma belgesine göre belleği tüketen isteğin, bozulan yapıyla ilgili olması bile gerekmiyor. Çok parçalı (multipart) form verileri, görünürde PHP'nin sınırları içinde kalarak belleği tüketebiliyor: kullanılabilir içerik uzunluğu olmayan istekler, parça başına sınırsız başlık, iç içe alan adlarıyla birleştirilmiş boş dosya alanları bunun yolları. GitHub Security Advisory GHSA-w8hw-w9fx-j79w

İkinci açık: bir önceki isteğin bıraktığı iz

İkinci açık, art arda gelen istekler arasındaki ilişkiden doğuyor. Bir işçi süreç çok sayıda isteğe hizmet eder. PHP'nin bazı genel değişkenleri (hata durumu, oturum, nesne ve eklenti durumu) işçinin yaşamı boyunca kalır; ama bunların bir kısmı tek bir isteğe ait belleği gösterir. Kural şu: istek belleği geri verilmeden önce bu değişkenler sıfırlanmalı. GitHub Security Advisory GHSA-6wmf-4rv5-p3rp

Ölümcül bir hata, örneğin bellek tükenmesi ya da azami çalışma süresinin aşılması, bu sıfırlamayı yarıda bırakabiliyor. Ya da kapanış sırasında üretilen bir uyarı, sıfırlanmış durumu yeniden dolduruyor. Böylece işçi bir sonraki isteği aldığında, elinde geçerliliğini yitirmiş bir işaretçi oluyor. Normal başlangıç bu işaretçiyi sıfırlayacak; ama bazı işlemler normal başlangıçtan önce çalışıyor ve o eski işaretçiyi okuyor. Bu, serbest bırakılmış belleğin kullanımı demek. GHSA-6wmf-4rv5-p3rp

PHP projesi iki yolu doğruladı. Birincisi yalnız PHP 8.5'te: ölümcül hata için tutulan geri izleme (backtrace) kapanışta sıfırlanmıyor, sonraki isteğin bir ayar uyarısı onu okuyor; mod_php üzerinde komut çalıştırma bu yolla gösterildi. İkincisi dosya yükleme: oturumun yükleme ilerlemesi özelliği, uygulama hiç session_start() çağırmasa bile varsayılan olarak açık ve normal başlangıçtan önce oturum durumunu hazırlıyor; yükleme sırasında bellek tükenirse o durum ortada kalıyor. Bu yoldaki eski durumun yeniden kullanımı hem mod_php hem de PHP-FPM üzerinde doğrulandı; bu, her PHP-FPM kurulumunda uygulamadan bağımsız, tamamlanmış bir RCE zinciri gösterildiği anlamına gelmiyor. GHSA-6wmf-4rv5-p3rp, Datadog Security Labs

Bu açığın bir koşulu var: izi bırakan istekle onu okuyan isteğin aynı işçiye düşmesi gerekiyor. Çok işçili bir kurulumda her denemenin tutma olasılığı düşer; ama açık ortadan kalkmaz, saldırgan daha çok istek gönderir. Datadog Security Labs

SVG indir

Ayrıntıları büyüt

Neden ayar değiştirmek yetmiyor?

İlk akla gelen çözüm bellek sınırını kaldırmak: memory_limit=-1. PHP bunu bir ara önlem olarak öneriyor, ama tamamlanmış saymıyor. Sınır kalksa da işletim sistemi bellek veremediğinde aynı sıçrama yine çalışabiliyor. Daha kötüsü, süreç düzeyinde bellek sınırı koymak (RLIMIT_AS, RLIMIT_DATA) tam da açığın ihtiyaç duyduğu ayırma hatasını tetikleyebiliyor. İkinci açık için session.upload_progress.enabled=0 ve 8.5'te fatal_error_backtraces=0 ayarları yalnız doğrulanmış yolları kapatıyor; diğer eklenti ve hata durumlarını kapsamıyor. Hataları gizlemek de işe yaramıyor: display_errors kapalı olsa da eski duruma erişim sürüyor. PHP, güvenlik duyurusu, GHSA-w8hw-w9fx-j79w

Kalıcı çözüm güncelleme. Yama, bellek tükenmesindeki ani sıçramayı kaldırıp hatayı güvenli bir noktaya erteliyor; daha yüksek bir eşikte ise temizlik yapmadan işçiyi doğrudan sonlandırıyor. İsteğe ait genel durum da yeniden kullanılmadan önce sıfırlanıyor. GHSA-w8hw-w9fx-j79w

Tablo PHP projesinin ve watchTowr'ın yayımladığı bilgilere dayanıyor. Eski dallar için kaynak kod yaması var ama derlenmiş sürüm yok. Bu, PHP'yi bir cihazın içine gömmüş üreticiler için ayrı bir yük demek. PHP, güvenlik duyurusu, watchTowr, PHP2Shell SSS

Sahadaki sömürüye dair kuruluşların bildirdiği gözlemler farklı. watchTowr, bal küpü ağında 21 Ekim'den itibaren sömürü denemesi gördüğünü söylüyor. Datadog, AWS'nin 17 Ekim gibi erken bir tarihte, yani kamuya açıklanmadan dört gün önce denemeler bildirdiğini aktarıyor. Bitdefender ise 22 Ekim itibarıyla deneme görmediğini yazdı. CISA, 23 Ekim itibarıyla iki CVE'yi de bilinen sömürülen açıklar kataloğuna eklememişti. Bu bildirimler farklı tarihlere ve telemetri kapsamlarına dayanıyor; bir kuruluşun deneme görmemesi diğerinin gözlemini tek başına çürütmüyor. Sömürü denemesi ile başarılı ele geçirmeyi de ayırmak gerekiyor. watchTowr, Datadog Security Labs, Bitdefender

23 Ekim güncellemesi: PHP, sıra dışı bir oturum serileştirme yapılandırmasına ilişkin ek bir yol bildirdi. session.serialize_handler değerinin yapılandırmada php_binary veya php_serialize olup uygulama tarafından çalışma anında php yapılması ve yükleme ilerlemesinin açık kalması gerekiyor. Bu koşullar için session.upload_progress.enabled=0 öneriliyor; konu sonraki olağan sürümde CVE-2026-115560 olarak ele alınacak. Bu ek öneri, yukarıdaki iki açık için güncellemenin yerini tutmuyor. PHP, 23 Ekim ek duyurusu

Siemens ne yaptı?

Siemens ProductCERT 23 Ekim'de SSA-566435'i yayımladı. Belge, çeşitli Siemens yazılım ürünlerinin etkilenme durumunu listeliyor. Sonuç dikkat çekici: listelenen ürünlerin hiçbiri etkilenmiyor ve gerekçe hepsinde aynı, "bileşen mevcut değil". Opcenter Execution Core, Polarion, Teamcenter Active Workspace, Tecnomatix Plant Simulation, Xpedition ailesi ve diğerleri için Siemens, üründe PHP bulunmadığını tek tek beyan ediyor. Siemens ProductCERT, SSA-566435

Etkilenmeyen ürünler listesi neden önemli? Çünkü büyük bir üreticinin, bir dil çalışma zamanındaki açık için ürün envanterini taraması ve "bu yazılımda PHP yok" demesi gerekti. Bu, bizim de yapmamız gereken işin ta kendisi. Bu listedeki ürünlerin etkilenmemesi, diğer üreticilerin veya aynı ürünlerin çevresine eklenen bileşenlerin de PHP içermediği anlamına gelmez. Asıl risk, bu sistemlerin çevresindeki ve envanterde zor görünen bileşenlerde: cihaz konsolları, tedarikçi portalları, eski panolar, üçüncü taraf eklentiler. CISA da PHP'nin varlığının doğrudan gözlemlenemeyebileceğine dikkat çekiyor. Hollanda NCSC'nin takip listesinde 22 Ekim itibarıyla yaklaşık 430 tedarikçiden 635 ürün kayıtlıydı. Engineering.com, PHP2Shell ve üreticiler

OT ortamında PHP nerede saklanır?

Envanter incelemesi kurumsal web sitesiyle sınırlı kalmamalı. Şu sorularla başlayabiliriz:

Bu tablo bir tarama aracının çıktısı değil; envanteri gözden geçirirken kullanabileceğimiz bir sıra. Bulduğumuz her PHP için üç bilgi lazım: sürüm, hangi yolla çalıştığı (mod_php, PHP-FPM, php-cgi ya da başka bir sunucu) ve kimin güncelleyeceği. CISA, web isteği karşılayan her PHP kurulumunu kapsama alıyor. CISA, 21 Ekim 2026 uyarısı

Gömülü cihazlarda durum daha zor. Cihazın içindeki PHP eski bir dalda olabilir; o dal için derlenmiş sürüm yok. Güncellemeyi ancak cihaz üreticisi yeni firmware ile yapabilir. Üretici danışma belgesi yayımlayana kadar uygulanabilecek telafi önlemlerinden biri ağ erişimi: yönetim arayüzüne kimin ulaşabildiğini daraltmak. Siemens'in genel güvenlik tavsiyesi de bu yönde: cihazlara ağ erişimini uygun mekanizmalarla korumak ve endüstriyel güvenlik için işletme kılavuzlarına uymak. Siemens ProductCERT, SSA-566435

Kayıtlarda neye bakabiliriz? Datadog birkaç iz öneriyor: PHP hata günlüğünde "Allowed memory size of ... exhausted" mesajının Unknown on line 0 ile birlikte görünmesi, yani hatanın hazırlık aşamasında oluşması; kısa sürede aynı işçiden gelen bellek hataları; Apache günlüğünde çökme kayıtları; ve en doğrudan belirti olarak, bir web işçisinin kabuk süreci başlatması. İsteklerde ise uygulamanın normalde kullanmadığı PHPSESSID ya da PHP_SESSION_UPLOAD_PROGRESS alan adları, yüzlerce parçalı çok parçalı istekler ve aşırı iç içe alan adları dikkat çekici. Datadog, istek boyutunun tek başına zayıf bir sinyal olduğunu da ekliyor; ayrıştırma, hat üzerindeki boyuttan çok daha fazla bellek ayırabiliyor. Datadog Security Labs

Bu açık neden hatırlanacak?

PHP2Shell'i önemli yapan şey tek bir uygulamadaki hata değil. Bir dilin çalışma zamanının, isteği daha anlamadan güvenilmez duruma düşebilmesi. Uygulama içindeki giriş kontrolü bu hazırlık aşamasını korumaz; PHP’nin önündeki ters vekil veya erişim denetimi ise isteği ayrıştırıcıya ulaşmadan sınırlayabilir. Üstelik PHP'nin kendi danışma belgesi, aynı kalıbın başka yerlerde de bulunabileceğini söylüyor: bir bellek hatası işi yarıda bırakıyor, temizlik yarım kalan durumu geçerli sanıyor. Datadog da benzer hataların daha çıkmasını bekliyor. Datadog Security Labs

OT tarafında bu bize bir şey hatırlatıyor: sahadaki bir cihazın web arayüzü, o cihazın en az düşünülen parçası olabilir. Siemens'in yaptığı gibi ürün ürün sormak gerekiyor. Bizim sormamız gereken soru da aynı:

Sahamızda web arayüzü olan her cihaz ve uygulama için, o arayüzü hangi yazılımın sunduğunu ve kimin güncelleyeceğini biliyor muyuz?

Kaynaklar

• PHP, güvenlik duyurusu ve düzeltilmiş sürümler, 21 Ekim 2026
• GitHub Security Advisory GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• GitHub Security Advisory GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• Siemens ProductCERT, SSA-566435, 23 Ekim 2026
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching, 21 Ekim 2026
• Datadog Security Labs, PHP2Shell: detection, analysis, and remediation
• watchTowr, PHP2Shell FAQ
• Bitdefender, Technical Advisory: PHP2Shell Pre-Auth RCE
• Engineering.com, PHP2Shell: for manufacturers, the danger goes deeper than a website