PHP2Shell Güncellemesi: Son 24 Saatteki Gelişmeler ve aaPanel Adım Adım Yama Rehberi

Dün blogumda paylaştığım “PHP2Shell Açığı Rehberi: CVE-2026-109618 ve CVE-2026-109619” başlıklı yazımdan sonra hem sosyal medyadan hem de topluluk kanallarından çok sayıda soru ve geri bildirim aldım. Tehdit ortamı son 24 saatte olağanüstü bir hızla hareket etti. İlk saatlerdeki “kontrollü sızıntı ve teorik PoC” aşaması, yerini dünya çapında rastgele IP bloklarını hedef alan otomatik tarama botlarına ve istismar girişimlerine bıraktı.

Öte yandan, dünkü yazımda yedi farklı kontrol panelini (HestiaCP, CloudPanel, CyberPanel, cPanel, Plesk, DirectAdmin ve FastPanel) incelemiştim. Gelen mesajlarda en çok dile getirilen eksiklik, özellikle Türkiye’de ve bağımsız geliştiriciler arasında çok yaygın kullanılan aaPanel oldu.

Bu yazıda, son 24 saat içinde ortaya çıkan yeni teknik detayları, sahadaki saldırı dinamiklerini, geçici önlemlerle ilgili ölümcül bir operasyonel hatayı ve aaPanel kullanıcıları için adım adım PHP yamalama rehberini bir araya getirdim.

ÖZET: Son 24 Saatte Ne Değişti?

Aktif İstismar Taramaları Başladı: Honeypot sensörleri (watchTowr, Datadog ve GrayNoise telemetrileri), internet genelinde dosya yükleme ve multipart form uç noktalarına yönelik otomatik bellek tüketme saldırılarında keskin bir artış bildirdi. CISA, sistem yöneticilerine yamalamanın ertelenemez olduğunu yineleyen acil bültenler yayımladı.
Dağıtım Paketleri Hazır: Ubuntu (USN-7080-1), Debian (DSA-5789-1), RHEL / AlmaLinux / Rocky Linux için Remi Collet RPM depoları ve resmi Docker kütüphanesi yamalı PHP paketlerini yayımladı.
“pm.max_requests = 1” Tuzağı: Geçici bir önlem olarak önerilen pm.max_requests = 1 ayarının, orta ve yüksek trafikli sunucularda aşırı CPU yüküne ve beklenmedik bir Hizmet Reddi (DoS) krizine yol açtığı kanıtlandı. Kesin çözüm doğrudan ikili (binary) düzeyde yama yapmaktır.
WAF Atlatma Teknikleri: Cloudflare ve AWS WAF acil koruma imzaları dağıttı; ancak parçalı veri aktarımı (chunked transfer) ve özel sınır (boundary) manipülasyonlarıyla WAF kurallarını atlatan varyasyonlar gözlemlendi. WAF tek başına yeterli değildir.
aaPanel İçin Yol Haritası Netleşti: aaPanel’in izole /www/server/php/ dizin mimarisi nedeniyle standart apt upgrade işlemi paneli korumaz. App Store üzerinden hızlı (Fast) ya da kaynak koddan (Compiled) derleme ve SSH ile zorlama adımları netleştirildi.

Son 24 Saatte Sahadaki İstismar Durumu

21 Ekim’deki yama yayınının ve kavram kanıtı (PoC) araçlarının sızmasının ardından, tehdit aktörleri saldırı senaryolarını hızla otomatikleştirdi. Son 24 saatteki teknik gözlemler şu kritik tabroyu ortaya koyuyor:

1. CVE-2026-109618: Multipart Bellek Bozulması Hedefte

Bu açık, PHP’nin HTTP isteklerini işlerken memory_limit sınırına ulaştığında tetiklenen bellek boşaltma (longjmp) mantığındaki bir hataya dayanıyor. Saldırganlar, sunucuda herhangi bir kimlik doğrulaması gerektirmeksizin, kasıtlı olarak devasa ve eksik bırakılmış multipart/form-data gövdeleri gönderiyor.

İstek PHP’nin tahsis edebileceği sınırı aştığında, yarım kalmış bellek temizleme rutinleri belleği bozuk durumda serbest bırakıyor ve saldırgan tarafından gönderilen zararlı kabuk kodunun (shellcode) yürütülmesine zemin hazırlıyor. Sunucu hata loglarınızda şu satırı sık aralıklarla görmeye başladıysanız, sisteminiz aktif olarak taranıyor olabilir:

PHP Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes) in Unknown on line 0

2. CVE-2026-109619: Kalıcı İş Parçacığı (Worker) Zehirlenmesi

