PHP2Shell (CVE-2026–109618 / CVE-2026–109619): Kapsamlı Teknik Analiz

PHP2Shell, PHP runtime'ındaki iki kritik zafiyetin (CVE-2026–109618, CVE-2026–109619) takma adıdır. PHP security team her ikisini CVSS v4.0 ile 9.2 olarak puanlamış ve unauthenticated remote code execution (RCE) riskine işaret etmiştir. Patch'ler 21 Ekim 2026'da PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 ile yayımlandı. PHP 8.1 ve eski branch'ler için upstream patch yoktur. 21 Ekim sonrası watchTowr ve Cloudflare exploitation attempt'leri gözlemlediğini bildirdi, teyitli bir server compromise henüz raporlanmadı.

Bu yazı Tenable, Cloudflare, Cyber Security News, Brandefense ve The Hacker News kaynaklarını birleştirir. Her iddia, onu aktaran kaynağa atfedilmiştir. Kaynaklarda geçmeyen çıkarımlar "yorum" olarak işaretlenmiştir.

1. Timeline

Discovery Ağustos 2026'da başladı, bilgi 20 Ekim'de leak oldu, patch'ler 21 Ekim'de yayımlandı. Tarihler ilgili ekiplerin kendi anlatımlarına dayanır. (Brandefense, Tenable, The Hacker News).

İki ekibin tarihleri birbirinden bağımsız anlatımlardır. PHP'nin 21 Ekim duyurusu discovererların adını vermez. Discovery sırası bu yüzden kesin hüküm değil, her ekibin kendi beyanı olarak okunmalıdır.

2. Technical anatomy

PHP'nin GitHub advisory'leri iki ayrı bug tanımlar ve her CVE'yi birine eşler. Ortak payda, bir request işlenirken PHP'nin internal state'inin bozulması ve bunun code execution'a çevrilebilmesidir (Brandefense). Changelog'da iki advisory için tek bir core fix görünür: "Avoid state corruption via bailout".

CVE-2026–109618: RCE via OOM corruption

Out-of-memory (OOM) durumu işlenirken PHP, request'e ait internal data kısmen initialize edilmişken kesilebilir. Request cleanup aşaması bu geçersiz veriyi geçerliymiş gibi ele alabilir. GitHub advisory'si tetikleyicilerden biri olarak multipart parsing sorunlarını anar.

CVE-2026–109619: RCE via stale global state

Request'e ait internal state, arkasındaki memory free edildikten sonra da hayatta kalabilir. Aynı worker tarafından işlenen sonraki bir request, normal initialization bu state'i sıfırlamadan önce onu kullanabilir. Advisory iki durumu doğrular:

• PHP 8.5'teki fatal error backtrace path'i
• Bir OOM veya başka bir fatal error sonrasında session upload progress (session.upload_progress)

İkinci madde operasyonel açıdan önemlidir: PHP manual'ine göre session.upload_progress.enabled default olarak açıktır; yani özellik çoğu kurulumda ek bir ayar yapılmadan aktiftir.

Ek etki: worker memory disclosure

The Hacker News'in aktardığına göre bir saldırgan, önce code execution elde etmeden de PHP worker process'inin memory'sini okuyabilir. Bu memory, diğer request'lere ait parolaları, authentication token'larını, API key'leri ve sertifikaları barındırabilir. Araştırmacılar bu okumayı kontrol etmedikleri uygulamalara karşı göstermiştir. Yani etki, PHP'nin üzerindeki application'dan bağımsızdır (The Hacker News).

Yorum: code execution path'i kapalı kalsa bile, sızmış olabilecek secret'ların rotation'ı ayrı bir risk kararı olarak değerlendirilmelidir.

Bağımsız araştırmacı iddiaları (unverified)

