PHP2Shell Açığı Rehberi: CVE-2026-109618 ve CVE-2026-109619

Yazan /


Konu çok uzun olduğu için önce bir özet geçeyim.

ÖZET

  • İki açık, tek olay. CVE-2026-109618 ve CVE-2026-109619, PHP çekirdeğinde 20 yılı aşkın süredir gizli kalan iki ayrı hataya dayanır. İkisi de kimlik doğrulaması gerektirmeyen (unauthenticated) uzak kod çalıştırma (RCE) sağlar. CVSS v4.0 ile ikisi de 9.2 (Critical).
  • “PHP2Shell” adı, bulguların ortak adı olarak kullanılıyor ve artık bir ürün/derleme adı değil; istismar zincirinin parçası olan genel bir exploit aracı için de kullanılıyor.
  • Yama 21 Ekim 2026 14:00 UTC’de yayınlandı: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. PHP 8.1 ve öncesi upstream güncelleme almıyor; PHP projesi 7.4 / 8.0 / 8.1 için minimal source backport yayımladı.
  • Neden gündemde: Açıklar yapay zekâ destekli bir araştırma süreciyle (OpenAI “Patch the Planet” girişimi; GPT‑5.6 Sol; Calif + Wiz) bulundu. 20 Ekim’de PHP ön-bildirim yaptı, ancak 20 Ekim’de detaylar sosyal medyada sızdı, bu yüzden PHP Foundation planlanandan erken açıklamak zorunda kaldı. Sızıntının ardından PoC exploit kamuya açıldı, ABD NSA nadir bir halk uyarısı yayımladı ve dünya genelinde hükümet siteleri kapatıldı. Yani bu, “sıradan bir güvenlik güncellemesi” değil, AI destekli sıfır gün keşfi ve küresel eşzamanlı müdahale anlatısıdır.
  • Japonya: Başbakan Sanae Takaichi konuştu — X hesabından, 21 Ekim gece. Japonya’da “cumhurbaşkanı” diye bir makam yoktur; devlet başkanı sembolik olarak İmparator’dur ve bu konuda İmparator’dan bir açıklama bulunmamaktadır. Resmî hükümet uyarısı Kabinet Ösekreterliği bünyesindeki Ulusal Siber Güvenlik Bürosu (NCO / 国家サイバー統括室) tarafından yapıldı. JPCERT/CC 22 Ekim’de ayrıca bir “注意喚起” (uyarı) yayımladı.
  • Paneller: Yedi panelin dördü (HestiaCP, CyberPanel, cPanel, Plesk, DirectAdmin) 24 saat içinde resmî duyuru yayımladı. CloudPanel paketleri yayımladı ama yazılı advisory’si yok. FastPanel hiçbir kanalda duyuru yapmadı — bu, operasyonel olarak en kritik boşluk.
  • Altın kural: “Ağ geçici önlemler yeterli mi?” Hayır. PHP advisory’si açıkça: “There are no complete mitigations, updating is the only safe choice.” Geçici önlemler yalnızca belirli saldırı yollarını kapatır.

PHP çalıştıran bir sunucunuz varsa ilk iş belli: PHP’yi yamalı bir sürüme güncellemek. 21 Ekim 2026’da açıklanan iki güvenlik açığı, CVE-2026-109618 ve CVE-2026-109619, kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya (RCE) izin verebiliyor. PHP projesi yamalı sürümleri aynı gün yayımladı: 8.5.12, 8.4.27, 8.3.36 ve 8.2.35.

Bu yazıda açıkların ne olduğunu, neden bu kadar hızlı gündeme geldiğini, Japonya’daki resmi çağrıyı, sunucuda sırayla yapılacakları ve yedi kontrol paneli için ayrı notları anlatıyorum. Kendi sunucusunu, VPS’ini ya da hosting hesabını yöneten geliştiriciler ve girişimciler için yazdım.

Olay hızlı ilerliyor. Bu metin 22 Ekim 2026 itibarıyla hazırladım. Panel duyuruları ve WAF kuralları birkaç saatte değişebilir, bu yüzden her adımdan önce resmi kaynağı kendiniz de kontrol edin.

PHP2Shell, iki kritik PHP açığının ortak adı

PHP2Shell, PHP’de bulunan iki ayrı güvenlik açığını anlatmak için kullanılan ortak addır. Açıklar CVE-2026-109618 ve CVE-2026-109619 numaralarıyla kayıtlı. CVE, bir güvenlik açığına verilen standart tanımlayıcı numaradır.

İki açık da kimlik doğrulaması gerektirmeyen uzaktan kod çalıştırma (RCE) imkânı veriyor. RCE, saldırganın hedef sistemde kendi kodunu çalıştırabilmesi demek. Her iki açık da CVSS v4.0 ölçeğinde 9.2 puan aldı. Bu, kritik seviye.

Ad, açıkları kullanan bir kavram kanıtı (PoC) kodu için de anılıyor. Bu kodun 21 Ekim’de kamuya açıldığı bildiriliyor. Bu yazıda adı yalnızca iki açığı anmak için kullanıyorum.

CVE-2026-109618 ve CVE-2026-109619 teknik olarak ne anlama geliyor

CVE-2026-109618: bellek sınırı aşıldığında bozulan veri

PHP, her isteğin kullanabileceği bellek miktarına memory_limit ayarıyla bir üst sınır koyar. Bu sınır aşılınca PHP isteği yarıda keser. Sorun, kesinti veri yapıları henüz tam kurulmadan gelirse başlar. İstek kapanırken temizlik kodu yarım kalmış veriyi geçerli sayabilir ve bellek bozulabilir.

PHP güvenlik duyurusu bu hatayı “OOM corruption” olarak adlandırıyor. OOM, “out of memory”, yani bellek tükenmesi demek.

CVE-2026-109619: bir isteğin durumu sonraki isteğe karışıyor

Bu açıkta bir isteğe ait iç durum, bellek serbest bırakıldıktan sonra da kullanılabiliyor. Buna “use-after-free” (serbest bırakıldıktan sonra kullanma) denir. Aynı worker’ın sonraki isteği bu eski duruma temas edebiliyor.

