PHP2Shell: PHP'nin Çekirdeğindeki İki Kritik Açık

PHP ekibi 21 Ekim 2026'da, yorumlayıcının kendisini hedef alan ve kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya imkan veren iki kritik açığı kapatan acil bir güncelleme yayımladı. Açıkların varlığı resmi duyurudan önce sızdı, ilk saldırı denemeleri de yama henüz çıkmadan görülmeye başlandı. Bu yazıda ne olduğunu, kimlerin risk altında olduğunu ve bugün atılması gereken adımları bir arada topladık.

Bir sızıntıyla başlayan hafta

20 Ekim'de Hacker News forumunda paylaşılan kısa bir gönderi, PHP'de CVSS 10.0 puanlı iki uzaktan kod çalıştırma açığının birkaç gün içinde duyurulacağını iddia ediyordu. Gönderiyi paylaşan kişi elinde somut bir kanıt olmadığını kendisi de yazmıştı ve paylaşım kısa sürede kaldırıldı. Ama ekran görüntüleri çoktan elden ele dolaşıyordu. Ardından güvenlik firması watchTowr, bilgilerin gerçek olduğunu ve açıkların ambargo altında bulunduğunu doğruladı.

Sızan bilgilerde iki CVE numarası (CVE-2026-109618 ve CVE-2026-109619), bir puan ve bir tarih vardı. Açıkların nasıl çalıştığına dair teknik bir ayrıntı ise yoktu. Ambargonun normalde 22 Ekim Perşembe günü kalkması planlanıyordu. PHP güvenlik ekibi aynı akşam 19:33 UTC'de php.announce listesine bir ön bildirim gönderdi ve güncellemeyi bir gün öne çekerek 21 Ekim 14:00 UTC'ye (TSİ 17:00) planladı. Duyuruda iki açığın da CVSS v4.0 ölçeğinde 9.2 puanla kritik olduğu, ayrıntılar kamuya açılırsa ya da aktif istismar görülürse yamanın daha da erken çıkabileceği yazıyordu. Sızıntıdaki 10.0 puanının PHP'nin kendi değerlendirmesi olmadığının da altını çizmek gerekir.

Güncelleme 21 Ekim'de geldi. Huntress'in aktardığına göre sürümler planlanan saatten kısa bir süre önce yayındaydı: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Geliştirme aşamasındaki 8.6 dalı için düzeltme de 8.6.0 RC4 ile birlikte yayımlandı.

Açıkları birbirinden bağımsız olarak iki ekip buldu. Calif'ten Ryan Austin, 1 Ağustos'ta birden fazla RCE yolu tespit edip 11 Ağustos'ta PHP'ye bildirdi. Wiz Research ise kendi bulgularını 24 Ağustos'ta raporladı. Wiz, keşif ve istismar geliştirme aşamalarında yapay zeka modellerinden yoğun biçimde yararlandığını ve on yılı aşkın süredir kodda duran hataların bu sayede çok daha hızlı zincirlenebildiğini söylüyor. Koordineli açıklamaya OpenAI da dahil oldu.

Açıklar tam olarak ne?

İki açık da PHP ile yazılmış uygulamalarda değil, doğrudan yorumlayıcının bellek yönetiminde bulunuyor. Ortak noktaları, bir istek işlenirken ortaya çıkan ölümcül hatalar. Özellikle bellek sınırının aşıldığı (out of memory) durumlarda PHP, iç verilerini henüz tam hazırlamamışken ya da temizlememişken yarıda kesiliyor. Geride kalan bu yarım durum, aynı worker süreç tarafından işlenen bir sonraki istekte sanki geçerliymiş gibi kullanılıyor.