PHP-FPM veya Apache mod_php gibi yapılarda bir istek bittiğinde çalışma süreci (worker) hemen yok edilmez; sonraki isteği karşılamak üzere bellekte hazır bekletilir. CVE-2026-109619, ilk istek sırasında oluşan bir çökme veya sınır aşımının ardından küresel durumun (global state) düzgün sıfırlanmaması sonucunu doğuruyor.

Son 24 saatteki telemetri raporları, saldırganların ardışık iki istek göndererek birinci istekle belleği zehirlediğini, aynı worker’a düşen ikinci istekle ise kod yürütme ayrıcalığı elde ettiğini gösteriyor.

Geçici Önlemlerdeki Ölümcül Hata: “pm.max_requests = 1” Tuzağı

Yamanın ilk saatlerinde bazı topluluk forumlarında ve bloglarda bir geçici çözüm (workaround) dolaşıma girdi: php-fpm.conf dosyasında pm.max_requests değerini 1 yapmak.

Bu tavsiyenin arkasındaki teorik fikir şuydu: “Eğer worker her istekten sonra ölürse, ikinci isteğe hiçbir kirli durum (global state) aktarılamaz, böylece CVE-2026-109619 engellenir.”

Ancak pratikte bu tam bir felakete dönüştü.

Her gelen istekte PHP worker sürecinin baştan başlatılması, işletim sisteminde muazzam bir fork() yükü oluşturur. Ziyaretçi alan sitelerde CPU kullanımı dakikalar içinde %100 seviyesine kilitlendi ve sunucular kendiliğinden çöktü. Saldırganın yapmaya çalıştığı Hizmet Reddi (DoS) durumunu, sistem yöneticileri kendi elleriyle oluşturmuş oldu.

Önemli Tavsiyem: Eğer sunucunuzda pm.max_requests = 1 ayarı yaptıysanız bunu derhal makul bir seviyeye (örneğin 500 veya 1000) geri çekin. Güvenliği bu tür tehlikeli ayarlarla değil, PHP çekirdeğini yamalı sürüme güncelleyerek sağlayın.

aaPanel İçin Adım Adım PHP2Shell Yama Rehberi

aaPanel, Linux sunucu yönetimini kolaylaştıran harika bir panel olsa da kendine has bir dizin ve derleme yapısına sahiptir. Ubuntu veya Debian üzerinde apt update && apt upgrade çalıştırdığınızda sistemin varsayılan paketleri güncellenir; ancak aaPanel’in sitelerinize bağladığı PHP sürümleri /www/server/php/ altında bağımsız olarak yaşadığı için bu genel komut aaPanel sitelerinizi korumaz!

aaPanel üzerinde PHP sürümlerinizi güvenli hale getirmek için aşağıdaki adımları sırasıyla uygulayın.

Adım 1: aaPanel App Store Önbelleğini Yenileyin

aaPanel, paket listelerini yerel olarak önbelleğe alır. En son yayımlanan yama paketlerini görebilmek için öncelikle bu listeyi güncellememiz gerekir:

aaPanel yönetim paneline giriş yapın.
Sol menüden App Store (Uygulama Mağazası) sekmesine tıklayın.
Üst kısımdaki Installed (Yüklü Olanlar) sekmesine geçin.
Sağ üst köşede bulunan Update App List (Uygulama Listesini Güncelle) butonuna tıklayın.

Adım 2: PHP Sürümlerini Arayüzden Güncelleyin

Listeniz yenilendikten sonra kurulu olan tüm PHP sürümlerini güncelleyin:

Arama çubuğuna PHP yazın veya listeden kurulu PHP sürümlerinizi (örneğin PHP-8.2, PHP-8.3, PHP-8.4) bulun.
Sürümün yanında Update (Güncelle) butonu belirdiyse tıklayın.
Karşınıza gelen kurulum yöntemi penceresinde Fast (Hızlı) modunu seçin. Hızlı mod, aaPanel’in işletim sisteminize göre önceden derlediği yamalı ikilileri indirir ve dakikalar içinde kurar.
Eğer Fast modu hata verirse ya da bulunduğunuz mimari için paket henüz düşmediyse, Compiled (Kaynak Koddan Derleme) seçeneğini seçin. Derleme işlemi işlemci gücünüze bağlı olarak 10 ila 25 dakika sürebilir.

Adım 3: SSH Terminali Üzerinden Hızlı Kurulum ve Zorlama

Sunucunuza SSH ile bağlanarak güncelleme betiğini doğrudan tetiklemek genellikle web arayüzünden daha hızlı ve kararlı sonuç verir.

SSH terminalinde root yetkisiyle şu komutları çalıştırın:

# aaPanel güncel PHP kurulum betiğini indirin
wget -O /root/php_install.sh http://node.aapanel.com/install/0/php.sh

# Kullandığınız sürümü parametre olarak vererek güncellemeyi başlatın
# PHP 8.2 için:
bash /root/php_install.sh install 82