Oturum (session) ve yükleme ilerleme özelliklerinin de bilinen yollardan biri olduğu belirtiliyor. session.upload_progress.enabled ayarı varsayılan olarak açık. Bu yüzden geçici önlemler bölümünde bu ayarı ayrıca ele alıyorum.

SAPI ve mod_php neden önemli?

SAPI, PHP’nin web sunucusuyla konuşma biçimidir. Yaygın biçimler arasında Apache’nin mod_php modülü, PHP-FPM (PHP’nin ayrı süreç havuzları olarak çalıştığı yapı), FastCGI ve LiteSpeed’in LSAPI arayüzü var.

PHP güvenlik duyurusuna göre en yüksek risk mod_php‘de. Bu modda istismarın uygulama kodu çalışmadan önce tetiklenebildiği belirtiliyor. PHP-FPM ve diğer biçimler de ihmal edilmemeli. İki açığın risk profili birbirinden farklı.

Hangi PHP sürümleri etkileniyor, hangileri yamalı?

PHP 5.4.0 ve sonrası sürümler etkilenebilir. Calif araştırma ekibinin yazısına göre etkilenen yol bu sürümden itibaren var. CERT-EU de PHP 5’ten itibaren tüm sürümlerin etkilenebileceğini belirtiyor.

Bu, her sitenin kesin olarak etkilendiği anlamına gelmiyor. Ama sürümünüz yamalı listede değilse etkilenebilir kabul edip işlem yapın.

Yamalı sürümler: 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. PHP 8.1 ve öncesi için PHP projesi artık upstream güncelleme yayımlamıyor. Bunun yerine 7.4, 8.0 ve 8.1 için minimal kaynak yamaları paylaştı. Dağıtımınızın ya da uzun süreli destek (LTS) sağlayıcınızın geriye taşınmış yamasını (backport) da kullanabilirsiniz.

Açıklar neden bu kadar hızlı gündeme geldi?

Kısa cevap: açıklar yapay zekâ destekli bir araştırmada bulundu, detaylar planlanan tarihten önce sızdı ve bir PoC kodu kamuya açıldı. Bu üç etken, PHP ekibinin ve sistem yöneticilerinin önündeki zamanı daralttı.

Aşağıdaki tarihler araştırma notundaki kaynaklara dayanıyor:

TarihNe oldu
2004PHP’de bellek sınırıyla ilgili ilk RCE bulgusu anlatılıyor, istismar kamuya açılmıyor
2020PHP hata takibine bir OOM hatası bildiriliyor, o dönemde öncelikli görülmüyor
2024Bir güvenlik denetimi aynı sorunu yeniden buluyor, istismar kanıtlanamadığı için düzeltilmiyor
11 Ağustos 2026Calif ilk bulguyu PHP’ye bildiriyor
14 Ağustos 2026Calif RCE PoC’sini PHP ile paylaşıyor
20 Ekim 2026PHP ön bildirim yapıyor, detaylar sosyal medyada sızıyor
21 Ekim 2026Yamalı sürümler yayımlanıyor (planlanan saat 14:00 UTC), PoC kamuya açılıyor
22 Ekim 2026JPCERT/CC uyarı yayımlıyor

Başlıca dört etken var:

  • Yapay zekâ destekli keşif: Açıklar yapay zekâ destekli bir araştırma sürecinde bulundu. OpenAI’nin 21 Ekim 2026 tarihli yazısında şu cümle yer alıyor: “Calif identified a critical flaw using GPT-5.6 Sol as part of our Patch the Planet initiative, with Wiz also independently discovering and reporting both vulnerabilities.” Türkçesiyle: Calif, OpenAI’nin Patch the Planet girişimi kapsamında GPT-5.6 Sol ile kritik bir açık buldu; Wiz da iki açığı bağımsız olarak keşfedip bildirdi. OpenAI’ye göre, bildiği kadarıyla en gelişmiş yapay zekâ modelleri (frontier AI) bu açıkları saldırganlardan önce buldu. Bu, bakımcıların ve güvenlik sağlayıcılarının açıklamadan önce yama ve koruma hazırlayabileceği bir “savunma penceresi” (Defender’s Window) açtı anlamına geliyor.
  • Sızıntı ve PoC: Ön bildirimin yapıldığı 20 Ekim’de detaylar sosyal medyada sızdı. PHP ekibi açıklamayı planlanandan önce yapmak zorunda kaldı. Ardından çalışan bir PoC kodu yayımlandı.
  • Resmi uyarılar: NSA kamuya açık bir uyarı yayımladı. CERT-EU ve İngiltere’nin NCSC’si kuruluşlara derhal yama uygulamalarını istedi.
  • Kamu sitelerinin kapatılması: Araştırma notuna göre birkaç ülkede kamu kurumları, yama tamamlanana kadar sitelerini geçici olarak kapattı.

Ölçek de büyük. Araştırma notu, Palo Alto Networks Unit 42’nin internete açık ve potansiyel olarak etkilenebilir 22,6 milyon PHP örneği saydığını aktarıyor. Bu rakam her birinin saldırıya uğradığı anlamına gelmiyor. Yalnızca riskin boyutunu gösteriyor.

WordPress, Drupal, Joomla veya phpMyAdmin kullanıyorsanız bu açık sizi de ilgilendirir. Araştırmacılar bu uygulamaların test edilen sürümlerinde kimlik doğrulaması olmadan RCE gösterdiklerini bildirdi. Açığın kökü PHP çekirdeğinde olduğu için uygulamanın kendi güncellemesi tek başına yetmez.

Saha istismarı konusunda kaynaklar neden çelişiyor

Açığın gerçek saldırılarda kullanılıp kullanılmadığı konusunda kaynaklar ayrışıyor:

  • watchTowr: 21 Ekim itibarıyla kendi bal küpü (honeypot) ağında istismar gözlemlediğini bildirdi.
  • Cloudflare’ın CTO’su: İlk aşama saldırıların gerçekleştiğini doğruladıklarını söyledi.
  • Sophos: Yayın tarihi itibarıyla sahada aktif istismar bildirilmediğini yazdı.
  • Rapid7: Bulgunun bağımsız olarak yeniden üretildiğine dair işaretler olduğunu ve kullanılabilir bir istismar kodunun yakında yayımlanmasının beklendiğini belirtti.