CVE-2026-109618, bellek yetersizliği kaynaklı bozulma. PHP'nin resmi tanımına göre bellek yetersizliği hatası, istekle ilgili iç veriler yalnızca kısmen hazırlanmışken çalışmayı durdurabiliyor. İstek sonunda yapılan temizlik bu geçersiz verileri geçerliymiş gibi işliyor ve kod çalıştırmaya giden yol buradan açılıyor. PHP ekibi, Apache mod_php üzerinde varsayılan limitlerle, HTTP üzerinden ve kimlik doğrulaması olmadan tam RCE elde edildiğini doğruladı.

CVE-2026-109619, bayat global durum. Bir isteğe ait iç durum, arkasındaki bellek serbest bırakıldıktan sonra da yaşamaya devam edebiliyor. Aynı worker'ın işlediği sonraki istek, normal başlatma süreci bu durumu sıfırlamadan önce ona erişebiliyor. Sonuç kimlik doğrulamasız bir heap use-after-free, bellek ifşası ve worker yetkileriyle kod çalıştırma.

Wiz Research'ün teknik yazısı tabloyu biraz daha netleştiriyor. Araştırmacılar dosya yükleme ilerlemesini takip eden mekanizmanın (session upload progress) kullandığı unserializer'da, ölümcül hata geri izlemesinde (fatal error backtrace) ve OPcache'in paylaşımlı belleğinde birbirine benzeyen use-after-free ve tür karışıklığı (type confusion) hataları buldu. Bunlardan biri özellikle dikkat çekici: Belirli bir multipart isteğinin ardından serbest bırakılmış bellek içeriği, sunucunun döndürdüğü PHPSESSID çerezine kodlanarak saldırgana geri gönderilebiliyor. Bu, uygulama session_start() hiç çağırmasa bile oluyor. Yani saldırgan daha kod çalıştırmaya ulaşmadan, başka kullanıcıların isteklerinden kalan parolaları, oturum anahtarlarını, API token'larını, hatta TLS özel anahtarlarını okuyabiliyor.

Sansec'in incelemesine göre bilinen bütün tetikleme yolları multipart/form-data istekleri üzerinden ilerliyor ve hem Apache mod_php hem de PHP-FPM varsayılan ayarlarla etkileniyor. PHP'nin kendi güvenlik bildirisi riski daha da geniş tutuyor: Web isteklerine yanıt veren tüm kurulumlar, yani PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed risk altında. En yüksek risk mod_php'de, çünkü burada tek bir kimlik doğrulamasız istekle, uygulama kodu hiç çalışmadan tetiklenebilen bir istismar gösterilmiş durumda.

Neden bu kadar ciddi?

Web açıklarının çoğu belirli bir eklentiye, belirli bir framework'e ya da özensiz yazılmış bir koda bağlıdır. PHP2Shell'de durum farklı. Sorun yorumlayıcının içinde olduğu için üzerinde ne çalıştığının pek bir önemi yok. Wiz, basit bir "Hello World" uygulamasının bile etkilenen bir PHP sürümünde savunmasız kalabileceğini söylüyor.

Araştırmacıların paylaştığı sonuçlar da bunu destekliyor. Wiz, WordPress, Drupal ve Joomla'nın resmi konteyner imajlarında kimlik doğrulamasız RCE elde ettiğini açıkladı. Sansec ise listeyi uzattı: Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel 13, Symfony 8.1 ve WHMCS üzerinde başarılı istismar raporlandı. Uygulama katmanındaki güvenlik eklentileri ya da bakım modları burada işe yaramıyor, çünkü saldırı uygulamaya sıra gelmeden gerçekleşiyor.

Ölçek ayrı bir sorun. W3Techs verilerine göre sunucu tarafı dili bilinen web sitelerinin yaklaşık yüzde 69'u PHP kullanıyor. Mallory'nin 20 Ekim tarihli Shodan analizine göre sürüm bilgisi görünen yaklaşık 1,5 milyon internete açık PHP sunucusunun 884 bini, yani yüzde 59'u 8.1 veya daha eski bir sürüm bildiriyor. Bunlar resmi yama almayacak sürümler. Yaklaşık 740 bin sunucu ise sürüm bilgisini hiç göstermiyor.

