PHP2Shell: PHP'de Kimlik Doğrulamasız Uzaktan Kod Çalıştırma Açıkları (CVE-2026-109618 ve CVE-2026-109619)

PHP projesi 21 Ekim 2026'da, PHP'nin desteklenen tüm sürüm dallarında iki kritik güvenlik açığını kapatan acil sürümler yayınladı. Güvenlik topluluğunda birlikte PHP2Shell adıyla anılan CVE-2026-109618 ve CVE-2026-109619, CVSS v4.0 ölçeğinde 9.2 puanla "kritik" olarak derecelendirildi. İki açık da saldırganın herhangi bir kimlik doğrulaması olmadan, web isteği sunan bir PHP sunucusunda uzaktan kod çalıştırmasına (RCE) imkân tanıyor.

Durumu daha da ciddi kılan, istismarın çok hızlı başlaması: Güvenlik firması watchTowr, yamaların yayınlandığı 21 Ekim'den itibaren kendi honeypot ağında gerçek saldırı girişimleri gözlemlediğini bildirdi.

Açıklar tam olarak ne?

İki açık da PHP'nin istek yaşam döngüsündeki bellek yönetimiyle ilgili.

CVE-2026-109618, bellek yetersizliği sırasında bozulma: PHP bir isteği hazırlarken bellek sınırına ulaşırsa işlem yarıda kesilebiliyor. Bu durumda bazı iç veri yapıları yalnızca kısmen oluşturulmuş halde kalıyor; isteğin ardından çalışan temizlik kodu ise bu yarım verileri geçerliymiş gibi kullanıyor. Kötü niyetli bir isteğe yanıt veren işçi sürecini bellek sınırına zorlayabilen bir saldırgan açığı tetikleyebiliyor.

CVE-2026-109619, süresi dolmuş global durum: Bir isteğe ait iç durum, işaret ettiği bellek serbest bırakıldıktan sonra da yaşamaya devam ediyor. Aynı işçi sürecinin işlediği bir sonraki istek, normal başlatma bu durumu sıfırlamadan önce bu kalıntı veriyi kullanabiliyor. PHP-FPM gibi uzun ömürlü işçi modellerinde bu, istekler arası bir "use-after-free" hatası anlamına geliyor.

Kimler etkileniyor?

Kısa cevap: Web isteği sunan neredeyse her PHP kurulumu. Snyk ve watchTowr'un analizlerine göre kapsam şunları içeriyor:

• PHP-FPM
• Apache mod_php
• php-cgi
• LiteSpeed
• FrankenPHP

Bunlar arasında en riskli yapılandırma Apache mod_php. Snyk'e göre bu yapılandırmada tek bir kimlik doğrulamasız isteğin, uygulamanın kendi kodu daha hiç çalışmadan saldırıyı tetiklediği gösterildi. Bu da WordPress gibi uygulamaların güncel olmasının ya da güvenlik eklentisi kullanmanın tek başına koruma sağlamadığı anlamına geliyor. Açık, uygulamanın değil PHP motorunun kendisinde.

Yamalı sürümler

Güncellenmesi gereken sürümler şöyle:

Sürüm dalı	Yamalı sürüm
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 7.4, 8.0, 8.1	Resmi sürüm yok; dağıtım/LTS sağlayıcı paketleri veya PHP'nin yayınladığı kaynak kod yamaları
PHP 7.3 ve öncesi	Yama yok; desteklenen bir dala geçiş şart

php.net değişiklik günlüğünde düzeltmeler, Core bileşeninde "bailout yoluyla durum bozulmasının önlenmesi" başlığı altında GHSA-w8hw-w9fx-j79w ve GHSA-6wmf-4rv5-p3rp tanımlayıcılarıyla yer alıyor.

Geçici önlemler işe yarar mı?

PHP'nin açıklamasına göre hiçbir yapılandırma değişikliği bu açıkları tamamen kapatmıyor; tek güvenli çözüm güncellemek. Hemen güncelleyemeyenler için PHP duyurusunda bazı saldırı yollarını daraltan ayarlar listeleniyor:

• uygulamaların değiştiremeyeceği şekilde memory_limit=-1,
• düşük bir post_max_size değeri,
• session.upload_progress.enabled=0 ve ardından tüm işçi süreçlerinin yeniden başlatılması,
• PHP 8.5'te fatal_error_backtraces=0.

Bu ayarların kendi yan etkileri var. Örneğin memory_limit=-1, kontrolsüz bellek tüketimine kapı açıyor. Üstelik kurulumu güvenli hale getirmiyorlar. watchTowr'un önerisi de net: Hemen güncellenemeyen PHP sistemlerinin internet erişimi kısıtlanmalı.

Ne yapmalısınız?

1. Envanter çıkarın. Sunucularınızda, konteynerlerinizde ve paylaşımlı hosting hesaplarınızda hangi PHP sürümlerinin çalıştığını belirleyin. php -v komut satırı sürümünü gösterir; web sunucusunun kullandığı sürüm farklı olabilir, bunu phpinfo() ya da panel üzerinden doğrulayın.
2. Güncelleyin. Dağıtım paketleri, hosting paneli (Plesk, cPanel vb.) veya kendi derlemeniz üzerinden yamalı sürüme geçin. Plesk, kendi dağıttığı PHP sürümleri için ayrı bir destek makalesi yayınladı.
3. Docker kullanıyorsanız imaj etiketlerini kontrol edin. php:8.3-apache gibi taban imajlar güncellense bile, bunların üzerine kurulu uygulama imajları (örneğin resmi WordPress imajı) yeniden derlenene kadar eski PHP sürümünü taşıyabilir. Konteynerin içinde php -r 'echo PHP_VERSION;' ile gerçek sürümü doğrulayın.
4. Tüm işçi süreçlerini yeniden başlatın. PHP-FPM havuzlarını, Apache'yi veya uygulama sunucusunu yeniden başlatmadan yama devreye girmez.
5. İz arayın. Açık 21 Ekim'den beri istismar edildiği için o tarihten sonra yamasız kalan sistemlerde beklenmedik PHP dosyaları, değişmiş çekirdek dosyaları ve olağandışı giden bağlantılar kontrol edilmeli.

Sonuç

PHP2Shell, uygulama katmanındaki güvenlik önlemlerini tamamen devre dışı bırakan, motor seviyesinde bir açık. Kimlik doğrulama gerektirmemesi, yaygın her çalışma modunu etkilemesi ve aynı gün istismar edilmeye başlanması nedeniyle bu, "bir sonraki bakım penceresinde" değil hemen kapatılması gereken bir açık. Sürüm kontrolünü özellikle konteyner imajlarında ve paylaşımlı hosting ortamlarında atlamayın; asıl risk, güncellendiği sanılan ama hâlâ eski PHP ile çalışan sistemlerde.