Bu çelişkiyi tek bir cümleyle kapatmak doğru olmaz. Pratik sonuç şu: PoC kodu kamuya açık, Cloudflare ise erken aşama saldırılar gördüğünü söylüyor. Bu nedenle aciliyet moduyla hareket etmek makul. Büyük ölçekli bir botnet kampanyası olduğu ise henüz kanıtlanmış değil.

Japonya’da resmi çağrı ve Başbakan Takaichi’nin paylaşımı

Japonya’da cumhurbaşkanlığı makamı yoktur. Devlet başkanı anayasal olarak sembolik bir figür olan İmparator’dur. Hükümeti ise Başbakan yönetir. Bu nedenle Japonya’daki resmi çağrı Başbakan Sanae Takaichi’den geldi. Notta, İmparator’dan bu konuda bir açıklama bulunmadığı yazıyor.

Takaichi, 21 Ekim 2026 akşamı X hesabından paylaşım yaptı. Paylaşımda site sahiplerinden iki şey istendi: sitelerinde PHP olup olmadığını kontrol etmeleri ve Japonya saatiyle 23:00’te (14:00 UTC) yayımlanacak yama paketini mümkün olan en kısa sürede uygulamaya hazır olmaları.

Haber kaynaklarına göre, yamayı hemen uygulayamayan site sahipleri için geçici kapatma da yedek bir seçenek olarak anıldı. Mainichi/Kyodo haberine göre Takaichi, şirketler hemen harekete geçemiyorsa siteleri geçici olarak çevrimdışı almanın kötüye kullanımı önlemek için etkili bir güvenlik önlemi olduğunu söyledi. Araştırma notuna göre de Japonya’da bazı bakanlık siteleri ve bankalar PHP açıklarının ardından bakım için kapatıldı.

Araştırma notuna göre Ulusal Siber Güvenlik Bürosu (NCO) aynı gün benzer bir uyarı yayımladı. JPCERT/CC ise 22 Ekim’de ayrı bir uyarı yayımladı. Araştırma notuna göre Sakura Internet bazı hizmet işlevlerini askıya aldı.

Sunucunuzda yapılacaklar: beş adım

Önce PHP’yi yamalı sürüme geçirin. Ardından PHP’nin çalıştığı her yeri bulun, yamayı beklerken geçici önlemleri uygulayın ve yamasız sistemlerde olay incelemesi yapın.

PHP’nin 21 Ekim 2026 sürüm duyuruları bu konuda açık: “There are no complete mitigations, updating is the only safe choice.” Yani eksiksiz bir geçici önlem yok. Tek güvenli yol güncelleme.

Adım 1 — PHP’yi yamalı sürüme güncelleyin

Ne yapacaksınız: PHP’yi yamalı bir sürüme yükseltin. Hedef sürümler: 8.5.12, 8.4.27, 8.3.36 ve 8.2.35.

Neden: Açığın kökü PHP çekirdeğinde. Bu yüzden kesin çözüm, PHP’nin yamalı sürümüdür.

Dağıtımınızın paket deposunu kullanıyorsanız apt upgrade veya yum update ile yamalı paketi alabilirsiniz. Araştırma notuna göre Remi deposu bu güncellemeyi yayımlamayacak. Bu durumda dağıtım paketlerine geçmek ya da kaynaktan derlemek öneriliyor.

Sürümü yalnızca php -v ile doğrulamayın. Bazı sağlayıcılar yamayı aynı sürüm numarasıyla, yeni bir yapı tarihiyle yayımlıyor. Bazıları ise geriye taşınmış yamayı daha düşük bir sürüm numarasıyla sunuyor. Bu yüzden changelog ya da yapı tarihine bakın. cPanel/CloudLinux sunucusunda örnek kontrol:

rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'

En güvenilir kontrol, gerçek bir HTTP isteğiyle phpinfo() sayfasından web SAPI sürümüne bakmaktır. Komut satırındaki PHP ile web sunucunuzun kullandığı PHP farklı olabilir.

Adım 2 — PHP envanteri çıkarın

Ne yapacaksınız: Sunucunuzda PHP’nin çalıştığı her yeri bulun.

Neden: Bu adım çoğu operatörün atladığı adım. Bir PHP kopyasını yamayıp diğerini unutmak, unutulan kopyayı açıkta bırakır.

PHP yalnızca hosting hesaplarında çalışmaz. Şunlarda da olabilir:

  • Kontrol panelinin kendi PHP çalışma zamanı ve panel içindeki phpMyAdmin ya da webmail
  • Docker imajları ve konteynerler
  • Üçüncü parti yazılımların içine gömülü PHP
  • Cron işleri ve komut satırı betikleri
  • LiteSpeed ya da FrankenPHP gibi web sunucuları

Bu listedeki her yer yamalanmadan işi bitmiş saymayın.

Adım 3 — Geçici önlemleri uygulayın, sınırlarını bilerek

Ne yapacaksınız: Yamayı beklerken aşağıdaki ayarları uygulayın ve PHP worker’larını yeniden başlatın.

