PHP2Shell | Bellek Güvenliği ve Güvenli Yazılım Mühendisliği

PHP2Shell kapsamında CVE-2026-109618 ve CVE-2026-109619; bellek yaşam döngüsü, OOM, Use-After-Free, PHP SAPI, güvenli yazılım geliştirme, yama doğrulama ve adli bilişim açısından inceleniyor.

Özet

PHP2Shell, PHP çalışma zamanında saptanan ve CVE-2026-109618 ile CVE-2026-109619 olarak kaydedilen iki ilişkili bellek güvenliği açığını ifade eder. Bu çalışma, söz konusu bulguları dönemsel bir güvenlik duyurusunun ötesinde, istek yaşam döngüsü, bellek sahipliği, hata sonrası durum tutarlılığı, HTTP ayrıştırma, süreç izolasyonu, güvenli yazılım geliştirme ve adli bilişim açısından inceler. Birinci açık, bellek tükenmesi esnasında yürütme akışının kesilmesi ile kısmen başlatılmış dahili yapıların temizlenmesi arasındaki uyumsuzluktan; ikinci açık ise istek kapsamlı belleğe ait referansların uzun ömürlü worker durumunda korunmasından kaynaklanır. Uygun koşullarda saldırganın kimlik doğrulaması olmadan kod çalıştırabilmesi, uygulamanın kendi kaynak kodunda hata bulunmasa bile altyapı bağımlılıklarının güvenlik sınırını belirlediğini gösterir. İnceleme, PHP projesinin birincil güvenlik duyuruları, PHP Foundation açıklaması, CERT-EU bülteni, araştırmacı raporları ve güvenli geliştirme literatürünün karşılaştırılmasına dayanır. Doğrudan zafiyet istismarı gerçekleştirilmemiş, deneysel başarı veya kişisel olay müdahalesi iddiasında bulunulmamıştır. [1, 3, 7, 8, 10, 11, 12]

Anahtar kelimeler: PHP2Shell, PHP, CVE-2026-109618, CVE-2026-109619, bellek güvenliği, Use-After-Free, Out-of-Memory, güvenli yazılım geliştirme, tehdit modelleme, adli bilişim, savunma derinliği.

1. Giriş ve Araştırma Yaklaşımı

Uygulama güvenliği çoğu zaman kimlik doğrulama, yetkilendirme, girdi doğrulama, SQL injection veya istemci tarafı betik çalıştırma gibi uygulama katmanındaki konularla açıklanır. Oysa bir web isteğinin işlenmesinde HTTP sunucusu, proxy, sunucu uygulama arayüzü (SAPI), yorumlayıcı, yerel uzantılar, işletim sistemi ve uygulama kodu ortak bir yürütme zincirini oluşturur. Zincirdeki herhangi bir katmanın bellek bütünlüğünü veya durum izolasyonunu kaybetmesi, diğer katmanlar doğru tasarlansa bile güvenlik sınırını etkileyebilir. PHP2Shell bu ilişkiyi gözlemlemeye elverişli bir vakadır.

Bu makalede güvenlik açığının varlığı, kanıtlanmış saldırı önkoşulları, potansiyel etkisi ve savunma seçenekleri ayrı ele alınmaktadır. Teknik anlatımda birincil PHP güvenlik advisories kayıtları temel alınır; araştırma kuruluşlarının deneyleri kaynaklarına atfedilir. Olayın açıklama tarihi ve belirli paket sürümleri, tarihsel bağlam sağlamak amacıyla kaydedilir; makalenin asıl ekseni değişmeyen bellek yönetimi ve güvenli yazılım tasarım ilkeleridir. Her açık için tek bir evrensel istismar yöntemi bulunduğu varsayılmaz; erişilebilir işlem, SAPI, modüller, yapılandırma ve worker ömrü sonucu değiştirir.

Yüksek trafikli ve kritik yazılım sistemleri geliştirme perspektifimden önemsediğim nokta, sistemin normal koşullardaki performansından daha geniştir. Bir işlem beklenmedik biçimde yarım kaldığında, iptal edilen işin belleği, bağlantısı ve geçici durumu bir sonraki iş için güvenli biçimde bırakması gerekir. Performans, kapasite ve gecikme hedefleri ancak bu koşullar altında sürdürülebilir güvenilirliğe dönüşür. Buradaki değerlendirme, yazılım mühendisliği pratiğinden hareket eden kavramsal bir analizdir; PHP2Shell'i kendi üretim ortamımda yaşadığım veya denediğim anlamına gelmez.

2. PHP Çalışma Zamanı ve Güven Sınırları