Açıkların yaşı da tabloyu ağırlaştırıyor. Sansec'e göre ilgili kod PHP 5.4 ile, yani 2012'de eklendi. Wiz de son on yılda yayımlanan her PHP sürümünün bu hatalardan en az birini taşıdığını belirtiyor.

İstismar durumu

Yama çıkmadan önce bile tablo hızla değişti. Cloudflare CTO'su Dane Knecht, 21 Ekim sabahı ilk saldırı girişimlerini görmeye başladıklarını duyurdu. Sansec'in aktardığına göre ilk girişimler 07:43 UTC'de, yani resmi yamadan saatler önce kayda geçti. Cloudflare bilinen saldırı vektörleri için ücretsiz plan dahil tüm müşterilerine WAF kuralları yayımladı ama bunu geçici bir önlem olarak tanımlıyor. watchTowr açıklardan birini yeniden üretebildiğini bildirirken Huntress, aynı sabah itibarıyla kendi müşteri tabanında doğrulanmış bir istismar görmediğini açıkladı.

Burada bir uyarı yapmak gerekiyor. İnternette "PHP2Shell exploit" adıyla dolaşan kodların bir kısmının gerçekten çalışıp çalışmadığı belli değil ve Tenable bunların zararlı yazılım içerebileceği konusunda uyarıyor. Test amacıyla bile olsa kaynağı belirsiz istismar kodları kurum sistemlerinde çalıştırılmamalıdır.

Geçmiş de iyi bir gösterge. 2024'teki PHP-CGI açığı CVE-2024-4577 için Akamai, istismar girişimlerini kamuya açıklamadan sonraki 24 saat içinde görmüştü. Bu açık ve 2019'daki PHP-FPM açığı CVE-2019-11043, bugün CISA'nın aktif olarak istismar edilen açıklar kataloğunda fidye yazılımı kampanyalarıyla ilişkili olarak yer alıyor. PHP2Shell'in de benzer bir yol izlemesini beklemek için yeterince neden var.

Hangi sürümler etkileniyor, hangileri yama alıyor?

PHP ekibi yalnızca desteklenen dallar için yeni sürüm yayımladı. Aşağıdaki tablo güncel durumu özetliyor:

Desteği sona ermiş sürümler için küçük ama önemli bir istisna var. PHP güvenlik ekibi, kaynak koddan derleme yapan ya da bir LTS sağlayıcısına erişimi olmayan kullanıcılar için 7.4, 8.0 ve 8.1 dallarına minimal backport yamaları yayımladı. Bunlar php-src deposunda PHP-<sürüm>-CVE-2026-109618-109619 adlı dallarda duruyor. Linux dağıtımları ve LTS sağlayıcıları da yamaları önceden aldı, bu yüzden Debian, Ubuntu, RHEL ya da Alpine kullanılan sistemlerde ilgili dağıtımın güvenlik bildirileri kontrol edilmelidir. Sansec, popüler Remi deposunun yayın günü henüz güncellenmediğini not ediyor.

8.2 kullanan sistemler için ayrı bir not düşmek gerekir: Bu dal bugün yamayı aldı ama ömrü iki ay sonra doluyor. Zaten acil bir değişiklik penceresi açılacağı için bu fırsat, 8.4 ya da 8.5'e geçişin planlanması için de değerlendirilmelidir.

Bugün yapılması gerekenler

1. Envanter çıkarılmalıdır. Sunucular, konteyner imajları, CI ortamları ve geliştirici makineleri listelenmelidir. PHP'yi kendi içinde getiren ürünler de göz ardı edilmemelidir: cPanel ve Plesk gibi kontrol panelleri, ağ cihazları ve bazı Windows tabanlı kurumsal yazılımlar da kapsamda. Komut satırındaki php -v çıktısı web tarafında çalışan sürümü her zaman yansıtmaz, çünkü FPM havuzları ve mod_php farklı bir binary kullanıyor olabilir.