Neden: Geçici önlemler yalnızca bazı saldırı yollarını daraltır. Sunucuyu güvenli hale getirmez.

  • session.upload_progress.enabled = 0: Ayarı gerçek global php.ini dosyasında, FPM havuzunda ya da sunucu yapılandırmasında yapın. ini_set() ve .user.ini güvenilir değil, uygulama bunları geçersiz kılabilir. Ayar PHP_INI_PERDIR olduğu için kiracılar .user.ini ya da .htaccess ile yeniden açabilir.
  • PHP 8.5 kullanıyorsanız: fatal_error_backtraces = 0 ekleyin. Araştırma notuna göre bu, yalnızca doğrulanmış bir yolu kapatıyor.
  • Worker’ları yeniden başlatın: Ayarlar, çalışan işlemleri yenilemeden etkili olmaz. Web sunucusunu yeniden yüklemek her zaman yetmez. LiteSpeed 5.3 ve üzerinde PHP işlemleri ayrık (detached) modda çalışır. Bu modda lsws yeniden başlatılsa bile lsphp işlemleri yenilenmez, killall -9 lsphp gerekir.
  • memory_limit = -1 tartışmalı: PHP güvenlik duyurusu bu ayarı CVE-2026-109618 için öneriyor. CyberPanel ise ayrım yapmadan uygulanmamasını istiyor. Bellek sınırını kaldırmak, sunucunun belleğini tüketme riskini artırır. Bu kararı sunucunuzun kaynaklarına göre siz verin.
  • İstek boyutu: Dosya yüklemesi yoksa post_max_size = 8M, gerekiyorsa 32M. upload_max_filesize bu değerin altında kalmalı.
  • Hata mesajlarını susturmayın: display_errors, error_reporting ya da @ ile hataları gizlemek bir açığı kapatmaz, yalnızca tanılamayı zorlaştırır.

Havuz seviyesinde ayar örneği (ortamınıza göre uyarlayın):

php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[fatal_error_backtraces] = 0     ; yalnızca 8.5 havuzları

Bu değerleri global.conf dosyasına eklemeyin. php_admin_value global bölümde kullanılamaz ve PHP-FPM “Array are not allowed in the global section” hatasıyla başlamaz. Bellek sınırını RLIMIT_AS ya da RLIMIT_DATA ile koymayın. Araştırma notuna göre bu, hassas bir bellek tahsisi hatası yolunu tetikleyebilir. Konteyner ya da cgroup sınırı kullanacaksanız, sınırın yalnızca etkilenen worker’ı sonlandırmasını sağlayın.

Adım 4 — WAF ve ağ katmanına kalkan ekleyin

Ne yapacaksınız: Sunucunun önüne bir WAF (web uygulama güvenlik duvarı) koyun ya da mevcut kuralları güncel tutun.

Neden: WAF, yamanın yerini tutmaz. Araştırma notunda aktarılan CloudLinux açıklamasına göre mevcut kurallar kamuya açık istismar aracını ve istek örüntülerini engelliyor. Ancak CVE-2026-109618’in bellek tükenmesi yolunu henüz hiçbir kural kapatmıyor.

Notta geçen kalkanlar:

  • CloudLinux Imunify360: WAF kuralları 8.83, 8.84 ve 8.85 sürümleriyle kademeli olarak genişledi. Otomatik dağıtılıyor.
  • Cloudflare: WAF kurallarını acilen güncellediğini belirtti.
  • AWS WAF: CVE-2026-109618 için gövde boyutu kuralı, CVE-2026-109619 için ise oturum ilerleme verisini hedef alan özel bir kural yayımladı.

Topluluk tarafından önerilen, multipart/form-data isteklerini topyekûn engelleyen ModSecurity kuralları tüm yüklemeleri ve POST isteklerini bozabilir. Bu kuralları satıcı onayı olmadan uygulamayın.

Panel portlarını da kapatın. CloudPanel’de 8443, FastPanel’de 8888 gibi portları yalnızca kendi IP adresinizden erişilebilir yapın.

Adım 5 — Yamasız sistemlerde olay incelemesi yapın

Ne yapacaksınız: İnternete açık ve yamasız kalmış sistemlerde olay incelemesi yapın.

Neden: Yamalanmadan önce bu açığı kullanan biri sunucuya girmiş olabilir. Veri ihlali ile sistemin ele geçirilmesi riskini birlikte değerlendirmek gerekir.

Şu alanlara bakın:

  • PHP oturum dizinlerindeki anormal dosyalar
  • Web kökünde yeni ya da değişmiş dosyalar
  • Planlanmış görevler (cron) ve beklenmeyen zamanlanmış işler
  • /tmp altındaki şüpheli dosyalar
  • Kullanıcı hesaplarında authorized_keys ve crontab değişiklikleri
  • Yeni web shell izleri

Sophos’un araştırma notunda aktarılan göstergeleri arasında alışılmadık uzun ağ oturumları, yanlış yazılmış süreç adları ve beklenmeyen konumlarda çalışan meşru görünümlü süreçler var. Şüphe varsa sistemi ağdan ayırın, kanıtları koruyun ve uzman destek alın.

Kontrol panelleri: yedi panel, yedi farklı yol

Panel kullanıyorsanız iki katman var: müşteri sitelerinin PHP’si ve panelin kendi PHP çalışma zamanı. İkisi ayrı ayrı yamalanmalı. Aşağıdaki tablo durumu özetliyor. Ayrıntılar için her panelin kendi duyurusunu da kontrol edin.

PanelResmi duyuruPanelin kendi PHP’siDikkat edilecek nokta
HestiaCPForum ve GitHubAyrı paket: hestia-phpİki ayrı PHP çalışma zamanı
CloudPanelYalnızca GitHub yorumuclp-php-fpm (PHP 8.1)APT öncelik (pin) engeli
CyberPanelBlog yazısıAyrı lsphp kopyasıÜç ayrı PHP envanteri
cPanel & WHMDestek makalesi ve sürüm notlarıPanelin PHP’si de yamalanıyorea-php ve CloudLinux sürüm farkı
PleskDestek makalesi ve changelogsw-engineDomain başına ayrı FPM birimleri
DirectAdminForum (changelog’da kayıt yok)DirectAdmin’in kendi derlemesiPHP 8.1 derleme hatası
FastPanelİncelenen resmi kanallarda bulunamadı/opt/phpXXDağıtım paketlerinin dışında

HestiaCP

HestiaCP’nin forum duyurusu 21 Ekim 2026’da yayımlandı. Duyuruya göre sunucuda iki PHP çalışır. Birincisi, barındırılan siteler için Sury deposundan gelen PHP-FPM (/etc/php/<surum>/fpm/). İkincisi, panelin kendi paketi hestia-php. Birini yamamak diğerini açıkta bırakır.