Cyber Security News'in aktardığı public bir research repository'si farklı bir anlatım sunar: upload progress handler'ının verilen filename'i validate etmeden session data'ya yazması, POST body'deki session ID'nin session.use_only_cookies kısıtını bypass edebilmesi ve var_destroy destructor'una re-entry ile bir use-after-free durumu (Cyber Security News). Aynı yazı bazı path'lerin ek koşullara (bir local file inclusion açığı, bir application gadget'ı) bağlı olduğunu ve bu iddiaların PHP'nin tam advisorysiyle karşılaştırılana dek independent research claim'i olarak kalması gerektiğini vurgular. Bu yazıda exploit yöntemlerinin ayrıntıları bilerek yeniden üretilmemiştir. Savunma kararlarında PHP'nin kendi advisory'si esas alınmalıdır.

Kodun yaşı, discoverer'lar ve AI'ın rolü

The Hacker News'e göre zafiyetleri Wiz Research, Calif ve OpenAI'nin Codex Security ekibi bulmuş. Fix PHP security team ve Google'ın Gemini ekibiyle birlikte hazırlanmıştır. Sorunlu kod PHP'de on yıldan uzun süredir bulunuyor ve etki, araştırmacıların anlatımıyla PHP 5.4'e kadar neredeyse tüm sürümlere uzanıyor. Bu menzil PHP'nin advisory'sinde belirtilmediği için researcher claim'i olarak okunmalıdır.

Araştırmacılar AI modellerinin bu eski kusurları working exploit'e dönüştürmeyi hızlandırdığını söylüyor. Bir araştırmacı, normalde bir ekibin aylarını alacak işi yaklaşık bir haftada yapmış. Calif ise hedefin tarihçesini (2004 tarihli PHP araştırmasına uzanan kökeni) bilmenin yine de önemli olduğunu, güncel modellerin bu kadar eski ve obscure primitive'lerden kendiliğinden güvenilir biçimde yola çıkmadığını belirtiyor. Yorum: Bu, patch sonrası exploitation window'unun kısalabileceğine dair bir sinyaldir, ölçülmüş bir veri değildir.

3. Affected versions and patch status

PHP'nin advisory'leri, 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 öncesindeki tüm sürümleri affected sayar; web request'i serve eden her installation risk altındadır (Brandefense).

İki nokta önemlidir. Birincisi, eski branch'lerde etkinin ne kadar geriye gittiği PHP advisory'lerinde belirtilmemiştir; CERT-EU'nun "PHP 5 ve sonrası" ve Sansec'in "5.4 ve sonrası" aralıkları PHP tarafından doğrulanmış değildir (Tenable). İkincisi, PHP 8.2'nin support'u 31 Aralık 2026'da biter. Patch'i uyguladıktan sonra bile 8.2 kullanan ekiplerin kısa vadeli bir upgrade planına ihtiyacı vardır.

PHP ayrıca 7.4, 8.0 ve 8.1 için GitHub'da minimal source backport'ları yayımlamıştır. Bunlar source'tan build edenler veya LTS vendor'ı olmayanlar içindir. Önemli bir ayrım. WordPress veya Laravel gibi bir application'ı güncellemek, altındaki PHP runtime'ını güncellemez. Runtime server package'ından, hosting sağlayıcıdan veya container image'ından gelir. Distro package'ları eski görünen bir version string'iyle fix'i taşıyabileceğinden, package changelog'unda CVE numarası aranmalıdır (The Hacker News).

Distro packages

Distro package'ları kendi version numaralarını taşır. Bu yüzden numaraya değil vendor advisory'sine bakılmalıdır. Brandefense'in listelediği fix'ler:

PHP, gönüllülerce maintain edilen rpms.remirepo.net repository'sini kullananlara distro package'larına geçmelerini veya source'tan build etmelerini öneriyor. Orepository'de 21 Ekim'de update bulunmayacaktı.

4. Attack surface and real-world impact

PHP, web request'i serve eden her installation'ı riskli sayar. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil. En yüksek riski mod_php için görür. Orada, application code çalışmadan önce unauthenticated bir request'in saldırıyı tetiklediği gösterilmiş bir exploit vardır (Brandefense).

SAPI nüansları