PHP uygulamaları, sunucu tarafında yorumlanan veya derlenmiş opcode'lar üzerinden çalışan kodlardan ibaret değildir. Zend Engine değerlerin ve nesnelerin temsili, bellek tahsisi, hata yönetimi ve yürütme akışının önemli bir bölümünü üstlenir. PHP'nin Apache mod_php, PHP-FPM, CGI ve diğer SAPI biçimleriyle kullanılması, web isteğinin hangi süreçte başlatıldığına, ne zaman sonlandığına ve sonraki isteğe hangi durumun taşındığına etki eder. Ayrıntılar SAPI'ye özgüdür; aynı PHP sürümünün bütün dağıtımlarda aynı maruziyete sahip olduğu söylenemez. [10, 11]

Bir HTTP isteği uygulama koduna ulaşmadan önce başlık, gövde, form alanı, dosya yükleme ve oturum bilgisi gibi veriler ayrıştırılabilir. Bu nedenle yalnızca uygulama yönlendiricisinde yapılan doğrulama, daha erken evrelerde çalışan yorumlayıcı bileşenlerindeki bütün kusurlara karşı koruma sağlayamaz. PHP2Shell için kaynaklarda belirtilen önemli özelliklerden biri, mod_php üzerinde uygulama koduna erişilmeden tetiklenebilen saldırı yolunun doğrulanmış olmasıdır. Başka SAPI'lerde aynı varsayımı yapmak yerine ilgili resmî duyuruda doğrulanmış koşulları esas almak gerekir. [10]

İstek belleği ile worker ömrünün ayrılması temel bir tasarım ayrıntısıdır. İstek sona erdiğinde isteğe ait tahsisler serbest bırakılabilir; worker ise yeni istekleri karşılamaya devam edebilir. Kalıcı worker durumu içinde önceki isteğin belleğini gösteren bir adres bulunursa yaşam süreleri arasındaki sözleşme bozulur. Bu sözleşme ancak temizleme sırası, başlatma sırası, hata dalları ve uzantı davranışları birlikte incelenerek doğrulanabilir.

3. Bellek Sahipliği, Başlatma ve Yaşam Döngüsü

Bellek güvenliğinde bir kaynağın kimin tarafından oluşturulduğu, hangi işlem boyunca geçerli olduğu ve kimin tarafından serbest bırakıldığı açık olmalıdır. Bellek tahsisi sırasında başarısızlık meydana geldiğinde yarım başlatılmış bir nesnenin temizlenmesi, başarıyla oluşturulmuş bir nesnenin temizlenmesiyle aynı işlem değildir. Başlatıldı bilgisi, sahiplik durumu ve serbest bırakma kararı birbirinden bağımsız yürütülüyorsa kaynak yöneticisi geçersiz bir durumu güvenilir kabul edebilir.

Use-After-Free (UAF), serbest bırakılmış belleğin daha sonra okunması, yazılması veya başka bir işlemde kullanılmasıdır. MITRE'nin CWE-416 tanımı bu sınıfın veri ifşasına, süreç çökmesine, bellek bütünlüğünün bozulmasına veya bazı koşullarda kod çalıştırılmasına yol açabileceğini açıklar. UAF, her zaman RCE ile eşanlamlı değildir. Gerçek etki, boşa çıkarılan alanın yeniden nasıl kullanıldığına, erişim biçimine, bellek düzenine ve yürütme denetimi kazanma olasılığına bağlıdır. [5]

Bellek tükenmesi (Out-of-Memory, OOM) ise bir güvenlik açığı tanımı değil, sistemin veya uygulamanın bellek isteğini karşılayamadığı bir koşuldur. OOM yönetimi hatalıysa olağan kaynak sınırlama işlevi bellek bozulmasının tetikleyicisine dönüşebilir. memory_limit, post_max_size ve işletim sistemi bellek sınırları farklı katmanlara aittir; bu sınırlar aynı işi yapmaz. Özellikle bir sınırı kaldırmanın kaynak güvenliğini otomatik artıracağı düşünülmemelidir. [10]

Güvenli tasarımın önemli bir invarianti şu biçimde ifade edilebilir: Bir isteğin belleği serbest bırakılmadan önce, bu belleğe ait geçersizleşecek bütün kalıcı referanslar sıfırlanmış veya erişilemez duruma getirilmiş olmalıdır. Buna paralel ikinci invariant, başlatılması tamamlanmamış bir yapının tamamen başlatılmış gibi temizlenmemesidir. PHP2Shell, bu iki koşulun farklı hata yollarında nasıl bozulabileceğini göstermektedir.

4. CVE-2026-109618: Bellek Tükenmesi ve Kontrol Akışı