Yapılacaklar:

  1. Ne yapacaksınız: Sury deposuna geçin. Panelin paylaştığı geçiş adımlarını izleyin. Betiği çalıştırmadan önce okuyun, çünkü mevcut apt kaynak dosyalarını değiştirir. Neden: Barındırılan sitelerin PHP-FPM sürümleri bu depodan geliyor.
  2. Ne yapacaksınız: Site PHP’lerini yükseltin:apt update apt install --only-upgrade 'php*'Neden: Barındırılan siteler bu PHP sürümlerini kullanır; yükseltilmeyen sürüm açıkta kalır.
  3. Ne yapacaksınız: Tüm worker’ları yeniden başlatın. Yalnızca mod_php kullanıyorsanız systemctl restart apache2 komutunu da çalıştırın:for v in $(ls /etc/php/); do systemctl restart php$v-fpm 2>/dev/null; done systemctl restart apache2 # yalnızca mod_php kullanılıyorsaNeden: Yama ve ayarlar, çalışan worker’lar yeniden başlatılmadan etkili olmaz.
  4. Ne yapacaksınız: Panelin PHP’sini yükseltin: apt update && apt upgrade, ardından systemctl restart hestia. Panel çalışma zamanı hestia-php 8.5.12 olarak gelir. Neden: Bu adım atlanırsa panel hâlâ açıkta kalır.
  5. Ne yapacaksınız: Doğrulayın: apt.hestiacp.com deposunun Jammy Packages listesinde hestia-php 8.5.12-1+ubuntu22.04, Bookworm için hestia-php 8.5.12-1+debian12 görünmeli. Neden: Paket listesi, panelin yamalı sürümünün gerçekten yayımlandığını gösterir.

Dikkat edilecekler:

  • Ubuntu Jammy ve Debian Bookworm için paket doğrulandı. Debian Bullseye ve Ubuntu Focal için paketler 22 Ekim itibarıyla hâlâ derleniyordu. ARM64 paketleri de gecikmişti.
  • Panel şablonları HestiaCP güncellemesi ya da v-rebuild-user ile yeniden üretiliyor. Düzenlemeden önce kopyasını alın. Şablonlar /usr/local/hestia/data/templates/web/php-fpm/ altında.
  • Sürüm değiştirmek için Web Domains → Edit → PHP-FPM version yolunu izleyin. Komut satırında v-add-web-php 8.3, v-change-sys-php 8.0 ve v-list-sys-php kullanılabiliyor.
  • Panelde iptables tabanlı bir güvenlik duvarı var, ancak duyuruda php2shell için ModSecurity imzası yayımlanmadı.

CloudPanel