Calif'in anlatımına göre PHP-FPM path'i application'a bağlıdır: application'ın session gibi bir veriyi decode etmesi ve bu sırada oluşan fatal error'ın, sonraki bir request'in kullanabileceği stale state bırakması gerekir. Apache mod_php'de ise Calif, rastgele PHP script'lerine karşı RCE bildirir. Bu ifadeler discoverer'ların kendi lab sonuçlarıdır. Brandefense bunları doğrulamadığını belirtir.

The Hacker News'e göre sorun engine'de olduğu için basit bir "Hello World" sayfası bile vulnerable sürümde saldırıya açıktır. PHP-FPM, request kurulumun başında fail ettiğinde worker'ı kapattığı için mod_php'den farklı davranır. İki zafiyetten biri için PHP'nin analizi FPM'in susceptible olduğunu destekler ama complete bir FPM exploit'i gösterilmediğini söyler. İkincisinin hem mod_php hem PHP-FPM'de code execution'a ulaştığı gösterilmiştir, ancak FPM path'i çalışan application'ın içindeki bir işleme bağlıdır (The Hacker News). Haberde hangi zafiyetin hangisi olduğu belirtilmediğinden bu ayrımı CVE numarasına bağlamadım.

Session upload progress gibi bir özellik default açık olduğundan, "application code'um güvenli" yaklaşımı yeterli değildir: Sansec'e göre fix, server seviyesinde bir PHP update'idir ve Magento, Shopware, WooCommerce gibi platformların kendi code'undan uygulanamaz.

Exposure estimates

Bu rakamlar metodolojisi farklı, kaba tahminlerdir ve birbirinin yerine kullanılmamalıdır. Ortak mesaj nettir. Versiyonunu açıklayan host'ların yarısından fazlası resmi patch alamayacak branch'lerde.

Observed operational impact

Bazı kuruluşlar bir compromise nedeniyle değil, precaution olarak servislerini kapattı. The Hacker News'e göre BambooHR servisini ABD, Kanada ve İrlanda'da offline aldı, payroll işlemlerinin aksayacağını duyurdu ve restoration süresi vermedi. Hollanda'da MijnOverheid, DigiD, parlamento alt meclisinin sitesi, ulusal siber güvenlik merkezi ve bazı eğitim sistemleri offline oldu (NOS'un aktarımıyla) merkez, zafiyetin abuse edildiğini görmediğini ama herkesi patch'e çağırdığını belirtti.

5. Exploitation status

İncelenen kaynaklarda saldırı trafiği gözlendiğini söyleyen ilk elden beyanlar Cloudflare ve watchTowr'dan gelir. Public PoC'ler dolaşımdadır ve NCSC-NL kısa vadede yaygın exploitation bekliyor. Kaynaklar zaman içinde değiştiği için her ifade sahibine ve zamana atfedilmiştir.

Sonuç olarak: attempt'ler gözleniyor, confirmed compromise henüz raporlanmadı. Risk algısı "bekleniyor"dan "başladı"ya kaymıştır. Ancak tahminler ölçüm değil beklentidir. Public exploit koduna dair bir uyarı da var. Tenable, dolaşımdaki exploit kodunun çalıştığının doğrulanmadığını ve doğrulanmamış kodun malware ile trojanize edilmiş olabileceğini belirtiyor. Test yalnızca izole bir lab'da ve yetkiyle yapılmalıdır.

CVSS discrepancy

PHP security team her iki zafiyeti de CVSS v4.0 ile 9.2 olarak puanlamıştır. watchTowr ve bir Hacker News post'u gibi bazı erken kaynaklar 10.0 demiştir. Tenable bu farkı not etmiş ve PHP advisory'si yayımlandığında yazısını güncelleyeceğini belirtmiştir. The Hacker News de 10.0 iddiasının PHP'ye ait olmadığını vurgular. Bu yazıda PHP'nin resmi skoru olan 9.2 kullanılmıştır.

Historical context

CISA KEV kataloğunda PHP core'a ait üç zafiyet vardır. CVE-2024–4577 (PHP-CGI) ve CVE-2019–11043 (PHP-FPM) ransomware kampanyalarında kullanıldığı bilinenlerdir. CVE-2012–1823 ise CVE-2024–4577'nin sonradan bypass ettiği bir PHP-CGI açığıdır (Tenable).