CVE-2026-109618, PHP'nin bellek limitine erişildiğinde kullanılan erken çıkış mekanizması ile kısmen hazırlanmış dahili veri yapılarını kapsayan temizleme kodu arasındaki tutarsızlığa dayanır. PHP, belirli koşullarda bellek limitinin aşılmasını longjmp() aracılığıyla mevcut yürütme bağlamından çıkarak işler. Böyle bir sıçrama, normal işlev dönüşünü ve ara adımları atlayabilir. Özellikle HTTP form verisinin ayrıştırılması sırasında bazı alanlar henüz güvenli bir duruma getirilmemişse temizleme aşaması bunları geçerli kabul edebilir. [10]

Saldırı açısından kritik olan yalnızca büyük bir istek gönderilmesi değildir. İsteğin yürütme zamanlaması, bellek basıncının hangi dahili işleme denk geldiği ve temizleme kodunun hangi durumla karşılaştığı önemlidir. Bellek tahsisi başarısızlığının tam olarak hangi aşamada gerçekleştiği, veri yapısının hangi alanlarının geçerli olduğunu değiştirir. Önceki tahsislerden kalan baytların daha sonra semantik alanlar olarak yorumlanması bellek bütünlüğü üzerinde etkili olabilir. Güvenlik duyurusunda belirli koşullarda kimlik doğrulama gerektirmeyen RCE doğrulaması belirtilmiştir; her konfigürasyon için aynı güvenilirlik düzeyinde sonuç bulunduğu ileri sürülmez. [10]

Kavramsal yürütme dizisi şöyledir: HTTP girdisi ayrıştırılır; dahili nesne oluşturulmaya başlanır; bellek sınırına ulaşılır; hata yolu normal başlatma adımlarından çıkar; istek temizleme aşaması eksik durumu ele alır. Bu dizide güvenlik sınırı son adımda görünür olsa da kök neden, hata akışının bütün ara durumlarla uyumlu tanımlanmamış olmasıdır.

Düzeltme, yönetilebilir OOM durumunda sonraki güvenli VM noktasında devreye giren ertelenmiş bir soft OOM yaklaşımı ve daha yüksek bellek sınırında süreci sonlandıran hard OOM yaklaşımı içerir. Böylece longjmp() ile hazırlığı yarıda kalan bir alandan kontrolün koparılması sorunu giderilirken PHP'nin bellek kullanımını sınırlandırma özelliği korunur. Güvenlik düzeltmesinin yalnızca hata mesajını gizlemekle değil, kontrol akışını değiştirmekle ilgili olması dikkat çekicidir. [10]

5. CVE-2026-109619: Kalıcı Global Durum ve Use-After-Free

CVE-2026-109619, hata, oturum, nesne veya uzantı bilgisi gibi global durumun kalıcı worker içerisinde saklanması ile söz konusu bilginin bağlı olduğu istek belleğinin ömrü arasındaki uyumsuzluğu ele alır. İstek tamamlandıktan sonra bellek serbest bırakılırken worker alanında eski referans kalabilir. Sonraki istek, normal başlatma adımları bu alanı yenilemeden önce bir hata, tanılama veya oturum işlemi yaparsa geçersiz referansa erişebilir. [11]

PHP güvenlik açıklaması, istismarı iki ayrı görev olarak tarif eder: önceki istekten sonraki isteğe yanlış biçimde durum taşıyan producer ve sonraki istekte söz konusu durumu kullanan consumer. Aynı worker tarafından işlenen istekler arasındaki bu ilişki, sıradan tek-istek güvenlik incelemesinin kaçırabileceği bir tehlikedir. fatal error, zaman aşımı veya bellek tükenmesi gibi istisnai yollar durum sıfırlama işleminden önce yürütmeyi durdurabilir; kapanış esnasındaki bazı tanılama işlemleri daha önce temizlenmiş durum alanını yeniden doldurabilir. [11]

Bu güvenlik açığında iki isteğin aynı worker'a denk gelmesi belirli istismar yollarının önkoşuludur. Ancak bu durum her PHP dağıtımında aynı sıklıkta veya aynı doğrulama düzeyinde gerçekleşmez. PHP-FPM, mod_php ve diğer SAPI türleri için tedarikçi duyurusundaki doğrulanmış sınırlamalar dikkate alınmalıdır. Hatanın güvenlikle ilişkili olması için uygulamanın açıkça önceki isteğe ait bir işaretçiyi kullanması gerekmez; runtime'ın kendi dahili global alanı yeterli olabilir.

Güvenli yazılım mühendisliği bakımından burada temel sorun, logical ownership ile physical lifetime arasındaki ayrımdır. Bir durum nesnesi mantıksal olarak isteğe aitse, uzun ömürlü yürütme bağlamında saklanması açık bir sahiplik aktarımı veya geçerli kopyalama olmadan güvenli değildir. Yeniden kullanılan iş parçacığı, nesne havuzu, bağlantı havuzu ve asenkron görev ortamlarında da bu ilke geçerlidir; ancak bu benzetmelerin PHP'deki aynı bellek açığını birebir oluşturduğu iddia edilmemelidir.

