php2shell PHP açığı: etkilenen sürümler ve çözüm

Özet: Birleşik Krallık Ulusal Siber Güvenlik Merkezi (NCSC), 21 Ekim’de PHP’yi etkileyen kritik bir sorun için uyarı yayımladı. Sorun aslında iki ayrı açık: biri bellek yetmediğinde isteğin yarıda kesilmesinden, diğeri bir istekten kalan durumun aynı işçi süreçteki sonraki istekte kullanılmasından doğuyor. İkisi de kimlik doğrulaması olmadan, web sunucusunun kullanıcı hesabıyla kod çalıştırmaya kadar gidebiliyor. PHP 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 sürümleriyle düzeltme yayımladı ve tek tam çözümün güncelleme olduğunu söylüyor. Bu yazıda resmî duyurularda yazanları, risklerin nerede yoğunlaştığını, güncelleme hemen yapılamıyorsa alınabilecek geçici önlemleri ve henüz doğrulanmamış iddiaları ayrı ayrı topladım.

php2shell nedir, kimleri etkiliyor?

Kısa cevap: php2shell, PHP’nin çekirdeğindeki iki kritik açığın (CVE-2026-109618 ve CVE-2026-109619) ortak adı. Web isteği işleyen bütün PHP kurulumları etkileniyor; en yüksek risk Apache mod_php kullanan sunucularda. Çözüm, PHP’yi 8.2.35, 8.3.36, 8.4.27 ya da 8.5.12 sürümüne güncellemek ve bütün PHP işçilerini yeniden başlatmak.

Soru	Cevap
Açıklar	CVE-2026-109618, CVE-2026-109619
Önem	Kritik, CVSS 4.0 puanı 9,2
Kimlik doğrulama gerekiyor mu?	Hayır
Duyuru tarihi	21 Ekim 2026
Düzeltilmiş sürümler	8.2.35, 8.3.36, 8.4.27, 8.5.12
En riskli kurulum	Apache `mod_php`
Tam çözüm	Güncelleme; ayar değişiklikleri yalnızca riski azaltır

Ne oldu?

PHP projesi 20 Ekim’de kritik bir güvenlik sürümü geleceğini önceden duyurdu, 21 Ekim’de de dört dalda birden güvenlik sürümü çıkardı. Aynı gün NCSC, Kanada Siber Güvenlik Merkezi ve Hollanda NCSC’si (NCSC-NL) uyarı yayımladı. Güvenlik çevrelerinde iki açık birlikte php2shell adıyla anılıyor. Bu adı PHP’nin kendi duyurusu kullanmıyor; NCSC-NL’nin takip deposu ve çeşitli güvenlik firmaları kullanıyor.

NCSC’nin uyarısı kısa ve genel tutulmuş. PHP çalıştıran her web sunucusunun risk altında olabileceğini belirtiyor ve kurumların önce internete açık sistemlerden başlayarak PHP kurulumlarını bulmasını ve güncellemesini istiyor. Sürüm numaralarını ve teknik ayrıntıları PHP’nin GitHub üzerindeki güvenlik duyurularından ve php.net’ten aldım.

İki açık neyi bozuyor?

1. CVE-2026-109618: bellek yetmediğinde yarım kalan istek

PHP, bir istek memory_limit sınırını aştığında isteği longjmp() ile yarıda keser. Kesinti, isteğe ait bazı iç veriler henüz yarım hazırlanmışken gelirse isteğin kapanış aşaması bu yarım veriyi geçerliymiş gibi okuyabiliyor. Bunun sonucu bellek bozulması oluyor.

PHP’nin duyurusuna göre saldırgan, çok parçalı form verisiyle (multipart/form-data) bellek kullanımını görünürdeki sınırların içinde kalarak şişirebiliyor. Apache mod_php üzerinde, varsayılan ayarlarla, HTTP üzerinden, kimlik doğrulaması gerektirmeden uzaktan kod çalıştırılabildiği doğrulanmış. Duyuruda, kaynak kod incelemesine göre PHP-FPM, FrankenPHP ve LiteSpeed’in de etkilenebileceği yazıyor; ancak FPM için tam bir istismar gösterilmemiş.

Düzeltme, bellek yetmediğinde longjmp() kullanımını tamamen kaldırıyor. Yerine iki aşamalı bir yapı geliyor: önce güvenli bir noktada isteği durduran yumuşak bir sınır, daha yüksek bir eşikte de süreci hemen kapatan sert bir sınır.