6. Disclosure breakdown and PHP Foundation's assessment.

The Hacker News'in aktardığına göre coordinated disclosure, release öncesinde dağıldı. 20 Ekim'de yaklaşık 20:00 UTC'de Calif çalışan PoC'sinin videosunu yanlışlıkla paylaştı. 21 Ekim'de 07:41 UTC'de, fix'ten yaklaşık altı saat önce, Chainguard patch içeren image'ları yayımladı. Bu sayede herkes fix'i inceleyebilirken diğer kullanıcılar update için bekliyordu (The Hacker News).

PHP Foundation ayrıca CVE-2026–109618'in dayandığı OOM kusurunun ilk belirtilerinin 2024'teki external audit sırasında bir core developer tarafından görüldüğünü, ancak o dönemde saldırının yalnızca theoretical olduğunu ve code execution path'i bulunamadığını söylüyor. Rakip fix'lerin her biri backward compatibility'yi bozma, denial-of-service (DoS) path'leri açma veya third-party extension'ları değişmeye zorlama riski taşıdığı için küçük bir ekip uzlaşamamış ve çalışma aylarca durmuş. Foundation bu gecikmeyi karar sürecinin ve kaynaklarının "structural failure"ı olarak niteledi; Calif, OpenAI ve Wiz'in 2026 raporları (AI araçlarıyla) tam etkiyi ortaya koyunca fix önceliğe alınmış. Foundation, security decision-making sürecini değiştirdiğini ve benzer sorunları daha erken yakalamak için personel ve tooling eklediğini bildirdi.

Yorum: leak'in yanında patch içeren image'ların erken görünür olması da attacker'lara patch diffing için zaman kazandırmış olabilir. Kaynaklar bunun exploitation'a etkisini ölçmez.

7. Mitigations and workarounds (stopgap only)

Tek eksiksiz çözüm patching'dir. PHP core developer Gina Peter Banyard tek mitigation'ın patch/upgrade olduğunu söylemiş, PHP 8.6 release manager'ı Joe Ferguson ise ini ayarlarının kurtarmayacağını belirtmiştir (Tenable). PHP'nin kendi notu da aşağıdaki adımların yalnızca belirli attack path'lerini daralttığını, kurulumu güvenli yapmadığını söyler (Brandefense). The Hacker News ayrıca, patch öncesinde workaround olarak dolaşan session.upload_progress ayarının hiçbir zaman complete bir fix olmadığının release ile teyit edildiğini aktarır.

Örnek FPM pool config'i (yalnızca geçici önlem, uygulamadan önce kendi ortamınızda test edin):

; php-fpm pool dosyası (ör. www.conf)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[session.upload_progress.enabled] = 0

; php-fpm pool dosyası (ör. www.conf)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[session.upload_progress.enabled] = 0

Bu ayarlar sonrası PHP-FPM veya web server restart edilmelidir. Yorum: memory_limit=-1 resource consumption'ı sınırsız bırakır. Yalnızca patch gelene dek kısa süreli bir stopgap olarak düşünülmelidir. 8.1 ve eski branch'lerde PHP, vendor'dan backport almayı ya da supported bir sürüme geçmeyi söylüyor.

Post-patch configuration review

The Hacker News'e göre fix yeni bir hard memory limit ekler; bu limite ulaşıldığında process sonlanır ve shutdown handler'lar çalışmaz. Bu yüzden update sonrasında memory_limit ve post_max_size değerleri application'ın ihtiyaçlarına göre gözden geçirilmelidir.

8. Cloudflare emergency WAF release

Cloudflare, 21 Ekim'de Managed Ruleset'e anormal request pattern'lerini yakalayan dört kural ekleyen bir emergency release yayımladı. İkisi eşleşen request'leri block ediyor, ikisi yalnızca log'luyor (Cloudflare changelog).