# PHP 8.3 için:
bash /root/php_install.sh install 83

# PHP 8.4 için:
bash /root/php_install.sh install 84

Bu işlem, ilgili sürümün resmi yama uygulanmış en son paketini indirip /www/server/php/<sürüm>/ dizinine kuracaktır.

Adım 4: Açık Portları ve Sürüm Numaralarını Doğrulayın

Güncellemenin gerçekten başarılı olup olmadığını anlamanın tek yolu, aaPanel’in çalıştırdığı ikilinin versiyon bilgisini sorgulamaktır. Genel php -v komutu sistem genelindeki farklı bir ikiliyi gösterebilir; bu yüzden doğrudan aaPanel dizinini sorgulamalısınız:

# PHP 8.2 sürüm doğrulaması
/www/server/php/82/bin/php -v

# PHP 8.3 sürüm doğrulaması
/www/server/php/83/bin/php -v

# PHP 8.4 sürüm doğrulaması
/www/server/php/84/bin/php -v

Çıktıda görmeniz gereken asgari güvenli sürümler şunlardır:

PHP 8.2 için: 8.2.35 veya üzeri
PHP 8.3 için: 8.3.36 veya üzeri
PHP 8.4 için: 8.4.27 veya üzeri
PHP 8.5 için: 8.5.12 veya üzeri

Adım 5: PHP-FPM Servislerini Yeniden Başlatın

Paketler yüklense bile bellekte hâlâ eski PHP-FPM worker süreçleri çalışıyor olabilir. Bellekteki eski süreçleri temizlemek için servisleri yeniden başlatın:

# PHP 8.2 servisini yeniden başlatma
/etc/init.d/php-fpm-82 restart

# PHP 8.3 servisini yeniden başlatma
/etc/init.d/php-fpm-83 restart

# PHP 8.4 servisini yeniden başlatma
/etc/init.d/php-fpm-84 restart

Veya aaPanel arayüzünde: App Store -> Installed -> İlgili PHP sürümünün yanındaki Setting (Ayarlar) -> Service (Servis) -> Restart butonuna tıklayın.

Adım 6: OpenLiteSpeed (OLS) Kullanan aaPanel Sunucuları İçin Ekstra Adım

Eğer aaPanel üzerinde Nginx veya Apache yerine OpenLiteSpeed kullanıyorsanız, web sunucusu PHP’yi standart PHP-FPM olarak değil lsphp modülü olarak çalıştırır.

Bu durumda işletim sisteminizin paket yöneticisi üzerinden lsphp paketlerini de güncellemelisiniz:

Ubuntu / Debian sistemlerde: apt-get update apt-get install --only-upgrade 'lsphp*' -y systemctl restart lsws
AlmaLinux / Rocky Linux / CentOS sistemlerde: yum update 'lsphp*' -y systemctl restart lsws

Adım 7: Web Sitelerinin PHP Sürümünü Kontrol Edin

aaPanel’de birden fazla PHP sürümü kurulu olabilir. Sitelerinizin yamalı sürüme bağlı olduğundan emin olun:

Sol menüden Website bölümüne gidin.
Sitenizin sağ tarafında yer alan PHP Version sütununa bakın.
Eğer siteniz hâlâ destek süresi dolmuş (EOL) olan PHP 7.4 veya 8.1 gibi sürümleri kullanıyorsa, sürümün üzerine tıklayın ve açılır menüden yamalanmış PHP-8.2 veya PHP-8.3 sürümünü seçip Switch (Değiştir) butonuna basın.

Adım 8: aaPanel Güvenlik Sıkılaştırma Önlemleri

Sisteminizi korumak için panel üzerinden birkaç kritik güvenlik ayarını mutlaka devreye alın:

Tehlikeli Fonksiyonları Kapatın (disable_functions):
aaPanel App Store -> PHP -> Setting -> Disabled functions sekmesine gidin. Aşağıdaki fonksiyonların listede yer aldığından emin olun: system, exec, shell_exec, passthru, proc_open, popen, pcntl_exec, show_sourceBu ayar, saldırgan bir şekilde bellek zafiyetini tetiklese dahi sunucuda komut satırı kabuğu (reverse shell) açmasını engeller.
Gereksiz Dosya Yükleme Sınırlarını Düşürün:
PHP ayarlarından (php.ini) post_max_size ve upload_max_filesize değerlerini uygulamanızın gerçek ihtiyacına göre sınırlandırın (örneğin 10M veya 20M). Saldırganların yüzlerce megabaytlık yapay multipart paketleriyle belleği tüketmesini zorlaştırın.
aaPanel Yönetim Portunu Dış Dünyaya Sınırlandırın:
aaPanel panel giriş portunu (varsayılan 8888 veya değiştirdiğiniz özel port) Security sekmesindeki sistem güvenlik duvarından yalnızca kendi sabit IP adresinize açın.
Kullanılmayan Eski PHP Sürümlerini Kaldırın:
Sunucunuzda aktif bir site tarafından kullanılmayan PHP 7.0, 7.1, 7.2, 7.3, 7.4, 8.0 ve 8.1 kurulumlarını App Store -> Installed listesinden Uninstall ederek tamamen silin. Sistemin üzerinde çalışan her fazladan servis potansiyel bir saldırı yüzeyidir.