2. CVE-2026-109619: sonraki isteğe taşınan eski durum

PHP-FPM ya da mod_php gibi kalıcı işçi süreçlerle (worker) çalışan kurulumlarda aynı süreç art arda birçok isteğe hizmet eder. PHP’nin hata, oturum, nesne ve eklenti durumlarından bazıları, isteğin belleği serbest bırakıldıktan sonra da işçide kalabiliyor. Bir sonraki istek, normal başlatma bu durumu sıfırlamadan önce ona erişirse serbest bırakılmış bellek yeniden kullanılmış oluyor. Bu hata türü İngilizcede use-after-free diye anılıyor.

İstismar için aynı işçide iki adım gerekiyor: durumu bozuk bırakan bir istek ve onu sonradan okuyan bir işlem. PHP’nin doğruladığı iki yol var:

PHP 8.5’teki fatal_error_backtraces özelliği ile başlatma öncesinde çıkan INI uyarılarının birleşimi (mod_php üzerinde doğrulanmış).
Bellek yetmezliğiyle bozulan oturum yükleme ilerlemesi (session.upload_progress) yolu (mod_php ve PHP-FPM üzerinde doğrulanmış).

Açığın etkisi, bellek içeriğinin sızması ve web işçisinin yetkisiyle kod çalıştırılması.

3. Önem derecesi

	CVE-2026-109618	CVE-2026-109619
Duyurudaki İngilizce başlık	RCE via OOM corruption	RCE via stale global state
Önem	Kritik, CVSS 4.0 puanı 9,2	Kritik, CVSS 4.0 puanı 9,2
Kimlik doğrulama	Gerekmiyor	Gerekmiyor
Saldırı karmaşıklığı	Yüksek, ön koşul var	Yüksek, ön koşul var
Doğrulanmış ortam	Apache `mod_php`	Apache `mod_php`, PHP-FPM

Vektör ikisinde de aynı: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Karmaşıklığın “yüksek” olması, açığın istismar edilemeyeceği anlamına gelmiyor; istismarın başarısının derleme seçeneklerine, eklentilere ve bellek düzenine bağlı olduğunu gösteriyor.

Hangi sürümler etkileniyor?

Dal	Etkilenen	Düzeltilmiş sürüm	Not
8.5	8.5.12 öncesi	8.5.12
8.4	8.4.27 öncesi	8.4.27
8.3	8.3.36 öncesi	8.3.36
8.2	8.2.35 öncesi	8.2.35	Destek 31 Aralık 2026’da bitiyor
8.1, 8.0, 7.4	Etkileniyor	Resmî sürüm yok	PHP yalnızca kaynaktan derleyenler için asgari yamalar yayımladı

PHP’ye göre web isteği işleyen bütün kurulumlar etkileniyor: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Risk en çok mod_php kullanan kurulumlarda yüksek, çünkü gösterilen istismar uygulama kodu hiç çalışmadan, isteğin işlenmesi sırasında tetikleniyor. Yani sitenin WordPress, Laravel ya da elle yazılmış bir uygulama olması tek başına bir fark yaratmıyor.

Test aşamasındaki 8.6.0 sürümünün dördüncü sürüm adayı (RC4) düzeltmeleri içeriyor, ama üretim için değil. Dağıtımlar ve uzun süreli destek veren firmalar yamaları önceden aldı; AlmaLinux gibi bazıları aynı gün paket yayımladı. PHP, rpms.remirepo.net deposunun 21 Ekim’de güncel paket sunamayacağını da ayrıca duyurdu.

1. Kendi sunucumda ne kullandığımı nasıl anlarım?

Komut satırındaki sürüm ile web sunucusunun kullandığı sürüm farklı olabilir. Önce ikisini de kontrol etmek gerekiyor:

# Komut satırı sürümü
php -v

# PHP-FPM kuruluysa (paket adı dağıtıma göre değişir, ör. php8.3-fpm)
php-fpm8.3 -v

# Debian/Ubuntu: yüklü PHP paketleri ve sürümleri
dpkg -l | grep -E '^ii\s+(php|libapache2-mod-php)'

# RHEL/AlmaLinux/Rocky
rpm -qa | grep -E '^php'

Web tarafında PHP’nin hangi sunucu arayüzüyle (SAPI) çalıştığını görmek için phpinfo() çıktısındaki Server API satırına bakılabilir; satır “Apache 2.0 Handler” diyorsa mod_php kullanılıyor demektir. Bu sayfayı geçici açıp işi bitince silmek gerekir.