Dördü de yeni detection'dır; eski bir rule ID'ye karşılık gelmez. Changelog girdisi PHP2Shell'i adıyla anmaz. Bağlantı, zamanlamadan ve Cloudflare CTO'su Dane Knecht'in açıklamasından gelir. Knecht, PHP siteleri için bilinen exploit vector'lerine yönelik ilk bir rule set'in deploy edildiğini, kuralların free plan dahil tüm müşterilerde bulunduğunu, early attack'ların görüldüğünü ve mitigation'ların yeni vector'ler çıktıkça güncellendiğini söylemiştir (Tenable). Brandefense, kuralların 21 Ekim'de 03:02 UTC'de, resmi release'ten önce açıldığını ve free plan'lar için managed bir free ruleset bulunduğunu aktarır.

Knecht açıklamayı açıkça "stopgap only" diye çerçeveler ve PHP update'i çıkar çıkmaz patch yapılmasını ister. İki sınır vardır. Kurallar yalnızca Cloudflare üzerinden geçen traffic'i kapsar ve iki kural yalnızca log tuttuğu için, bu kurallarla eşleşen saldırılar block edilmeden geçebilir. Cloudflare arkasındaki ekipler de PHP'yi patch'lemeli, ayrıca Log action'lı kuralların kayıtlarını izlemelidir.

9. Detection and threat hunting

Yayımlanmış bir Indicator of Compromise (IoC) listesi yoktur; Huntress doğrulanmış bir IoC olmadığını, Sansec ise signature listelemediğini belirtir (Brandefense). Bu yüzden pratik sinyal behavior'dır. Bir web server process'inin web server'dan beklenmeyecek bir şey yapması. Araştırmacılar ayrıca exploitation'a özgü bazı telemetry sinyalleri önerir.

MITRE ATT&CK mapping: exploitation T1190 (Exploit Public-Facing Application), yerleştirilen web shell ise T1505.003 (Server Software Component: Web Shell).

Inventory and scanning

Tenable, PHP installation'larını ve unsupported sürümleri bulan şu plugin'leri sunuyor. 48243 (PHP Version Detection), 58987 (PHP Unsupported Version Detection), 200476 (Windows) ve 216936 (Unix) için PHP Scripting Language Installed. CVE'ye özel plugin'ler yayımlandıkça CVE sayfalarında listelenecek.

First response if compromise is suspected

Huntress, server'ı isolate etmeyi ve web server ile PHP log'larını korumayı önerir. Ardından web shell, web root'ta yeni dosyalar, cron job'lar, scheduled task'ler ve yeni hesaplar aranır. Memory disclosure ihtimali nedeniyle (bkz. Bölüm 2), etkilenmiş olabilecek worker'ların işlediği credential, token ve API key'lerin rotation'ı da incident response planına dahil edilmelidir (yorum).

10. Patch rollout plan

PHP, tüm kullanıcıların 8.5.12, 8.4.27, 8.3.36 veya 8.2.35'e hemen update etmesini söylüyor; plandaki version numaraları php.net duyurusundan teyit edilmelidir (Brandefense).

1. Inventory çıkarın. Container'ları, control panel'leri, CMS host'larını ve kendi PHP'sini taşıyan appliance'ları dahil edin; vendor yazılımına gömülü PHP'yi unutmayın.
2. Internet-facing sistemlerle başlayın. Huntress bunu önerir; Sansec ise release'ten dakikalar sonra saldırı bekler.
3. Distro package'ını alın. Distro ve LTS vendor'ları patch'leri önceden aldı; package numaraları kendi şemasını izlediği için vendor advisory'sine ve changelog'daki CVE referansına bakın (bkz. Bölüm 3).
4. Servisi restart edin. PHP-FPM'i veya web server'ı ve long-running PHP worker'larını restart ederek çalışan worker'ların yeni code'u yüklemesini sağlayın. Container kullanıyorsanız image'ı rebuild edip redeploy etmek gerekir (genel pratik, kaynaklarda geçmez).
5. Version'ı yeniden verify edin. Aşağıdaki komutlarla.
6. Memory ayarlarını gözden geçirin. Yeni hard memory limit nedeniyle memory_limit ve post_max_size değerlerini kontrol edin.
7. Retrospective hunt yapın. 20 Ekim'den bu yana log'larda Bölüm 9'daki sinyalleri arayın.