6. İki Güvenlik Açığının Birlikte Okunması

İlk CVE'nin odak noktası, hata anında yarım kalmış durumun aynı isteğin temizlenmesinde işlenmesidir. İkinci CVE'nin odak noktası, isteğin ömrünü aşan bir referansın sonraki istekte yeniden kullanılmasıdır. Her iki örnekte de hata sonrası çalışma zamanı durumu, normal durumda geçerli kabul edilen varsayımları ihlal etmektedir. Bu ortak özellik, sorunun tek bir HTTP parametresine veya tek bir içerik yönetim sistemine indirgenemeyeceğini gösterir.

Bu bulgular üzerinden bellek bütünlüğü, gizlilik ve kullanılabilirlik ayrımı yapılmalıdır. Yanlış serbest bırakma süreç çökmesine; istekler arası geçersiz referanslar istenmeyen bellek ifşasına; uygun bellek düzeni ve erişim özellikleri ise daha ağır yürütme etkilerine yol açabilir. Bununla birlikte bir bellek kusurunun varlığı otomatik olarak belirli bir RCE zincirinin her hedefte çalışacağını kanıtlamaz. Bileşen sürümü, çalışma modu, eklentiler ve bellek davranışı sonuç üzerinde belirleyicidir. [7, 10, 11]

CWE eşleştirmeleri olayın nedenini sınıflandırmada yararlıdır; fakat tanımlama ile kanıt birbirinden ayrılmalıdır. CWE-416, serbest bırakılmış belleğin kullanımını açıklar. Kısmen başlatılmış nesnelerin güvenli olmayan temizlenmesi ise tahsis ve başlatma sözleşmesi açısından ayrıca incelenmelidir. Güvenli kod incelemelerinde yalnızca adlandırılmış CVE'lere odaklanmak yerine, bütün hata yollarını kapsayan durum makinesi oluşturmak daha genellenebilir bir yöntemdir.

7. HTTP Ayrıştırma, Dosya Yükleme ve Saldırı Yüzeyi

Bir web uygulamasının saldırı yüzeyi, URL yönlendiricisi veya API denetleyicisi ile başlamaz. HTTP mesajının boyut sınırları, gövde ayrıştırıcısı, multipart/form-data işleme, dosya yükleme alanları, oturum başlatma ve çalışma zamanının erken tanılama yolları uygulama kodundan önce veya onun dışında çalışabilir. PHP2Shell için bu evreler özellikle önemlidir. PHP güvenlik duyuruları, istek gövdesi boyutlarının ve ayrıştırma karmaşıklığının sınırlanmasını geçici risk azaltma bağlamında ele alır. [10, 11]

Savunmada yalnızca Content-Length değerini kontrol etmek yeterli bir varsayım değildir; proxy ve sunucu katmanları aktarımın çözülmüş gövdesini, alan sayısını, form parçası sayısını ve iç içe geçme sınırlarını uygun biçimde denetlemelidir. Yükleme gerektirmeyen uygulamalarda bu işlevin erken katmanda kapatılması saldırı yüzeyini daraltabilir. Bununla birlikte uygulamaya gelen HTTP isteğinin geçerli biçimde sınırlandırılması, runtime içindeki bütün bellek güvenliği kusurlarının giderildiği anlamına gelmez.

Web güvenliğine ilişkin savunma kontrolleri de katmanlara ayrılmalıdır: kimlik doğrulama ve yetkilendirme iş mantığını korur; sunucu/proxy istek kaynaklarını sınırlar; runtime düzeltmesi bellek bütünlüğünü onarır; işletim sistemi izolasyonu hasar alanını sınırlar. Bu kontroller birbirinin yerine geçmez; doğru yerde ve doğrulanmış önkoşullarla uygulanmaları gerekir.

8. Çalışma Ortamları, SAPI ve Uygulama Ekosistemi

PHP güvenlik ekibi, Apache mod_php dağıtımını yüksek riskli koşullar arasında değerlendirir. mod_php üzerinde uygulama kodu çalışmadan önce tetiklenebilen yol doğrulanmıştır. PHP-FPM için risk yoktur demek de teknik olarak yanlıştır; belirli koşullarda uygulama çalışması ve worker yeniden kullanımı ile ilişkili senaryolar bulunmaktadır. php-cgi, FrankenPHP ve LiteSpeed/LSAPI açısından kaynak analizi veya çalışma ortamına özgü gözlemler yer alsa da bütün istismar biçimlerinin eşdeğer şekilde deneysel olarak kanıtlandığı varsayılmamalıdır. [10, 11]