Paylaşımlı barındırma kullananlar sürümü genellikle panelden görür ve güncellemeyi barındırma firması yapar. Firmanın bir açıklama yapıp yapmadığına bakmak ve gerekirse sormak bu durumda en doğru adım.

2. Güncelleme

Tek tam çözüm güncellemektir. Dağıtım paketleri kullanılıyorsa dağıtımın güvenlik duyurusundaki sürüm, kaynaktan derleniyorsa yukarıdaki tablodaki sürüm esas alınır. Güncellemeden sonra bütün PHP işçilerinin yeniden başlatılması gerekiyor; yalnızca paketi yüklemek çalışan süreçleri değiştirmez:

# Örnek: Debian/Ubuntu, PHP-FPM ve Apache
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

NCSC özellikle şunu hatırlatıyor: PHP’yi kendi içinde barındıran ağ cihazları, yönetim panelleri, hazır uygulamalar ve kapsayıcı (container) görüntüleri sunucunun paket yöneticisiyle güncellenmez. Bunlar için üreticinin yamasını beklemek gerekiyor. NCSC-NL, etkilenebilecek ürünlerin bir listesini GitHub’da tutuyor.

3. Güncelleme hemen yapılamıyorsa

PHP’nin önerdiği geçici önlemler aşağıda. PHP’nin kendi ifadesiyle bunlar belirli saldırı yollarını daraltır ama kurulumu güvenli hâle getirmez. Ayarlar php.ini, FPM havuzu ya da sunucu yapılandırmasında verilmeli ve ardından bütün işçiler yeniden başlatılmalı; ini_set() ya da .user.ini ile verilen ayarlara güvenilmemeli.

CVE-2026-109619 için:

; Oturum yükleme ilerlemesi gerekmiyorsa kapalı tutulmalı (yamadan sonra da)
session.upload_progress.enabled = 0

; Yalnızca PHP 8.5
fatal_error_backtraces = 0

Ayrıca istek başına verilen ve başlatma sırasında uyarı üreten geçersiz ya da kullanımdan kalkmış ayarlar (.htaccess içindeki php_value satırları gibi) temizlenmeli. Uyarıyı error_reporting, display_errors ya da @ ile gizlemek işe yaramıyor.

CVE-2026-109618 için:

; Dosya yükleme gerekmiyorsa 8M, gerekiyorsa 32M
post_max_size = 8M
; upload_max_filesize, post_max_size değerinden küçük kalmalı
upload_max_filesize = 6M

PHP ayrıca memory_limit=-1 önerisini kısmi bir önlem olarak veriyor. Bu ayar bellek sınırını kaldırdığı için sunucunun başka bir yoldan, örneğin kapsayıcı ya da cgroup memory.max sınırıyla korunması gerekiyor. RLIMIT_AS ve RLIMIT_DATA kullanılmamalı; bunlar tam da açığı tetikleyen bellek ayırma hatasına yol açabiliyor. Web sunucusu ya da ters vekil (reverse proxy) katmanında istek boyutu, alan sayısı, çok parçalı form parça sayısı ve başlık sayısı için sınır konmalı. Uygulama çok parçalı form kullanmıyorsa bu istekler ön katmanda engellenebilir.

NCSC, bunların hiçbiri mümkün değilse sistemi yamalanana kadar çevrim dışı almanın düşünülmesini öneriyor. Yamayı geciktirmek zorunda kalınan sistemlerde web sunucusu kayıtlarına, beklenmedik süreçlere, dosyalara ve dışarıya giden bağlantılara bakılması da önerilenler arasında.

Doğrulanmamış iddialar

Bu bölümdekiler resmî duyurularda yok ya da birbiriyle çelişiyor:

Aktif istismar: watchTowr, kendi tuzak sistem (honeypot) ağında 21 Ekim itibarıyla istismar gördüğünü yazıyor. Patchstack ve Aikido da istismar bildirdi; ancak SOCRadar’ın notuna göre ikisi de teknik ayrıntı yayımlamadı. Datadog, istismar girişimlerinin açıkların kamuya duyurulmasından dört gün önce, 17 Ekim’de başladığını AWS’ye dayandırarak aktarıyor; Sansec ise Cloudflare’in düzeltmeler çıkmadan önce, 21 Ekim sabahı saldırı gördüğünü bir sosyal medya paylaşımına dayanarak yazıyor. Bunların hiçbirini birinci elden doğrulayamadım. Öte yandan Kanada Siber Merkezi aynı gün aktif istismar tespit etmediğini, ancak durumun hızla değişebileceğini söylüyor; Rapid7 de doğrulanmış istismar bildirmiyor, beklendiğini yazıyor. SOCRadar’a göre iki açık 21 Ekim itibarıyla CISA’nın istismar edilen açıklar kataloğunda (KEV) yoktu.
Kamuya açık kavram kanıtı (PoC): Kanada Siber Merkezi, kamuya açık haberlere göre bir kavram kanıtının bulunduğunu yazıyor. GitHub’da bu adla yayımlanmış depolar var; çalışıp çalışmadıklarını denemedim ve bağlantı vermiyorum.
PHP 5’e kadar uzanma: Bazı yazılar açıkların PHP 5’ten itibaren bütün sürümleri etkilediğini söylüyor. PHP, duyurusunda 7.4, 8.0 ve 8.1 için asgari yama yayımladığını belirtiyor; daha eski sürümler hakkında açık bir şey yazmıyor. NCSC’nin “PHP’nin her sürümü” ifadesi de bu yönde okunabilir, ama sürüm aralığı vermiyor.

Sık sorulan sorular

Sitem WordPress ise etkileniyor muyum?

Büyük olasılıkla evet. Açıklar WordPress’te değil, PHP’nin kendisinde. Sitenin hangi uygulamayla yapıldığından bağımsız olarak, sunucudaki PHP sürümü düzeltilmiş sürümlerden eskiyse risk var. Eklenti ya da tema güncellemesi bu sorunu çözmez.

Paylaşımlı barındırmada ne yapmalıyım?

PHP’yi barındırma firması günceller. Panelden PHP sürümüne bakmak, firmanın php2shell için bir açıklama yapıp yapmadığını kontrol etmek ve açıklama yoksa sormak yeterli. Panel izin veriyorsa desteklenen en yeni PHP dalına geçmek de iyi bir adım.

Yalnızca komut satırında PHP kullanıyorum, risk var mı?

Resmî duyurular web isteği işleyen kurulumları hedef gösteriyor; komut satırı (CLI) kullanımını ayrıca anmıyor. Yine de aynı makinede bir web sunucusu da çalışıyorsa güncelleme ertelenmemeli.

Geçici ayarlar yeterli mi?

Hayır. PHP, session.upload_progress.enabled=0, fatal_error_backtraces=0 ve memory_limit gibi ayarların belirli saldırı yollarını daralttığını, ama kurulumu güvenli hâle getirmediğini açıkça yazıyor.

PHP 8.1 ya da daha eskisini kullanıyorum, ne olacak?

PHP projesi bu dallar için yeni sürüm çıkarmıyor. Kaynaktan derleyenler için 7.4, 8.0 ve 8.1’e asgari yamalar yayımlandı; dağıtımlar ve uzun süreli destek veren firmalar da kendi yamalarını sunabiliyor. Kalıcı çözüm desteklenen bir dala geçmek.

Benim okumam

Kesin olan: İki ayrı, kritik ve kimlik doğrulaması gerektirmeyen açık var; düzeltmeler 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 ile geldi. En çok risk altındaki kurulum Apache mod_php.
Yapılandırma tek başına çözüm değil: PHP, geçici önlemlerin hiçbirinin kurulumu güvenli hâle getirmediğini açıkça yazıyor. Ayar değiştirip güncellemeyi ertelemek riski yalnızca küçültür.
Asıl yük sunucunun dışında: Kendi sunucusunu güncellemek görece kolay. Zor olan, PHP’yi kendi içinde taşıyan cihazlar, paneller ve kapsayıcı görüntüleri; bunların ne zaman yamalanacağı üreticiye bağlı.
Desteği bitmiş sürümler: 8.1 ve öncesinde kalan sistemler bu kez resmî bir sürüm alamadı. 8.2’nin de 31 Aralık 2026’da destek dışına çıkacağı düşünülünce, güncellemeyi bir sonraki dala geçişle birlikte planlamak mantıklı görünüyor.
İstismar konusunda temkinli olmak: Aktif istismar iddiaları birkaç güvenlik firmasından geliyor ama resmî kurumlar henüz doğrulamadı. Bunları kesin kabul etmiyorum; yine de güncellemeyi beklemek için bir neden olarak da görmüyorum. Yeni resmî bilgi gelirse yazıyı güncelleyeceğim.

Kaynaklar

Resmî duyurular

Güvenlik firmalarının değerlendirmeleri