Sık Sorulan Sorular

aaPanel App Store üzerinde henüz en son sürüm görünmüyor, ne yapabilirim?

Bazı bölgesel CDN ve ayna sunucularında paketlerin senkronize olması birkaç saat sürebilir. Eğer Fast modda eski sürüm iniyorsa, kurulum penceresinde Compiled (Kaynak Koddan Derleme) seçeneğini işaretleyin. aaPanel derleme betikleri PHP’nin resmi kaynak deposundan en güncel kararlı tarball paketini çeker ve yamalı sürümü doğrudan makinenizde derler.

Sunucumu tamamen yeniden başlatmam (Reboot) gerekir mi?

Genellikle gerekmez; PHP-FPM servisinin ve web sunucusunun (Nginx, Apache veya OpenLiteSpeed) yeniden başlatılması yeterlidir. Ancak bellek üzerindeki tüm artık iş parçacıklarının ve paylaşılan bellek segmentlerinin temizlendiğinden yüzde yüz emin olmak istiyorsanız, uygun bir bakım penceresinde sunucuyu yeniden başlatmak (reboot) en temiz yaklaşımdır.

WordPress sitem var, eklentilerim PHP 8.2 veya 8.3 ile uyumsuz. Ne yapmalıyım?

PHP 8.1 ve öncesi için resmi upstream yama yayımlanmadı. Eğer siteniz PHP 7.4 veya 8.1 olmadan çalışmıyorsa, CloudLinux gibi ticari hardened PHP sürümleri sunan bir altyapıya geçebilir veya PHP Vakfı’nın GitHub üzerinde yayımladığı asgari kaynak kod yamasını (source backport) manuel olarak derleyebilirsiniz. Ancak en sağlıklı ve kalıcı çözüm, uyumsuz eklentiyi modern bir alternatifle değiştirip en az PHP 8.2.35 sürümüne terfi etmektir.

Loglarımda saldırı izi aramak için hangi komutu kullanabilirim?

Nginx ve PHP hata loglarınızda şüpheli bellek hatalarını ve olağandışı multipart isteklerini aramak için SSH üzerinden şu komutu çalıştırabilirsiniz:

# Nginx ve PHP hata loglarında bellek tükenmesi ve anormal hataları tarayın
grep -rnE "(Allowed memory size|multipart/form-data|SIGSEGV)" /www/wwwlogs/

Eğer kısa süre içinde binlerce Allowed memory size exhausted hatası görüyorsanız, ilgili IP adreslerini aaPanel Security sekmesinden engelleyin.

3 Adımlık Acil Eylem Planı

Bugün: aaPanel yönetim panelinize girin, App Store önbelleğini yenileyin, PHP sürümlerinizi güncelleyin ve /www/server/php/<sürüm>/bin/php -v komutuyla yamayı doğrulayın.
Bu Gece: Sunucunuzda kullanılmayan tüm eski PHP sürümlerini App Store üzerinden kaldırın; açık olan PHP-FPM servislerini yeniden başlatın.
Yarın: Loglarınızı inceleyin, disable_functions listesini gözden geçirin ve aaPanel yönetim portunu yetkisiz IP’lere kapatın.

Kaynakça ve Güvenlik Bildirimleri

PHP Group Güvenlik Duyurusu (21 Ekim 2026): PHP Core Security Update
GitHub Güvenlik Bildirimi GHSA-w8hw-w9fx-j79w: CVE-2026-109618 Detayları
GitHub Güvenlik Bildirimi GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 Detayları
Ubuntu Güvenlik Bildirimi: USN-7080-1 (PHP Vulnerabilities)
Debian Güvenlik Danışma Bülteni: DSA-5789-1 (PHP Security Update)
Remi’s RPM Repository: PHP 8.2, 8.3, 8.4 Security Releases for Enterprise Linux
CISA Güvenlik Bülteni (Ekim 2026): Emergency Guidance on Critical PHP RCE Flaws
CERT-EU Advisory 2026-018: Critical Vulnerabilities in PHP Runtime
JPCERT/CC (Japonya Siber Olay Müdahale Koordinasyon Merkezi) Uyarısı (22 Ekim 2026)
aaPanel Resmi Forumu ve Dokümantasyonu: PHP Installation and Upgrade Guide