WordPress, Drupal ve Joomla gibi içerik yönetim sistemlerinde gösterilen saldırı senaryoları, söz konusu ürünlerin kendi uygulama kodlarının bu CVE'lere neden olduğu anlamına gelmez. PHP runtime bağımlılığı taşıyan herhangi bir uygulama aynı sınıftaki kusurdan etkilenebilir. Buna karşılık belirli bir sürüm ve dağıtım için hangi saldırı yolunun erişilebilir olduğu ayrıca incelenmelidir. Üretici duyurusundaki “etkilenen sürüm” bilgisi, “bütün dağıtımlarda tek adımlı RCE” iddiasıyla eşitlenemez.

Ortam envanterinde yalnızca web sunucusunun adı değil, PHP binary'sinin kaynağı, SAPI çeşidi, etkin uzantılar, çalıştırılan servis kullanıcıları, birden fazla sürümün birlikte bulunması, konteyner tabanlı dağıtımlar ve uygulamaların hangi worker havuzuna bağlandığı belgelenmelidir. Bir ana makinedeki komut satırı PHP sürümü, web trafiğinin kullandığı PHP-FPM sürümünü her zaman temsil etmez.

9. Sürüm Yönetimi ve Güvenlik Düzeltmelerinin Doğrulanması

PHP geliştirme ekibi 21 Ekim 2026 tarihinde güvenlik düzeltmesini PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerinde yayımlamıştır. Bu sürümler, olayın tarihsel düzeltme referanslarıdır; sonraki tarihlerdeki kurulumlar için ilgili dalın en son desteklenen güvenlik sürümü esas alınmalıdır. PHP 8.1 ve daha eski dallar için upstream destek durumu ile dağıtım/LTS tedarikçisinin backport politikası ayrı değerlendirilmelidir. [7, 8, 10, 11]

Güvenlik güncellemelerinin doğrulanması, yalnızca php -v çıktısına bakmaktan ibaret değildir. Dağıtım paketleri upstream numarayı koruyarak güvenlik yamalarını geriye taşıyabilir. Canonical'ın USN-8948-1 bülteni, belirli Ubuntu sürümlerinde upstream ile farklı görünen fakat güvenlik düzeltmesini içeren paket sürümlerinin somut örneğidir. Böyle bir kurulumda upstream sürüm kıyaslaması tek başına yanlış negatif üretebilir. [2]

Güncellemenin operasyonel kabul ölçütü açıkça tanımlanmalıdır: ilgili varlığın belirlenmesi, düzeltmenin tedarikçi bülteniyle eşleştirilmesi, kurulu paket ile çalışan prosesin aynı dağıtımı kullandığının doğrulanması, gerekli worker yeniden başlatmasının yapılması, işlevsel testlerin tamamlanması ve yeni çalışan süreçlerin doğrulanması. Birden fazla uygulamanın ortak PHP-FPM havuzunu kullandığı ortamlarda değişikliğin kapsamı da ortak altyapı üzerinden değerlendirilmelidir.

Güncellemeden önce ölçülen throughput ve P95/P99 gecikmeleri, güncellemeden sonraki sonuçlarla karşılaştırılabilir. Ancak düzeltmenin performans üzerinde kesin yüzdelik bir etkisi olduğu iddiası, hedef ortamdaki kontrollü benchmark olmaksızın yazılmamalıdır. Kapasite planlaması doğruluk, güvenlik ve gecikmeyi birlikte ele almalıdır.

10. Geçici Kontroller ve Savunma Derinliği

Resmî PHP duyuruları, güncellemenin tek tam çözüm olduğunu özellikle vurgular. memory_limit=-1 değerinin idari seviyede zorunlu tutulması belirli kontrollü OOM yolunu zorlaştırabilir, fakat işletim sistemi veya tahsis katmanında gerçek bellek yetersizliği yine oluşabilir. Sınırsız istek belleği ayrıca servis kullanılabilirliği açısından risk taşır. Bu nedenle böyle bir geçici ayar kapasite sınırı, süreç izolasyonu ve kaynak kullanım kontrolü olmadan kalıcı politika olarak önerilmemelidir. [10]

session.upload_progress.enabled=0 ve PHP 8.5 için fatal_error_backtraces=0 gibi kontrollerin etkisi, doğrulanmış belirli yollarla sınırlıdır. Ayarın hangi yapılandırma katmanında uygulandığı ve worker'ların yeniden başlatılıp başlatılmadığı önemlidir. Uygulama başladıktan sonra yapılan ayar değişiklikleri, daha erken ayrıştırma veya başlatma aşamalarını güvenceye almaz. Geçersiz veya deprecated INI tanımlarını yalnızca uyarıları gizleyerek yönetmek de sorunu çözmez. [11]