Version ve ayar kontrolü için Brandefense'in verdiği komutlar:

php -v
php -i | grep -i session.upload_progress
php-fpm -v
curl -sI https://www.example.com/ | grep -iE "^(server|x-powered-by):"

php -v
php -i | grep -i session.upload_progress
php-fpm -v
curl -sI https://www.example.com/ | grep -iE "^(server|x-powered-by):"

İki uyarı: CLI binary'si web server'ın kullandığından farklı olabilir; bu yüzden php-fpm -v veya Apache module'ünü de kontrol edin. session.upload_progress için okunan değer CLI'nin php.ini'sine aittir; web server'ın gerçekten yüklediği dosyayı denetleyin (örneğin geçici bir phpinfo() sayfasıyla ve işiniz biter bitmez silerek). Response header'larında version görünmemesi güvende olduğunuz anlamına gelmez; header yalnızca expose_php açıksa çıkar.

Not: Vulnerability check'te exploit traffic göndermeyin. Brandefense'in bilebildiği kadarıyla yayımlanmış güvenli bir test yoktur; yalnızca version ve config kontrol edilmelidir.

11. Conclusion and priority actions

PHP2Shell, bir application library'sindeki değil PHP'nin kendisindeki bir sorundur; bu yüzden remediation application code'uyla değil server seviyesinde update ile gelir. Öncelik sırası:

1. Internet-facing PHP server'larını 8.5.12, 8.4.27, 8.3.36 veya 8.2.35'e (ya da vendor'ın backport package'ına) update edin ve worker'ları restart edin.
2. 8.1 ve eski branch'lerdeki sistemleri tespit edin; vendor'dan backport alın, supported bir branch'e geçin veya isolate edin.
3. Update gecikecekse geçici ayarları ve WAF korumasını uygulayın, ancak bunların complete bir fix olmadığını bilin.
4. 20 Ekim'den bu yana PHP worker'larından shell ve download tool çağrılarını, web root'taki yeni dosyaları, olağandışı multipart request'leri ve scheduled task'leri hunt edin.
5. Memory disclosure riski nedeniyle, vulnerable sürümde çalışmış sistemlerdeki secret'ların rotation'ını değerlendirin (yorum).
6. Brandefense, PHP2Shell'in WordPress core'una ait WP2Shell'den farklı olduğunu vurgular; WordPress siteleri iki ayrı update'e ihtiyaç duyabilir.

Bu yazının yazıldığı anda bazı sorular cevapsızdır: eski branch'lerde etkinin kapsamı belirsiz, yayımlanmış bir IoC yok ve confirmed bir server compromise raporlanmadı. Ancak watchTowr ve Cloudflare exploitation attempt'leri gözlemlediğini bildiriyor. Yeni bilgi geldikçe PHP'nin advisory'leri ve CERT-EU uyarısı primary reference olarak izlenmelidir.

12. Kaynaklar

Bu yazı için açılıp okunan sayfalar:

• Tenable: php2shell (CVE-2026–109618, CVE-2026–109619) FAQ, Satnam Narang, 21 Ekim 2026
• Cloudflare Changelog: WAF Release 2026–10–21 Emergency
• Cyber Security News: PHP2Shell Vulnerability Gets a Public PoC Exploit, Guru Baran, 21 Ekim 2026
• Brandefense: PHP2Shell, CVE-2026–109618 ve CVE-2026–109619, 21 Ekim 2026
• The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge, Swati Khandelwal, 21 Ekim 2026 (sonradan güncellendi)

Yukarıdaki sayfalarda anılan ama burada açılmayan primary source'lar (verification için önerilir): php.net announcement ve release notes, PHP'nin GitHub advisory'leri (GHSA-w8hw-w9fx-j79w ve GHSA-6wmf-4rv5-p3rp), CERT-EU 2026–018, NCSC-NL, Huntress, Sansec, Wiz, Calif, watchTowr, PHP Foundation ve NOS yazıları. Bu sayfalardan yapılan aktarımlar, onları aktaran kaynağa atfedilmiştir.