2. İnternete açık sistemlere öncelik verilmelidir. İlk sırada doğrudan erişilebilen web sunucuları, ardından iç ağdaki sistemler ele alınmalıdır.

3. Güncelleme yapılmalı ve süreçler yeniden başlatılmalıdır. Yeni paketi kurmak tek başına yetmez. PHP-FPM ve Apache servisleri yeniden başlatılmazsa eski kod bellekte çalışmaya devam eder. Konteyner kullanılan ortamlarda imajlar yeni base image ile yeniden derlenip dağıtılmalı, kullanılan etiketin (ör. php:8.3-fpm) gerçekten güncellenmiş sürümü gösterdiği kontrol edilmelidir.

4. Sonuç doğrulanmalıdır. Güncellemeden sonra çalışan sürüm web üzerinden, yani gerçekten FPM ya da mod_php tarafından işlenen bir istekle teyit edilmelidir.

5. Desteği bitmiş sistemler ayrıca ele alınmalıdır. 8.1 ve öncesini kullanan sistemler desteklenen bir sürüme taşınmalı ya da dağıtım backport'u uygulanmalıdır. Bunların hiçbiri mümkün değilse sistem internetten çekilip VPN arkasına alınmalıdır. CERT-EU da yama uygulanana kadar internete açık uygulamaların izole edilmesini öneriyor.

6. Barındırma sağlayıcısıyla iletişime geçilmelidir. Paylaşımlı hosting ya da yönetilen bir platform kullanılıyorsa güncellemenin ne zaman uygulanacağı sağlayıcıdan yazılı olarak teyit edilmelidir. WordPress kullanıcıları PHP sürümünü Araçlar > Site Sağlığı > Bilgi > Sunucu menüsünden görebilir.

Yama hemen uygulanamıyorsa

PHP'nin güvenlik bildirisi, güncellemenin tek tam çözüm olduğunu açıkça vurguluyor. Yine de yamayı uygulayana kadar bilinen saldırı yollarını daraltan bazı ayarlar paylaştı:

; CVE-2026-109618: PHP bellek sınırının kaldırılması
; (tercihen FPM/Apache tarafında php_admin_value ile)
memory_limit = -1

; İstek gövdesi boyutunun sınırlandırılması
post_max_size = 8M          ; dosya yükleme gerekiyorsa 32M
upload_max_filesize = 7M    ; post_max_size değerinden küçük kalmalı

; CVE-2026-109619: yükleme ilerleme takibinin kapatılması
session.upload_progress.enabled = 0

; Yalnızca PHP 8.5
fatal_error_backtraces = 0

Bu ayarlar uygulanırken birkaç noktaya dikkat edilmelidir. Değerler ini_set() ya da .user.ini ile değil, doğrudan php.ini veya FPM havuz dosyalarında tanımlanmalı, değişiklikten sonra bütün worker'lar yeniden başlatılmalıdır. PHP ekibi RLIMIT_AS ve RLIMIT_DATA gibi işletim sistemi seviyesindeki sınırlara güvenilmemesini de özellikle belirtiyor. memory_limit = -1 ayarının bir bedeli de var: Tek bir isteğin sunucunun bütün belleğini tüketmesinin önü açılıyor, bu yüzden istek boyutu sınırlarıyla birlikte kullanılması şart.

Daha sert bir geçici çözüm, web sunucusu seviyesinde multipart/form-data isteklerini engellemek. Bilinen tüm tetikleme yolları bu istek tipinden geçtiği için etkili, ancak dosya yükleme ve bazı ödeme formları da çalışmaz hale gelir. Bir e-ticaret sitesi için en güvenli ara çözüm, yama uygulanana kadar siteyi salt okunur moda almak olabilir. Sansec, Magento ve WordPress'in kendi bakım modlarının burada koruma sağlamadığını hatırlatıyor, çünkü bu modlar da PHP üzerinden çalışıyor.