Reverse proxy ve WAF kullanımı bilinen anormallikleri durdurabilir, fakat runtime düzeltmesinin eşdeğeri değildir. Cloudflare'ın PHP2Shell sürecinde duyurduğu bütün işlem bağlamını kullanan tespit yaklaşımı, HTTP isteği ile yanıtını birlikte değerlendiren savunma örneğidir. Buna rağmen yanıtın engellenmesi, origin sunucuda daha önce gerçekleşmiş olabilecek yan etkileri otomatik geri almaz. Ağ çevresi, süreç sınırı, ayrıcalık sınırı ve yama yönetimi birbirini tamamlayan kontrollerdir. [4]

Yüksek trafikli uygulamalarda her istekten sonra worker yeniden yaratmak, bazı istekler arası koşulları zorlaştırsa da süreç açılış maliyetini artırabilir ve kapasiteyi düşürebilir. Bu tür bir yöntem birincil güvenlik çözümü gibi sunulmamalı; hedef ortamda ölçüm ve risk değerlendirmesi yapılmadan üretime alınmamalıdır. İleriye dönük ilke, zafiyetin kapatılmasını işletim davranışını bozabilecek geçici mimari değişikliklerinden ayırmaktır.

11. Güvenli Yazılım Geliştirme Yaşam Döngüsüne Çıkarımlar

Güvenli yazılım geliştirme, uygulama girişlerinde doğrulama yapılmasıyla sınırlandırılamaz. Tasarım aşamasında kaynak sahipliği, bileşen sınırı, kötüye kullanılabilir hata yolları, ayrıcalıklar ve arızadan sonra sistemin hangi duruma döneceği belirlenmelidir. PHP2Shell, özellikle bellek tükenmesi, iptal ve yeniden başlatma gibi olağan dışı koşulların tasarım sözleşmesinin bir parçası olması gerektiğini gösterir.

Kod incelemesinde yalnızca başarılı yürütme akışını izlemek yerine şu sorular önem taşır: Bir tahsis başarısız olursa nesnenin hangi alanları başlatılmıştır? Cleanup hangi alanların geçerli olduğunu nasıl bilir? Fatal error nedeniyle atlanan finally veya cleanup karşılığı hangi katmanda tamamlanır? Eski durumu kullanan bir sonraki istek var mıdır? Bir uzantı tarafından sonlandırma evresinde yazılan global alan bir sonraki istekte okunabilir mi? Bu soruların yanıtları uygulanabilir bir durum ve sahiplik modeli oluşturur.

Test stratejisi statik analiz, dinamik analiz, AddressSanitizer gibi bellek denetleyicileri, bellek tahsisi başarısızlığı enjeksiyonu, property-based testler, fuzzing ve farklı SAPI kombinasyonlarında regresyon testlerini birlikte içermelidir. Fuzzing'in yalnızca geçersiz girdileri değil, bellek limitleri ve farklı hata sıraları altında tekrarlanan istekleri de ele alması yararlıdır. Her araç yalnızca belirli tür hataları görünür kılar; hiçbir tekil araç tam güvenlik kanıtı sağlamaz. [5]

Güvenli geliştirme literatüründeki tehdit modelleme yaklaşımı burada da geçerlidir. Varlıklar, güven sınırları, saldırganın kontrol ettiği girdiler ve ayrıcalıklı yürütme katmanları ayrıştırılmalıdır. Web uygulamasının doğru şekilde parameterized SQL kullanması, Zend Engine'deki bir UAF için çözüm değildir; ancak veritabanı güvenliği farklı bir saldırı yüzeyini kontrol etmeyi sürdürür. Bu katmansal ilişki Güvenli Yazılım Mühendisliği: Tehdit Modelinden Sızma Testine Uygulamalı Siber Güvenlik ve Siber Güvenlik Mühendisliği ders notlarıyla birlikte incelenebilir.

12. Performans, Kapasite ve Deterministik Davranış

Yüksek hacimli sistemlerde güvenlik kontrolünün gerçek değeri, erişilebilirliği göz ardı etmeden ölçülebilir olmasına bağlıdır. Bellek sınırı, worker sayısı, istek büyüklüğü, kuyruğa alma ve geri basınç (backpressure) birlikte değerlendirilir. memory_limit gibi bir uygulama sınırı ile cgroup veya konteyner bellek sınırı farklı arıza davranışları üretir. Bir sınırı kaldırmak bellek güvenliği açığına ait belirli yolu daraltabilirken kaynak tükenmesi riskini büyütebilir.

Kapasite açısından risk, yalnızca ortalama gecikme değildir. Bellek baskısının worker çökmesine, yeniden başlamaya ve havuz kapasitesinin aniden azalmasına neden olduğu durumda kuyruk süreleri ve P99 gecikmeleri keskin biçimde yükselebilir. Bu nedenle servis kullanılabilirliği, kaynak izolasyonu ve güvenli hata sonlandırma aynı deney düzeninde sınanmalıdır. Özellikle üst sistemler ve bağımlılıklar arasında zincirleme etkilerin ölçülmesi, tek bileşende yapılan optimizasyonun gerçek sistem üzerindeki karşılığını gösterir.