CloudPanel’in durumu daha belirsiz. GitHub’daki konuda (#823) kurucu, PHP 8.1 için ilgili güvenlik yamalarını geriye taşımak üzerinde çalıştıklarını ve mümkün olan en kısa sürede dağıtacaklarını yazdı. Yazılı bir güvenlik duyurusu yok. Değişiklik günlüğünün (v2.5.4) da bu olaya dair bir kaydı yok. Site PHP’leri için paketler yayımlanmış görünüyor. Araştırma notuna göre 22 Ekim sabahı 05:58 UTC itibarıyla PHP 8.1 yaması henüz çıkmamıştı.

Yapılacaklar:

  1. Ne yapacaksınız: Site PHP’lerini yükseltin: sudo apt update && sudo apt upgrade && sudo systemctl restart 'php*-fpm'. Neden: Servisler yeniden başlatılmazsa eski worker’lar çalışmaya devam edebilir.
  2. Ne yapacaksınız: Doğrulayın: apt policy php8.5-fpm çıktısında 8.5.12-1+clp-<codename> görünmeli. Neden: CloudPanel kendi deposunu öncelik 1000 ile pinliyor; Ubuntu’nun yamalı paketi bu yüzden seçilmeyebilir.
  3. Ne yapacaksınız: Panelin PHP’si 8.1’de kalıyorsa yamayı bekleyin. Beklerken 8443 portunu yalnızca kendi IP adresinize açın. Ayarı Admin Area → Security → Firewall (UFW) üzerinden yapın. Neden: Notta bu, en etkili ara önlem olarak geçiyor.
  4. Ne yapacaksınız: Her /etc/php/*/fpm/pool.d/*.conf dosyasına havuz ayarlarını ekleyin. global.conf dosyasını bu işlemin dışında tutun. Neden: Site sahipleri PHP ayarlarını uygulama seviyesinde değiştirebilir; memory_limit için havuz seviyesinde ayar şarttır.
  5. Ne yapacaksınız: Yamasız kalan 7.x-8.1 PHP-FPM servislerini devre dışı bırakın (mask). Neden: Bir CloudPanel sunucusunda birden fazla PHP-FPM servisi aynı anda çalışabilir ve bunların bir kısmı yamasız kalabilir.

Dikkat edilecekler:

  • CloudPanel kendi deposunu 1000 önceliğiyle pinliyor. Araştırma notuna göre bu nedenle Ubuntu’nun yamalı paketleri tercih edilmeyebilir. Sury deposu eklenecekse öncelik 1001 olmalı. apt policy çıktısıyla kontrol edin.
  • CloudPanel PHP-FPM servislerini konteynerde çalıştırmaz. Servisler host üzerinde (php8.2-fpm … php8.5-fpm) çalışır.
  • Site sahipleri PHP ayarlarını uygulama seviyesinde değiştirebilir. Bu yüzden memory_limit için havuz seviyesinde ayar şart.
  • Cloudflare’ın acil WAF kuralları CloudPanel’a ait değil.

CyberPanel

CyberPanel, 21 Ekim 2026’da blog yazısıyla açıklama yaptı. Yazı 22 Ekim’e kadar güncellendi. Bu panelin mimarisi diğerlerinden farklı. Siteler PHP-FPM yerine OpenLiteSpeed’in LSPHP (LSAPI) katmanında çalışıyor. Site PHP’leri /usr/local/lsws/lsphpXX/ altında. Panelin kendi PHP kopyası ise /usr/local/lscp/fcgi-bin/lsphp dosyasında. Ubuntu paketlerini güncellemek bu dosyayı değiştirmez.

Yapılacaklar:

  1. Ne yapacaksınız: lsphp85*, lsphp84*, lsphp83* ve lsphp82* paketlerini imzalı LiteSpeed deposundan yükseltin. Neden: Ubuntu paketlerini güncellemek, LiteSpeed’in ayrı lsphp dosyalarını ve panelin kopyasını değiştirmez.
  2. Ne yapacaksınız: Panel kopyasını ayrıca yenileyin. /usr/local/lscp/fcgi-bin/lsphp dosyasını güncel /usr/local/lsws/lsphp83/bin/lsphp ile atomik olarak değiştirin. Sahiplik ve izinleri koruyun, SHA256 değerini doğrulayın. Panelin çalışma zamanı farklıysa 8.3 yolunu körlemesine kullanmayın. Neden: Panelin kendi lsphp kopyası, site PHP’lerinin güncellenmesiyle otomatik değişmez.
  3. Ne yapacaksınız: Worker’ları yenileyin:killall -9 lsphp && systemctl restart lswsNeden: lsws yeniden başlatmak, ayrık (detached) çalışan worker’ları tek başına öldürmez.
  4. Ne yapacaksınız: Gerçek bir HTTP isteğiyle test edin. Panel girişini, phpMyAdmin’i ve sitelerinizi deneyin. Neden: php -v yalnızca komut satırındaki sürümü gösterir; web üzerinden çalışan sürüm ayrıca doğrulanmalı.
  5. Ne yapacaksınız: OPcache’i birlikte güncelleyin. Neden: Eski OPcache modülüyle çekirdek güncellemesi eksik kalır.

Dikkat edilecekler:

  • “PHP-FPM Switcher” ve “php-fpm” adlı bir site resmi dokümantasyonda bulunamadı. Bunları kullanmayın. Doğru yol: Websites → List Websites → Manage → Modify Website → PHP Version. Ayarlar için: Server → PHP → Edit PHP Configs.
  • ModSecurity, OpenLiteSpeed ile gelir. Dashboard → Security → ModSecurity Conf. üzerinden yönetilir. Denetim günlüğü /usr/local/lsws/logs/auditmodsec.log dosyasında. Satıcının php2shell’e özel bir kuralı yok. OWASP CRS gibi genel kurallar tek kalkan.

cPanel & WHM

cPanel’in destek makalesi (22 Ekim) ve 21 Ekim tarihli sürüm notları, hem paneli hem EasyApache 4 PHP paketlerini kapsıyor. Panelin kendi PHP’si, Roundcube webmail dahil, yamalanıyor.

Notta yer alan EasyApache 4 (ea-php) sürümleri: ea-php82 için 8.2.35, ea-php83 için 8.3.36, ea-php84 için 8.4.27, ea-php85 için 8.5.12. 7.4, 8.0 ve 8.1 için de paketler var: ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5. CloudLinux’in ea-php paketlerinin sürüm numaraları upstream’den düşük görünebilir. Bu yüzden changelog ile doğrulayın.

Yapılacaklar:

Ne yapacaksınız: Paket depolarını yenileyin, PHP paketlerini güncelleyin, worker’ları yeniden başlatın ve changelog ile doğrulayın:

yum clean all && yum makecache
/scripts/rpmup
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'

Neden: Yama, PHP paketleriyle birlikte gelir; worker’lar yeniden başlatılmadan eski kod çalışmaya devam edebilir. Doğrulamayı sürüm numarasıyla değil changelog ile yapın.

CloudLinux kullanıyorsanız yum clean all && yum update "ea-php*" alternatiftir.

Yapılandırma yolları:

  • /opt/cpanel/ea-php##/root/etc/php.ini
  • /opt/cpanel/ea-php##/root/etc/php.d/
  • Havuz şablonu: /var/cpanel/userdata/[account]/[domain].php-fpm.yaml. .conf dosyası bu şablondan üretilir, elle yapılan değişiklikler silinir. Değişikliği şablona yapıp /scripts/php_fpm_config çalıştırın.
  • CloudLinux PHP Selector: /etc/cl.selector/global_php.ini

Dikkat edilecekler:

  • Kiracı .user.ini ya da .htaccess ile session.upload_progress.enabled ayarını yeniden açabilir. Ayarı FPM havuzunda php_admin_value ile zorunlu kılın. .htaccess ile yapılan php_value ve php_admin_value de güvenilir değil.
  • mod_php en riskli yapılandırma. Araştırma notuna göre cPanel, 8.0 ve sonrası için DSO desteklemiyor. Ancak 7.4 ve 8.0 ELS hesapları DSO çalıştırabiliyor. httpd -M | grep php_module ile kontrol edip FPM ya da LSAPI’ye taşıyın.
  • Application Manager (Passenger) kendi yorumlayıcısını kullanıyorsa ea-php güncellemesi onu değiştirmez. EA4 25.91 ile gelen Passenger 6.2.1 güncellemesini ayrıca alın ve yeniden başlatın.
  • CloudLinux PHP Selector ile MultiPHP farklı sürüm gösterebilir. İkisi de yamalanmalı ve yeniden başlatılmalı.
  • 7.4’ten eski sürümler için TuxCare ELS gibi ücretli bir çözüm ya da taşıma gerekir.

Plesk

Plesk’in destek makalesi 20 Ekim’de yayımlandı, 22 Ekim’de güncellendi. Obsidian değişiklik günlüğünde 21 Ekim tarihli yamalar yer alıyor. Plesk’in PHP’sinde sürüm numaraları aynı kalırken yapı tarihi değişti. /opt/plesk/php/8.3/bin/php -v çıktısında built: Oct 21 2026 görmelisiniz.

Panelin kendi PHP motoru sw-engine de yamalanmalı. Plesk Obsidian 18.0.80 Update 11 ve 18.0.81 Update 4 bu yamayı içeriyor. Araştırma notuna göre yamalanmadan önce panelin de RCE’ye açık olduğu belirtiliyor.

Yapılacaklar:

Ne yapacaksınız: Plesk’i güncel sürüme getirin, PHP’yi ve paneli yeniden başlatın:

plesk installer --select-release-current --upgrade-installed-components
/opt/plesk/php/8.3/bin/php -v
systemctl restart plesk-php83-fpm
systemctl restart sw-engine
systemctl start sw-cp-server

Neden: Panelin kendi PHP motoru (sw-engine) yamalanmazsa panel de RCE’ye açık kalır. Sürüm numarası aynı kaldığı için yapı tarihine bakmak gerekir.

Beklenen çıktı: PHP 8.3.36 (cli) (built: Oct 21 2026 08:04:57) (NTS).

Domain başına ayrı FPM birimleri (ör. plesk-php83-fpm_domain.tld_370) ayrıca tam adlarıyla yeniden başlatılmalı. systemctl restart plesk-php83-fpm bu birimleri etkilemez.

Yapılandırma yolları:

  • Panelin kendi php.ini dosyası: /usr/local/psa/admin/conf/php.ini (Windows’ta %plesk_dir%\admin\php.ini)
  • Arayüz: Tools & Settings → PHP Settings → php.ini editörü
  • Domain bazında: Websites & Domains → domain → PHP → ek PHP ayarları

Dikkat edilecekler:

  • Domain bazlı PHP ayarları ekranı sabit bir direktif listesi kullanıyor. session.upload_progress.enabled ve fatal_error_backtraces bu listede yok. php.ini editörünü ya da özel PHP-FPM yapılandırmasını kullanın.
  • Kiracı izinlerini daraltın. “Common PHP settings management” ve “PHP version and handler management” izinlerini kapatmazsanız kiracı memory_limit değerini yeniden sınırsız hale getirebilir.
  • Yamayı hemen uygulayamıyorsanız paneli durdurmayı düşünebilirsiniz (systemctl stop sw-cp-server). Araştırma notunda bu, Plesk destek tartışmasında geçen bir önlem olarak yer alıyor. Panel kullanılamaz hale gelir. Bunu yalnızca risk değerlendirmesinden sonra uygulayın.
  • WAF: Tools & Settings → Web Application Firewall. Atomic Standard, OWASP CRS, Comodo ve Atomic Advanced seçenekleri var. CVE’ye özel bir kural yok. OWASP CRS seçilirse WordPress’in bir kısmı, webmail ve dosya paylaşımı çalışmayabilir.

DirectAdmin

DirectAdmin ekibinden bir yetkili, forumda 21 Ekim 2026 sabahı yeni bir DA sürümünün current ve stable kanallarına çıktığını yazdı. Bu sürümle PHP 8.5, 8.4, 8.3 ve 8.2 son sürüme getiriliyor. PHP 8.1, 8.0 ve 7.4 için yamalar eklendi. 7.3 ve daha eski sürümler için henüz yama yok. Araştırma notuna göre DirectAdmin’in kamuya açık değişiklik günlüğünde bu kayıt yok.

Yapılacaklar:

Ne yapacaksınız: DirectAdmin’i güncelleyin, PHP’yi yeniden derleyin ve yapılandırmayı yenileyin:

da update
da build php
da build versions
da build rewrite_confs

Neden: Yamalı PHP sürümleri DirectAdmin’in kendi derleme aracıyla geliyor. da build php çalıştırılmazsa sunucudaki PHP eski kalır.

  • DA kendiliğinden güncellenir, ancak PHP güncellemesini elle tetiklemeniz gerekir. CustomBuild cron özelliğini açarsanız bu adım otomatikleşir.
  • da build versions çıktısında yıldızlı sürüm, aynı upstream sürümün yeni yamalarla derlendiği anlamına gelir.
  • Yama dosyasını şu yolda kontrol edin: /usr/local/directadmin/custombuild/patches/php-7.4/143-php-7.4-cve-2026-109618.patch

Yapılandırma yolları:

  • /usr/local/phpXX/lib/php.ini
  • Havuz ayarları: Admin → Custom Httpd Configuration → domain.com: php-fpm 5.x → ikinci metin kutusu (|CUSTOM2|)
  • Genel ayarlar: /usr/local/directadmin/data/templates/custom/php-fpm.conf.custom1 ve .custom2

Dikkat edilecekler:

  • user_ini.filename = ".user.ini" varsayılan olarak açık. Kiracı kendi php.ini dosyasını düzenleyebilir. session.upload_progress.enabled PHP_INI_PERDIR olduğu için php_admin_value kullanın ya da user_ini.filename ayarını kapatın.
  • PHP 8.1 derlemesi bazı sistemlerde zend_vm_execute.h hatasıyla başarısız olabiliyor. Bu durumda hesapları desteklenen bir sürüme taşıyın.
  • CloudLinux kullanıyorsanız iki ayrı PHP yığını olabilir: CustomBuild derlemesi (/usr/local/phpXX) ve CloudLinux ALT-PHP (/opt/alt/phpXX). İkisini de yamalayın.

FastPanel

FastPanel, en belirsiz panel. Araştırma notuna göre değişiklik günlüğü, blog, GitHub ve güvenlik sayfası gibi incelenen resmi kanallarda bu olayla ilgili bir duyuru bulunamadı. Sosyal medya ve Discord kontrol edilemedi. Bu yüzden “duyuru yapılmadı” demek yerine “bulunamadı” demek doğru. Değişiklik günlüğünün son kaydı 25 Aralık 2025 tarihli (Release 1.11.87).

Önemli bir fark var: FastPanel PHP’yi kendisi derleyip /opt/phpXX/ altına kuruyor. Dağıtım paketi değil. Örnek: /opt/php74/bin/php. Bu yüzden apt upgrade, Ubuntu güvenlik bültenleri ya da Sury bu PHP sürümlerine ulaşmaz.

Resmi kılavuz olmadığı için aşağıdaki adımlar, notun belgelenmiş mimariden çıkardığı önerilerdir:

  1. Ne yapacaksınız: Envanter çıkarın. Settings → Applications üzerinden kurulu PHP dallarını görün. Her biri için /opt/phpXX/bin/php -v komutunu çalıştırın. Neden: FastPanel PHP’yi kendisi derleyip /opt/phpXX/ altına kuruyor; dağıtımın PHP paketleri bu sürümleri güncellemez.
  2. Ne yapacaksınız: Yükseltmeyi panelin Applications yükleyicisiyle yapın. Yamalı build yayımlanıp yayımlanmadığı doğrulanamadı. FastPanel destek ekibine yazın ve yanıt gelene kadar tüm PHP sürümlerini yamasız kabul edin. Neden: Yamalı build’in yayımlandığı doğrulanamadı; yanıt gelene kadar yamasız varsaymak daha güvenli.
  3. Ne yapacaksınız: Worker’ları yeniden başlatın. Her dal için ilgili PHP-FPM servisini (Services bölümünden ya da systemctl restart <phpXX> ile) yeniden başlatın. Apache module (MPM ITK) kullanan sitelerde Apache backend’i de yeniden başlatın. Neden: Araştırma notuna göre Apache module (MPM ITK) mod_php anlamına gelir ve en yüksek riskli SAPI’dir.
  4. Ne yapacaksınız: Dal bazlı ayarları değiştirin. Side menu → PHP → Settings üzerinden session.upload_progress.enabled = 0, memory_limit ve post_max_size ayarlarını yapın. PHP 8.5 için fatal_error_backtraces = 0 ekleyin. Neden: Site bazlı ayarları kullanıcı değiştirebilir; yönetici tarafından zorlanabilen dal bazlı ayar gerekir.
  5. Ne yapacaksınız: Apache-module sitelerini FastCGI ya da PHP-FPM’e taşıyın. Neden: Notta, yamalı bir dal seçmenin tek yolunun bu olduğu yazıyor.
  6. Ne yapacaksınız: Panel portunu kısıtlayın. Panel portu 8888’i yalnızca kendi IP adresinizden açın. Panelin kendi PHP’sini de envantere ekleyin. Neden: Panelin kendi PHP’si de PHP servis eden bir yüzey; envantere alınmazsa unutulabilir.

Dikkat edilecekler:

  • Üçüncü taraf “/usr/bin/php sembolik bağlantısını değiştirin” rehberleri FastPanel için güvenli değil. FastPanel, kullanıcı başına CLI PHP sürümünü panelden yönetiyor.
  • FastPanel’de WAF yok. Settings → Applications üzerinden Fail2ban kurulabiliyor.
  • Yama gelene kadar 8.1 ve daha eski dalların upstream yaması olmadığını unutmayın. Bu sürümleri IP allowlist ya da VPN ile izole edin.

Sık sorulan sorular

PHP2Shell’i sadece PHP güncellemesiyle kapatabilir miyim?

Evet, yamalı PHP sürümüne geçmek bu açığı kapatmanın tek güvenli yolu. PHP güvenlik duyurusu geçici önlemlerin eksiksiz olmadığını belirtiyor. Geçici önlemler yalnızca belirli saldırı yollarını daraltır.

PHP’yi güncelledim, hâlâ etkilenebilir miyim?

Olabilir. Kontrol panelinin kendi PHP’si, LiteSpeed’in ayrı lsphp kopyası ya da Docker imajı eski kalmış olabilir. Eski worker’lar yeniden başlatılmadıysa eski kodu çalıştırmaya devam edebilir. Sürümü php -v ile değil, gerçek bir HTTP isteğiyle doğrulayın.

PHP 8.1 kullanıyorum, ne yapmalıyım?

PHP projesi 8.1 için upstream güncelleme yayımlamıyor. Dağıtımınızın ya da hosting sağlayıcınızın geriye taşınmış yamasını kontrol edin. PHP projesi 7.4, 8.0 ve 8.1 için minimal kaynak yamaları yayımladı. Yama yoksa en güvenli yol desteklenen bir sürüme geçmek. Bu süreçte panel ve yönetim portlarını IP ile kısıtlamak ara önlem olarak öneriliyor.

WAF kullanıyorsam yeterli mi?

Hayır. Araştırma notuna göre mevcut WAF kuralları bilinen istismar örüntülerini engelliyor. Ancak CVE-2026-109618’in bellek tükenmesi yolunu henüz hiçbir kural kapatmıyor. WAF, yamanın yerini tutmaz.

WordPress sitem için ne yapmalıyım?

WordPress’in kendi güncellemesi bu açığı kapatmaz, çünkü açık PHP çekirdeğinde. Sunucudaki PHP sürümünü yamalayın, ardından yukarıdaki envanter ve olay incelemesi adımlarını uygulayın.

Yamayı bugün uygulayın, envanteri bu hafta bitirin

PHP2Shell, kimlik doğrulaması gerektirmeyen ve CVSS v4.0’a göre 9.2 puan alan iki açığın ortak adı. Yamalı sürümler 21 Ekim 2026’da yayımlandı. Eksiksiz bir geçici önlem yok. Yamalamak tek güvenli yol.

İlk yapmanız gereken 3 şey

  1. Bugün: PHP’nin yamalı sürümünü kurun, çalışan worker’ları yeniden başlatın ve gerçek bir HTTP isteğiyle doğrulayın.
  2. Bu hafta: PHP envanterinizi çıkarın (panelin kendi PHP’si dahil) ve kullanılmayan ya da destek süresi dolmuş (EOL) sürümleri kapatın.
  3. Hemen: Yamalı sürüme geçemediğiniz sunucularda panel portunu yalnızca kendi IP adresinizden erişilebilir yapın. Yamasız siteler için çevrimdışı almayı ya da erişimi kısıtlamayı değerlendirin.

Olay hâlâ gelişiyor. Panel duyuruları, WAF kuralları ve CISA’nın Known Exploited Vulnerabilities listesi değişebilir. Bu yazıdaki bilgiler 22 Ekim 2026 itibarıyla geçerli.

Kaynaklar

PHP ve birincil kaynaklar

Araştırma

Devlet ve resmi kurumlar

Güvenlik firmaları ve satıcılar

Kontrol panelleri

Haberler

Yorum bırakın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Yukarı Çık