WAF kuralları (Cloudflare, AWS, Akamai, Fastly ve diğerleri) zaman kazandırır ama yalnızca o servisten geçen trafiği korur. Sunucuya doğrudan IP üzerinden ulaşılabiliyorsa bu koruma devre dışı kalır.

MDR ve SOC ekipleri için izleme rehberi

Yama gerçekleşmiş bir sızmayı geri almaz. İlk saldırı girişimleri resmi yamadan önce başladığı için yalnızca bundan sonrasını izlemek yetmiyor; en az 20 Ekim'den itibaren geriye dönük bir av (threat hunting) yapılması gerekiyor. Şu an için resmi bir IOC listesi (IP, hash, imza) yayımlanmış değil. Bu yüzden tespitin davranışa dayalı kurgulanması gerekiyor. Saldırı uygulama katmanının altında gerçekleştiği için uygulama logları da çoğu zaman sessiz kalacak. Asıl görünürlük web sunucusu, PHP süreç ve uç nokta telemetrisinden gelecek.

Önce kapsam ve öncelik

MDR ekipleri için ilk iş, izlenen her ortamda internete açık PHP varlıklarını çıkarmak ve bunları sürüm ile yama durumuna göre etiketlemek. Zafiyet tarayıcılarındaki genel PHP sürüm tespit kontrolleri (örneğin Tenable'ın 48243 ve 58987 numaralı eklentileri) CVE'ye özel kontroller yayımlanana kadar iyi bir başlangıç noktası. Yaması uygulanmamış ve internete açık sistemler için alarm eşiklerini geçici olarak düşürmek, bu varlıklardan gelen her yüksek seviyeli alarmı da doğrudan analiste yönlendirmek mantıklı olur. Müşterilerin yama ilerlemesini aynı listeden takip etmek, hangi sistemlerin ne kadar süre açıkta kaldığını da kayıt altına alır.

Görünürlük: hangi loglar lazım?

Varsayılan erişim logları bu açık için eksik kalıyor. Nginx ve Apache standart formatta istek gövdesinin boyutunu ve Content-Type başlığını kaydetmez. Yama sürecinde log formatına bu iki alanı ve mümkünse yanıt boyutunu eklemek, multipart tabanlı denemeleri ayırt etmeyi çok kolaylaştırır. Bunun yanında PHP-FPM ve Apache hata loglarının, EDR ya da auditd üzerinden süreç oluşturma olaylarının, web sunucularının dış bağlantılarını gösteren ağ verisinin ve web kök dizini için dosya bütünlüğü izlemenin SIEM'e aktığından emin olunmalıdır. WAF ya da reverse proxy kullanılıyorsa yanıt başlıklarının da loglanması, PHPSESSID üzerinden gerçekleşen bellek ifşasını görmenin neredeyse tek yolu.

Tespit senaryoları

Aşağıdaki tablo, istismarın farklı aşamalarında ortaya çıkması beklenen sinyalleri bir arada gösteriyor. İlk dört satır deneme ve bellek ifşası aşamasını, kalan satırlar ise başarılı bir sızma sonrasını kapsıyor.

Örnek Sigma kuralı

Başarılı bir RCE'nin ardından en güvenilir sinyal, PHP çalıştıran süreçlerin kabuk ya da araç başlatması. Aşağıdaki kural Linux süreç oluşturma olayları için yazıldı ve kullanılan SIEM'e göre dönüştürülebilir:

title: PHP worker sürecinden kabuk veya araç başlatılması
status: experimental
description: PHP2Shell sonrası olası kod çalıştırma (CVE-2026-109618/109619)
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - 'php-fpm'
      - 'php-cgi'
      - 'lsphp'
      - 'frankenphp'
      - '/httpd'
      - '/apache2'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
  condition: selection_parent and selection_child
falsepositives:
  - exec() ile sendmail, ImageMagick vb. çağıran meşru uygulamalar
level: high

Bazı uygulamalar exec() ya da mail() üzerinden meşru olarak /bin/sh çağırdığı için kural devreye alınmadan önce ortamdaki normal davranış bir süre gözlemlenmeli ve istisnalar buna göre tanımlanmalıdır. Huntress, teknik ayrıntılar netleştiğinde Sigma ve YARA kurallarını huntresslabs/threat-intel GitHub deposunda paylaşacağını duyurdu; bu deponun takip edilmesinde fayda var.

Microsoft Defender için KQL

Defender for Endpoint kullanan ortamlarda aynı mantık şu sorguyla geriye dönük olarak taranabilir:

DeviceProcessEvents
| where Timestamp > datetime(2026-10-20)
| where InitiatingProcessFileName has_any
    ("php-fpm", "php-cgi", "lsphp", "httpd", "apache2")
| where FileName in~ ("sh", "bash", "dash", "python3", "perl",
    "curl", "wget", "nc", "cmd.exe", "powershell.exe", "certutil.exe")
| project Timestamp, DeviceName, AccountName,
    InitiatingProcessFileName, FileName, ProcessCommandLine

Sunucu üzerinde hızlı log taraması

EDR'ı olmayan ya da SIEM'e log göndermeyen sunucularda ilk kontrol için şu komutlar iş görür. Log yolları dağıtıma ve PHP sürümüne göre değişebilir:

# Bellek sınırı hataları
grep -E "Allowed memory size of [0-9]+ bytes exhausted" \
  /var/log/php*-fpm.log /var/log/apache2/error.log

# Çöken PHP-FPM worker'ları
grep -E "exited on signal (11|6)" /var/log/php*-fpm.log

# 500 dönen POST isteklerinin kaynak IP dağılımı
awk '$6 ~ /POST/ && $9 == 500 {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

# Son 3 günde web kökünde değişen PHP dosyaları
find /var/www -name "*.php" -mtime -3 -ls

Komut satırlarında /dev/tcp/, mkfifo, base64 -d gibi ifadeler ya da web sunucusu kullanıcısıyla çalıştırılmış whoami, id, uname -a gibi keşif komutları görülmesi durumunda bu doğrudan olay olarak ele alınmalıdır. EDR bulunmayan Linux sunucularda Florian Roth'un ücretsiz process-watcher aracı bu tür alt süreçleri görünür kılabilir; ancak araç yalnızca kayıt tutar, hiçbir şeyi engellemez.

Alarm geldiğinde

1. Sunucu ağdan izole edilmeli, ancak kapatılmamalıdır. Bellek ve çalışan süreçler delil değeri taşır.

2. Web sunucusu, PHP-FPM ve sistem logları, mümkünse bellek imajıyla birlikte koruma altına alınmalıdır.

3. Web kök dizinindeki webshell ve yeni dosyalar, yeni cron görevleri, systemd servisleri, SSH anahtarları ve kullanıcı hesapları incelenmelidir.

4. Sunucunun bağlandığı dış adresler çıkarılmalı ve aynı adreslerin diğer varlıklarla iletişimi SIEM üzerinde aranmalıdır.

5. Sistem temiz bir imajdan, yamalı PHP sürümüyle yeniden kurulmalıdır. Sızılmış bir sunucuyu yalnızca yamalamak yeterli değildir.

Son olarak bellek ifşası ihtimali de göz ardı edilmemelidir. CVE-2026-109618 kod çalıştırma izi bırakmadan da veri sızdırabildiği için, yamanın gecikmeli uygulandığı internete açık sistemlerde veritabanı parolalarını, API anahtarlarını, uygulama sırlarını (örneğin Laravel APP_KEY ya da WordPress salt değerleri) ve gerekiyorsa TLS sertifikalarını yenilemek makul bir önlem olacaktır.