Buradan çıkardığım sistem mühendisliği ilkesi şudur: Hata yolunun güvenli olması, performansın karşıtı değildir; sürdürülebilir performansın önkoşullarından biridir. Bellek veya zaman aşımı sırasında deterministik olarak temizlenen bir işlem, sonraki isteğin güvenilirliğini korur. Kesintiye uğramış işin geride bıraktığı belirsiz durum ise düşük olasılıklı görünse bile yüksek ölçeklerde tekrar eden bir operasyonel riske dönüşebilir. Bu görüş, PHP2Shell'in belgelenmiş davranışından üretilen mühendislik değerlendirmesidir; ölçülmüş saha verisi olarak sunulmamaktadır.

İlgili teorik temel için İşletim Sistemleri: Süreç, Bellek, Dosya ve Giriş Çıkış ve Red Hat Enterprise Linux Sistem Yönetimi ders notları, süreç/bellek izolasyonu ve güvenli dağıtım bağlamını tamamlar.

13. Adli Bilişim ve Olay Müdahalesi

PHP çalışma zamanı düzeyinde olası istismarların araştırılması yalnızca uygulama denetleyicisinin loglarına dayanamaz. HTTP isteğinin uygulama kodundan önce ayrıştırılması, kimi önemli olayların uygulama logu oluşmadan gerçekleşebilmesine neden olabilir. Bu durumda reverse proxy erişim kayıtları, web sunucusu hata kayıtları, PHP-FPM veya Apache süreç kayıtları, systemd olayları, bellek baskısı ve OOM olayları, süreç yeniden başlatmaları, dosya bütünlüğü, ağ bağlantıları ve dağıtım değişiklik geçmişi birlikte ele alınmalıdır.

Örnek araştırma hipotezleri arasında belirli bir zaman aralığındaki sıra dışı çok parçalı HTTP istekleri, bellek sınırı hataları, 5xx yanıt yoğunluğu, beklenmedik worker yaşam döngüsü değişimleri veya önceki isteğe bağlı anormal oturum davranışları yer alabilir. Bunların hiçbiri tek başına istismar kanıtı değildir. Olası web tarayıcıları, yük testi sistemleri, meşru dosya yüklemeleri ve olağan servis hataları karşılaştırma kümesine dâhil edilmelidir. Şüpheli artefaktlar kanıt zinciri ve zaman bütünlüğü korunarak toplanmalıdır. [3, 4, 12]

Müdahale sırasında önce etkilenen varlık ve sürümler belirlenir, mümkünse olayla ilişkili log ve sistem durumu korunur, hizmetin riskine uygun izolasyon gerçekleştirilir, güvenlik düzeltmesi uygulanır ve sonrasında geçmişteki olası yetkisiz etkiler araştırılır. Yama uygulanmış olması daha önce bir ihlal yaşanmadığını kanıtlamaz. Aynı şekilde bellek hatası ya da HTTP 500 görülmesi de saldırının gerçekleştiğini tek başına kanıtlamaz.

Adli bilişimde ayrılması gereken üç düzey vardır: doğrudan elde edilen bulgu, bulgudan çıkarılan teknik yorum ve alternatif açıklamalar. Güvenilir bir sonuç için üçü ayrı raporlanmalıdır. Bu yaklaşım, olay hakkında doğrulanmamış başarı sayıları veya saldırgan kimliği üretmekten daha değerlidir.

14. Keşif, Yapay Zekâ Destekli Analiz ve Sorumlu Açıklama

PHP Foundation açıklamasına göre kök nedenle bağlantılı bulgular 2024 yılındaki güvenlik çalışmalarına uzanmaktadır. 2026'da Calif, OpenAI ve Wiz araştırmacıları farklı tarihlerde bulgu ve istismar edilebilirlik analizlerini PHP güvenlik ekibine iletti. 21 Ekim 2026'da dört desteklenen PHP dalı için güvenlik düzeltmeleri duyuruldu. Araştırmacıların bağımsız katkıları, yıllardır bilinen bir hata sınıfının farklı koşullarda nasıl kritik bir etkiye dönüşebileceğini gösterir. [7, 12]

Yapay zekâ destekli araştırmanın rolü, kodun büyük bölümünü tarama, olası ilişkileri belirleme, hata koşulları için hipotez üretme ve teknik kanıtların değerlendirilmesini hızlandırma olarak ele alınmalıdır. PHP Foundation, doğrulama ve düzeltme kararlarında insan uzmanların sorumluluğunun sürdüğünü açıklamıştır. Buradan “yapay zekâ tek başına bütün açıkları bulur” ya da “insan analizi gereksizdir” gibi bir sonuç çıkarılamaz. Zafiyet araştırmasında keşif, yeniden üretim, istismar kabiliyeti değerlendirmesi, düzeltme tasarımı ve regresyon doğrulaması farklı aşamalardır.

Koordineli açıklama süreci de mühendislik problemidir. Güvenlik düzeltmesinin varlığı, dağıtıcıların paket hazırlayabilmesi ve kullanıcıların güncellemeye erişebilmesi arasında zamanlama ilişkisi bulunur. Erken bilgi yayılımı saldırı yüzeyini açığa çıkarabilir; aşırı gecikme savunmayı erteleyebilir. PHP Foundation'ın açıklaması, sızıntı ve ambargo sorunlarının bu dengeye etkisini kayda geçirir. Bu olay, açık kaynak güvenlik mühendisliğinin yalnızca kod üretimi değil, sürdürülebilir bakım, iletişim ve tedarikçi koordinasyonu olduğunu gösterir. [7]

15. Güvenlik Riskinin Ölçülmesi ve Akademik Sınırlılıklar

CVSS puanı, teknik zafiyetin belirli ölçütlerle ifade edilen şiddetini gösterir; belirli kurumda gerçekten istismar edildiğinin kanıtı değildir. PHP2Shell için PHP projesinin duyurduğu 9,2 CVSS v4.0 skoru, kuruma özgü varlık kritikliği, ağ erişilebilirliği, dağıtım sürümü veya tedarikçi backport durumu ile birlikte değerlendirilmelidir. Farklı tedarikçilerin başka CVSS sürümleri kullanması sonuçların doğrudan karşılaştırılmasını sınırlar. [10, 11]

PHP kullanım yaygınlığına ilişkin toplu web istatistikleri de aynı hassasiyetle yorumlanmalıdır. Bir teknolojiye ait kullanım oranı, bütün bu sitelerin açığa karşı savunmasız olduğu veya ele geçirildiği anlamına gelmez. Benzer biçimde honeypot ağlarında istismar teşebbüsü görülmesi, başarılı saldırı sayısını veya hedeflerin bütünlüğünü kanıtlamaz. PHP2Shell araştırmalarında bazı SAPI yolları deneysel olarak gösterilirken diğerleri kaynak analiziyle olası kabul edilmiştir; bu iki kanıt sınıfı ayrı tutulmalıdır. [3, 10, 12]

Bu çalışma bir kod yaması denetimi, kontrollü laboratuvar istismarı, üretim telemetrisi ölçümü veya özgün istismar araştırması değildir. Kaynaklara dayalı bir teknik sentez ve güvenli sistem mühendisliği değerlendirmesidir. Doğrudan doğrulanmış bulgular ile bu bulgulardan çıkarılan tasarım ilkeleri metin içinde ayrılmıştır. Gelecekteki güvenlik sürümleri belirli sayısal bilgileri güncelleyebilir; buna karşılık bellek sahipliği, hata yolları ve yaşam döngüsü ilkeleri güncelliğini korur.

16. Mühendislik Değerlendirmesi ve Sonuç

PHP2Shell'in kalıcı önemi, iki CVE tanımının tarihsel öneminden fazladır. Sistem, hata oluşmadığı durumda doğru çalışabilir; fakat beklenmedik kontrol akışında başlatma, temizleme veya durum sıfırlama yükümlülüklerinden biri ihlal ediliyorsa güvenlik sınırı kaybolur. Bu durum web sunucusu, yüksek trafikli servis, mesaj işleyici ve kalıcı worker mimarileri için geniş bir ders niteliğindedir.

Kritik yazılım geliştirme pratiği açısından değerlendirdiğim üç ilke öne çıkmaktadır. Birincisi, kaynak yaşam döngüsü normal ve istisnai yollar için birlikte tasarlanmalıdır. İkincisi, süreç veya worker yeniden kullanımı yalnızca kapasite kazancı olarak değil, durum izolasyonu sözleşmesi olarak incelenmelidir. Üçüncüsü, güvenlik güncellemesinin tamamlanmış sayılması için çalışan bileşenin gerçekten düzeltilmiş olduğunun doğrulanması gerekir. Bu ilkeler performans mühendisliği ile güvenli yazılım geliştirme arasında doğrudan ilişki kurar.

Sonuç olarak PHP2Shell, güvenlik sınırının yalnızca uygulamanın yazıldığı satırlarda değil, çalışma zamanının bellek sahipliği kurallarında, HTTP işleme sıralamasında, iş parçacığı veya worker yaşam döngüsünde ve işletim sisteminin kaynak izolasyonunda da kurulduğunu gösterir. Güvenli sistemler, normal akışta doğru çıktı üretmek kadar, hata sonrasında güvenli bir duruma geçme yükümlülüğüyle değerlendirilmelidir.