PHP2Shell — WordPress Sitem Etkilenir mi, Ne Yapmalıyım?

Son güncelleme: 22 Ekim 2026, 09:36 TSİ. Durum hızla değişiyor; yeni bilgi geldikçe bu sayfayı güncelliyoruz.

PHP2Shell, PHP’nin çekirdeğinde bulunan ve 21 Ekim 2026’da yamalanan iki kritik güvenlik açığının (CVE-2026-109618 ve CVE-2026-109619) ortak adıdır. “Sitem etkilenir mi, ne yapmalıyım?” sorusunun kısa cevabı şudur: Açık WordPress’te değil, sitenizi çalıştıran PHP’dedir. Web isteği karşılayan her PHP kurulumu risk altındadır ve WordPress’i güncellemek sorunu kapatmaz. Tek tam çözüm PHP’yi yamalı bir sürüme yükseltmektir: PHP projesinin duyurusuna göre 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35.

Sürümünüzü WordPress’te Araçlar → Site sağlığı → Bilgiler → Sunucu bölümünde görebilirsiniz. Ancak hosting firmaları yamayı eski sürüm numarasını koruyarak da uygulayabildiği için kesin teyidi hostinginizden almanız gerekir. PHP 8.1 ya da daha eski bir sürüm kullanıyorsanız PHP projesi bu dallar için yeni sürüm yayımlamıyor; 8.3 ya da 8.4’e geçişi bugün planlayın.

Bu, bugün ilgilenmeniz gereken bir konu. ABD’nin siber güvenlik ajansı CISA güncellemenin hemen yapılmasını istiyor ve araştırma firmalarına göre bir saldırı aracı internette dolaşıyor. 22 Ekim itibarıyla baktığımız kaynaklarda saldırı girişimleri raporlanıyor, ama doğrulanmış başarılı bir sızma bildirimi bulamadık. Aşağıda yapılacakları sırayla anlattık. Saldırının nasıl yapıldığına girmiyoruz; yalnız sitenizi korumak için bilmeniz gerekenleri yazıyoruz.

PHP2Shell nedir, ne oldu?

PHP, 21 Ekim 2026’da iki kritik açığı kapatan güvenlik sürümlerini yayımladı. İki açık da kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya (RCE) izin verebiliyor. Uzaktan kod çalıştırma, birinin internet üzerinden sunucunuzda kendi kodunu çalıştırabilmesidir. “Kimlik doğrulamasız” olması, saldırganın bunun için sitenize giriş yapması gerekmediği anlamına gelir. PHP’nin güvenlik bildirimine göre bu kod, web sunucusundaki PHP işçisinin (worker) yetkileriyle çalışır. Bu yüzden açıklar “kritik” sınıfında.

İki açık, tek güncelleme

php.net duyurusundaki kısa açıklamaya göre CVE-2026-109618’de bellek yetersizliği hatası PHP’yi, bir isteğe ait iç veri henüz yarı hazırken durdurabiliyor. Ardından gelen temizlik adımı bu geçersiz veriyi geçerli sanabiliyor. CVE-2026-109619’da ise bir isteğe ait iç durum, belleği serbest bırakıldıktan sonra da kalabiliyor. Aynı işçi sürecin işlediği sonraki bir istek bu bayat durumu kullanabiliyor.

PHP Foundation’a göre iki açık da neredeyse her isteğin geçtiği bellek yönetimi ve hata işleme katmanlarında. Yani sorun bir eklentiye ya da temaya bağlı değil. İkisi de aynı PHP sürümleriyle kapanıyor; WordPress tarafında yapılacak bir güncelleme yok:

“No WordPress update is required or planned for these issues.” (Bu sorunlar için bir WordPress güncellemesi gerekmiyor ve planlanmıyor.) — WordPress.org, 21 Ekim 2026

Ciddiyet puanında iki resmi değer var. CVSS, açıkların ciddiyetini 0 ile 10 arasında puanlayan standarttır. PHP iki açığa da CVSS v4.0 ile 9,2 (Kritik) verdi. ABD’nin ulusal açık veritabanı NVD ise kendi CVSS v3.1 hesabıyla 9,8 verdi. 20 Ekim’de sosyal medyada dolaşan 10,0 puanı resmi değil; PHP Foundation sızıntıdaki bu puanın yanlış olduğunu açıkladı.

Adı nereden geliyor?

“PHP2Shell” adını araştırmacılar koydu; PHP kendi duyurusunda bu adı kullanmıyor. PHP Foundation açıkları bulanlar olarak Calif, Wiz ve OpenAI Codex Security’yi anıyor; teşekkür listesinde OSTIF ve Quarkslab da var.

Yayın takvimi bir sızıntı yüzünden değişti. PHP Foundation’a göre 20 Ekim’de teknik ayrıntı değil, yalnız CVE numaraları ve yanlış bir puan sızdı. Ancak aynı akşam keşfeden firmalardan Calif’in yanlışlıkla yayımladığı bir video sınırlı ek ayrıntıları açığa çıkardı. watchTowr ve SecurityWeek ise olayı ayrıntıların sızması olarak aktardı. PHP bunun üzerine yayını 22 Ekim’den bir gün öne çekti; sürümler 21 Ekim 14:00 UTC’de (TSİ 17:00) çıktı.

Hangi siteler etkileniyor?

Etkilenen kitle çok geniş. W3Techs’in 21 Ekim 2026 ölçümüne göre sunucu tarafı dili bilinen web sitelerinin %69,3’ü PHP kullanıyor. WordPress de PHP ile çalıştığı için her WordPress sitesi bu konunun içinde. Önemli olan, sitenizin hangi PHP sürümünde ve nasıl çalıştığı.

PHP web sunucusuna farklı biçimlerde bağlanabilir: Apache’nin modülü olarak (mod_php), ayrı bir süreç yöneticisiyle (PHP-FPM), CGI olarak (php-cgi) ya da LiteSpeed gibi sunucuların kendi yöntemiyle. PHP’nin duyurusu bunların hiçbirini dışarıda bırakmıyor:

“Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.” (Kimler risk altında: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil, web isteği karşılayan bütün PHP kurulumları.) — PHP güvenlik duyurusu, php.net, 21 Ekim 2026

Resmi kayıt ne diyor?

PHP’nin resmi CVE kayıtları yalnız desteklenen dalları listeliyor: 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 öncesi. NVD’nin eşleşme kuralında ise başlangıç sürümü yok; 8.2.35’ten eski her sürüm eşleşiyor. Resmi kaydın 8.1 ve öncesini saymaması onları güvenli yapmıyor: PHP bu dallar için de kaynak kodu yaması yayımladı.

Eski sürümler: araştırmacılar ne diyor?

Calif, Wiz, Cloudflare ve Sansec, PHP 5.4 ve sonrasının etkilendiğini söylüyor. Imperva da 5.4 diyor, ama “her sürüm tek tek test edilmedi” çekincesini ekliyor. Ubuntu, php5 ve php7 serisindeki eski paketlerine de düzeltme yayımladı. Resmi PHP teyidi olmasa da sonuç değişmiyor: eski sürümleri de risk altında kabul etmek gerekiyor.

Bu, küçük bir kitle değil. WordPress.org’un PHP sürüm istatistiklerine göre (api.wordpress.org verisi, 22 Ekim 2026’da okundu) WordPress sitelerinin yaklaşık %36’sı PHP 8.2’den eski bir sürümde çalışıyor. Yalnız PHP 7.4’teki sitelerin payı yaklaşık %16. En yaygın dal ise yaklaşık %26,6 ile PHP 8.3.

Keşfeden firmalardan Wiz, standart WordPress konteyner imajında kimlik doğrulamasız kod çalıştırmayı ve süreç belleğinin okunabildiğini gösterdi. Wiz’e göre bu bellekte parola, kimlik doğrulama belirteci ya da API anahtarı bulunabilir. PHP’nin güvenlik bildirimi de bellek içeriğinin açığa çıkmasını doğrulanmış etkiler arasında sayıyor; WordPress üzerindeki gösterim ise Wiz’e ait.

LiteSpeed, PHP-FPM ya da mod_php: fark eder mi?

Risk sırası değişir, ama hiçbiri güvenli sayılmaz. PHP en yüksek riski mod_php’de görüyor. PHP-FPM’de de CVE-2026-109619 için uzaktan kod çalıştırma doğrulandı; yani “FPM kullanıyorum, güvendeyim” çıkarımı yanlış. LiteSpeed de php.net’in listesinde açıkça var. Yamalı lsphp paketleri (8.2.35, 8.3.36, 8.4.27 ve 8.5.12) 21 Ekim’de LiteSpeed’in RHEL 9 uyumlu paket deposunda yayımlandı; diğer dağıtımların depolarını kontrol etmedik. Paketin depoda olması, sizin sunucunuza kurulduğu anlamına gelmez.

Ne kadar acil? İstismar durumu (22 Ekim itibarıyla)

Kaynaklar burada ayrışıyor; iki tarafı da veriyoruz. CISA, 21 Ekim’deki uyarısında yayın anında istismar gözlemlemediğini yazdı. 22 Ekim 09:26 TSİ’de yeniden baktığımızda iki CVE de CISA’nın “bilinen istismar edilen açıklar” (KEV) kataloğunda değildi (katalog sürümü 2026.10.21). PHP Foundation, yayın anında dolaşan kavram kanıtlarında (PoC) çalışan bir saldırı bulamadığını söyledi. Huntress de 21 Ekim 16:30 ET (TSİ 23:30) itibarıyla müşteri sistemlerinde istismar görmediğini açıkladı.

Öte yandan Cloudflare, yama çıkmadan önce müşterilerini hedef alan saldırı trafiği gördüğünü bildirdi. Sansec, açıkla ilgili teknik yazıların ve bir saldırı aracının herkese açık olduğunu yazdı; CloudLinux da kural setlerinin bu “herkese açık saldırı aracını” engellediğini duyurdu. watchTowr kendi sayfalarında açıkları “istismar ediliyor (in the wild)” olarak işaretliyor ve bunu tuzak sunucu (honeypot) ağında gördüğünü söylüyor. The Hacker News’e göre ise aynı firma 21 Ekim 11:26 UTC itibarıyla istismar görmemişti. Firmanın tehdit istihbaratı başkanı Jake Knott, SecurityWeek’e henüz başarılı bir girişim görmediklerini söyledi. Hadrian adlı güvenlik firması ise geniş çaplı istismar bildirdi; bu iddia tek bir kaynağa dayanıyor. Amazon’un tehdit istihbaratı ekibi de 21 Ekim akşamı (22:36 UTC, TSİ 22 Ekim 01:36) yayımladığı yazıda, tuzak sunucu ağında 17 Ekim’de, yani açıklamadan dört gün önce bir istismar girişimi kaydettiğini, 21 Ekim’de birden çok saldırgandan gelen yeni girişimler gördüğünü ve açığın artık “yaygın biçimde istismar edildiğini” yazdı. Amazon bu girişimlerin gerçek sistemlerde başarılı olup olmayacağının belli olmadığını da ekliyor.

Özetle: 22 Ekim sabahı itibarıyla baktığımız kaynaklarda saldırı girişimleri raporlanıyor, Amazon’a göre de yaygın biçimde; ama doğrulanmış başarılı bir sızma bildirimi bulamadık. The Hacker News de başarılı bir sızmayı doğrulayan bir kaynak olmadığını yazdı. Bir saldırı aracı dolaşımda olduğu için bu tablo hızla değişebilir.

T.C. Siber Güvenlik Başkanlığı da 21 Ekim’de TR-26-1372 numaralı bildirimi yayımladı. Bildirim yamalar çıkmadan önce yazılmış; resmi güncellemenin yayımlanınca gecikmeden uygulanmasını öneriyor ve 22 Ekim sabahı itibarıyla yamalı sürüm numaralarını içerecek biçimde güncellenmedi. Başkanlık ayrıca yurt dışı erişim ihtiyacı olmayan sistemlerin uluslararası trafiğe kapatılmasını, yönetim arayüzleri ile kritik PHP servislerine dışarıdan erişimin de güvenilir IP adresleriyle sınırlanmasını öneriyor. Bunu hostinginiz ya da web uygulaması güvenlik duvarınız (WAF) üzerinden yapabilirsiniz; tam çözüm değildir. Anadolu Ajansı’nın aktardığına göre Başkanlık 21 Ekim akşamı yaptığı ayrı bir açıklamada, kamu kurumlarından başlayarak Türkiye genelindeki sistemlerde güvenlik taraması başlattığını ve Siber Olaylara Müdahale Ekipleri (SOME) İletişim Platformu üzerinden kurumlara ve kritik altyapılara acil duyuru gönderdiğini bildirdi; kamu ve özel sektördeki sistem yöneticilerinden yayımlanan güncellemeleri ivedilikle uygulamalarını istedi.

Son kontrol: 22 Ekim 2026, 09:36 TSİ.

PHP sürümümü nasıl öğrenirim?

İlk iş sürümünüzü ve PHP’nin nasıl çalıştığını öğrenmek. WordPress.org’un 21 Ekim açıklaması da aynı yolu gösteriyor.

WordPress Site sağlığı ekranından

Yönetim panelinde Araçlar → Site sağlığı sayfasını açın ve Bilgiler sekmesine geçin. Sunucu bölümünü genişletin. “PHP sürümü” satırı tam numarayı gösterir (örneğin 8.3.36). “PHP SAPI” satırı ise PHP’nin nasıl çalıştığını söyler. Ekran yalnız bilgi verir, buradan ayar değişmez (Site Health belgesi).

SAPI satırında apache2handler görüyorsanız siteniz mod_php ile çalışıyor; hostinginize öncelikle bunu sorun. fpm-fcgi PHP-FPM, litespeed ise LiteSpeed anlamına gelir (php.net SAPI listesi).

cPanel’de (MultiPHP Manager / Select PHP Version)

cPanel’de iki ekran olabilir. MultiPHP Manager, her alan adının kullandığı PHP dalını listeler. CloudLinux kullanan sunucularda “Yazılım” başlığı altında Select PHP Version da bulunur. Hosting firmanız bu ekranları kapatmış olabilir. İki ekranda da yalnız dal seçilir (ör. 8.3); yama seviyesini siz seçemezsiniz, onu sunucu yöneticisi kurar.

Panel paketlerinin durumu: cPanel, 21 Ekim’de EasyApache 4 25.91 güncellemesiyle ea-php74’ten ea-php85’e kadar paketleri yamaladı. CloudLinux’un 22 Ekim 01:25 UTC (TSİ 04:25) güncellemesine göre Select PHP Version ekranının kullandığı alt-php paketlerinin bütün sürümleri (5.2’den 8.5’e) için yamalı paketler CloudLinux 7, 8 ve 9’un kararlı (stable) depolarında; normal bir paket güncellemesi bunları kuruyor. Hosting firmasının güncellemeyi çalıştırıp PHP işçilerini yeniden başlatması gerekiyor.

Plesk’te

Plesk’te sürüm, alan adının PHP ayarları sayfasında görünür; menü adı arayüz sürümüne göre değişebilir. Yama seviyesini yine sunucu yöneticisi belirler.

Numara neden tek başına kanıt değil?

Linux dağıtımları yamayı kendi paketlerine “geri taşır” ve sürüm numarasını değiştirmez. Örneğin Ubuntu 24.04’teki yamalı php8.3 paketi 8.3.6 olarak görünür. CloudLinux da kendi ea-php84 paketinin yamalı olduğu hâlde 8.4.26 gösterdiğini söylüyor. Yani Site sağlığında eski bir numara görmeniz yamasız olduğunuzu kanıtlamaz; yeni bir numara görmek de işçi süreçlerin yeniden başlatıldığını kanıtlamaz. Kesin cevabı hosting firmanız verebilir: paketin değişiklik kaydında bu iki CVE numarasının geçip geçmediğine bakar.

Yamalı PHP sürümleri ve destek takvimi

PHP projesinin 21 Ekim 2026’da yayımladığı yamalı sürümler aşağıda. Sürüm duyurularındaki uyarı nettir:

“There are no complete mitigations, updating is the only safe choice.” (Tam bir geçici çözüm yok; güvenli tek seçenek güncellemektir.) — PHP 8.5.12 sürüm duyurusu, php.net, 21 Ekim 2026

Hangi dala geçeceğinizi seçerken destek takvimine bakın. php.net’in destek tablosuna ve ömrü biten sürümler listesine göre tarihler şöyle:

8.2’ye geçmek bu yılın sonuna kadar güvenlik desteği verir; ardından aynı işi yeniden yapmanız gerekir. WordPress.org PHP 8.3 ya da üzerini öneriyor. WooCommerce kullanıyorsanız WooCommerce’in sunucu gereksinimleri de PHP 8.3 ve üzerini istiyor (8.4’e kadar test edilmiş). Bu yüzden hedefiniz 8.3 ya da 8.4 olmalı.

PHP adım adım nasıl güncellenir?

Paylaşımlı hostingdeyseniz PHP’yi siz kurmazsınız; dalı seçer ya da hosting firmanızdan istersiniz. Aşağıdaki sıra WordPress.org’un “Update PHP” sayfasındaki adımlara dayanıyor.

1. Yedek alın

Önce dosyaların ve veritabanının tam yedeğini alın. WordPress.org’un hatırlattığı bir ayrıntı var: yedeğe dönmek için hostinginizin PHP’yi de eski dala geri alması gerekir. Mümkünse değişikliği önce sitenin bir kopyasında deneyin. Yedek ve kopya site düzenini güncellemeden önce tam yedek ve kopya sitede (staging) test yazımızda adım adım anlattık.

2. Uyumluluğu kontrol edin

Başlangıç → Güncellemeler ekranından WordPress’i, temaları ve eklentileri güncelleyin. PHP, WordPress ve WooCommerce sürümlerini birlikte nasıl not edeceğinizi sürüm uyumluluğu bölümümüzde anlattık. WordPress.org bu aşamada PHP Compatibility Checker eklentisini öneriyor. Sınırlarını bilin: eklenti sayfasına göre uyumluluğu “PHP 8.0’a kadar” kontrol ediyor, son üç büyük WordPress sürümüyle test edilmemiş ve yalnız WordPress.org’daki tema ve eklentileri tarıyor. Satın aldığınız (premium) temalar için geliştiricinin sürüm notlarına bakın.

3. Panelden dalı seçin ya da hostinge yükseltme talebi açın

Paneliniz izin veriyorsa 8.3 ya da 8.4 dalını seçin. İzin vermiyorsa ya da listede yalnız eski dallar varsa destek talebi açın; aşağıda kopyalayabileceğiniz bir metin var. Değişiklikten sonra ana sayfayı, iletişim formunu, giriş ekranını ve varsa ödeme sayfasını tek tek açıp deneyin.

4. Yamalı paketi ve yeniden başlatmayı teyit edin

Diskteki paketi güncellemek, o an çalışan süreçleri korumaz. Apache, PHP-FPM ya da LiteSpeed işçileri yeniden başlatılmalı; bunu hostinginize açıkça sorun. Geçici önlem olarak bellek sınırı kaldırıldıysa, yama kurulduktan sonra hostinginizden bu sınırı eski değerine geri almasını isteyin; yamalı PHP aşırı bellek kullanan isteği yeni bir üst sınırda kendisi sonlandırıyor. PHP ayrıca, yükleme ilerleme özelliğini (session.upload_progress) kullanmıyorsanız yamadan sonra da kapalı tutmayı makul buluyor.

Kendi sunucusunu yönetenler için

Dağıtımınızın güvenlik güncellemesini kurun, paket değişiklik kaydında iki CVE numarasını doğrulayın, bütün PHP servislerini yeniden başlatın, konteyner imajlarını yeniden derleyin. Debian’da düzeltmeler DSA-6574-1 ve DLA-4848-1 ile geldi. Red Hat, RHEL 8.10, 9.8 ve 10.2’nin AppStream php paketleri için düzeltmeleri RHSA kayıtlarıyla yayımladı (bazı paket akışları için düzeltme henüz yok); RHEL 6 ve 7 için durum hâlâ “inceleniyor”. php.net, gönüllülerin yürüttüğü Remi deposunun 21 Ekim’de güncelleme almayacağını duyurdu. PHP 8.2’den eski bir sürümde kalıyorsanız WordPress.org, güncellemeye hazırlanırken sunucuyu geçici olarak çevrimdışı almayı düşünmenizi öneriyor (ayrıntısı aşağıdaki yol haritası bölümünde).

Hemen güncelleyemiyorsanız: geçici önlemler

PHP bazı ayarlarla riskin azaltılabileceğini söylüyor, ama çizgiyi net çekiyor: php.net’e göre bu önlemler belirli saldırı yollarını daraltır, kurulumu güvenli yapmaz. Paylaşımlı hostingde bu ayarların çoğunu siz yapamazsınız; aşağıdaki tablo hostinginize ne sorabileceğinizi gösteriyor.

Geçici önlemler ve kim yapabilir?

Kaynaklar bu ayarların değeri konusunda da ayrışıyor. PHP onları “kısmi önlem” olarak sunuyor. watchTowr ise .ini dosyasıyla yapılan önlemlerin etkisiz sayılması gerektiğini yazıyor. Ortak nokta değişmiyor: hiçbiri güncellemenin yerini tutmuyor.

WAF: Cloudflare ve Imunify360

Cloudflare’e göre yönetilen WAF kuralları 21 Ekim 03:02 UTC’den (TSİ 06:02) beri, trafiği Cloudflare üzerinden geçen (proxy’li, turuncu bulutlu) sitelerde ücretsiz plan dahil varsayılan olarak açık. Cloudflare’ı yalnız DNS için kullanıyorsanız bu koruma devrede değildir. Pro ve üstü planlarda kural setinin “block” modunda olduğunu kontrol edin. Birçok hostingde kurulu güvenlik yazılımı Imunify360 için CloudLinux, 8.84 ve sonraki kural setlerinin LiteSpeed sunucularda da çalıştığını söylüyor ve bunu “sanal yama” olarak tanımlıyor. CloudLinux’a göre bu kurallar herkese açık saldırı aracının kullandığı yolu (CVE-2026-109619) hedefliyor; CVE-2026-109618’in bellek yetersizliği yolunu engelleyen bir kural henüz yok (22 Ekim 06:00 UTC). İkisi de faydalı bir ek katman, ama düzeltme değil. Cloudflare saldırganların kuralları aşmaya çalıştığını da bildirdi.

Neyi yapmamalısınız?

Yamadan önce yazılmış bazı Türkçe yazılar .user.ini ya da .htaccess dosyasıyla ayar yapmayı öneriyordu. PHP’nin duyurusu ise ayarın, istek işlenmeden önce uygulanan php.ini, FPM havuzu ya da sunucu yapılandırmasından verilmesini istiyor; ini_set() ile FPM .user.ini dosyasına güvenilmemesini söylüyor. .htaccess için ayrıca bir şey demiyor, ama bu ayarların sunucu düzeyinde, hostinginiz tarafından yapılması gerekir.

Sizin de katkı verebileceğiniz bir önlem var. PHP, istek başına uygulanan geçersiz ya da eskimiş ayarların kaldırılmasını öneriyor. Sitenizin .htaccess ya da .user.ini dosyasında eski PHP sürümlerinden kalmış php_value ya da php_flag satırları varsa, bunları hostinginizle birlikte temizleyin.

Bellek sınırını kendiniz kaldırmaya çalışmayın; bu karar sunucunun tamamını etkiler. Bakım modu da yeterli değil. Sansec’e göre PHP isteği, WordPress bakım bayrağına bakılmadan önce işliyor; bu bilgi tek bir araştırma firmasına dayanıyor. Siteyi gerçekten kapatmak gerekiyorsa PHP durdurulmalı ve sunucu statik bir sayfa göstermeli; bunu hostinginiz yapar.

Hosting firmanıza sormanız gereken sorular

Paylaşımlı hostingde yamanın kurulup kurulmadığını sizin doğrulamanızın güvenilir bir yolu yok. Bu yüzden hostinginizden yazılı teyit isteyin. 22 Ekim 09:30 TSİ itibarıyla Turhost, Natro, Radore ve İsimtescil’in kamuya açık blog ve duyuru sayfalarında PHP2Shell duyurusu bulamadık; Güzel Hosting’in sitesini kontrol edemedik. Türkiye’de de hizmet veren Hostinger ise küresel durum sayfasında, 22 Ekim 06:34 TSİ’de bütün cPanel sunucularını PHP düzeltmesini içeren cPanel yapısına ve en son alt-php sürümüne güncellediğini bildirdi. Firma 21 Ekim’deki ilk kaydında kendi testlerine göre platformunun etkilenmediğini de yazdı; bu firmanın kendi değerlendirmesi, PHP projesi ise web isteği karşılayan her PHP kurulumunu risk altında sayıyor. Duyuru yapmamış olmak yama yapılmadığı anlamına gelmez; müşteri panelinizi ve e-postanızı kontrol edin. Sorulacaklar:

1. Sitem hangi PHP dalını ve hangi paketi kullanıyor (ea-php, alt-php, lsphp, plesk-php ya da dağıtım paketi)?
2. Bu pakette CVE-2026-109618 ve CVE-2026-109619 yaması var mı? Sürüm numarası değişmediyse paketin değişiklik kaydında bu CVE’ler görünüyor mu?
3. Yamadan sonra Apache, PHP-FPM ya da LiteSpeed işçileri yeniden başlatıldı mı?
4. Hesabımda seçilebilen bütün PHP sürümleri ve alt alan adlarımın kullandığı sürümler de yamalandı mı?
5. Sitemin PHP SAPI’si nedir? mod_php (apache2handler) mı kullanılıyor?
6. Yama henüz yoksa hangi geçici önlem uygulandı (oturum ilerleme ayarı, WAF kural seti, yurt dışı trafik kısıtı)?
7. PHP 7.4, 8.0 ya da 8.1 kullanıyorsam yamalı bir paket mi sunuluyor, yoksa 8.3 ya da üstüne geçmem mi gerekiyor?
8. PHP, hesabımın kendi kullanıcı adıyla mı çalışıyor? (WordPress.org bunun daha güvenli olduğunu ve hostinge sorulmasını öneriyor.)

Kopyalayıp gönderebileceğiniz destek talebi

Konu: PHP2Shell (CVE-2026-109618, CVE-2026-109619) yama durumu

Merhaba,

21 Ekim 2026’da yayımlanan PHP güvenlik güncellemesi (CVE-2026-109618 ve CVE-2026-109619) hakkında bilgi rica ediyorum. Hesabımdaki bütün alan adları ve alt alan adları için şunları yazılı olarak iletebilir misiniz?

1. Kullanılan PHP dalı ve paket adı.
2. Paketin değişiklik kaydında bu iki CVE’nin bulunup bulunmadığı.
3. Yamadan sonra PHP işçilerinin yeniden başlatılıp başlatılmadığı.
4. Yama henüz yoksa uygulanan geçici önlem ve yama için tahmini tarih.

Sitem PHP 8.3 ya da 8.4’e geçmeye uygunsa, geçiş için ne yapmam gerektiğini de öğrenmek isterim.

Teşekkürler.

PHP 7.4, 8.0 ya da 8.1’de kalanlar için yol haritası

Bu dallardaysanız durumunuz diğerlerinden zor. PHP’nin duyurusu açık: PHP 8.1 ve öncesi artık PHP projesinden güncelleme almıyor. Güvenlik ekibi yalnız 7.4, 8.0 ve 8.1 için “asgari” kaynak kodu yamaları paylaştı. Bunlar kaynaktan derleyenler içindir; paylaşımlı hosting kullanıcısının kendi başına uygulayabileceği bir şey değildir. PHP 5.x için PHP projesinden hiçbir yama yok.

Güncelleyemiyorsanız: çevrimdışı almayı düşünün

Resmi kurumların bu dallar için önerisi sert. WordPress.org’un 21 Ekim açıklaması, PHP 8.2’den eski bir sürüm kullanan ve sunucusunu kendi yöneten site sahiplerine, güncellemeye hazırlanırken sunucuyu geçici olarak çevrimdışı almayı düşünmelerini öneriyor. ABD’de CISA, hemen güncelleyemeyen ya da PHP 8.1 ve öncesini kullanmaya devam eden kurumların PHP tabanlı sistemlerini yamalanana kadar çevrimdışı almasını istiyor. İngiltere’nin siber güvenlik merkezi NCSC de geçici önlemler uygulanamıyorsa sistemi çevrimdışı almayı önermektedir. Paylaşımlı hostingdeyseniz bu kararı hostinginizle birlikte verin.

Neden 8.2 değil, 8.3 ya da 8.4?

Bazı hosting firmaları ve dağıtımlar eski dallara yamalı paket sundu. cPanel ea-php74/80/81’e yamayı geri taşıdı, Ubuntu da Ubuntu Pro üzerinden eski php5 ve php7 paketlerini yamaladı. Bunlar bugünü kurtaran bir köprüdür, kalıcı yol değildir; 8.2’nin desteği de yıl sonunda bitiyor. WordPress’in PHP uyumluluk tablosuna göre WordPress 7.0 ve 7.1, PHP 7.4’ten 8.5’e kadar bütün dallarla uyumlu. Yani WordPress çekirdeği geçişin önünde engel değil. Hedefi 8.3 ya da 8.4 koymak, aynı işi birkaç ay sonra tekrarlamamanızı sağlar.

Eski temanız ya da eklentiniz 8.x’te çalışmıyorsa

Önce geliştiricinin güncel sürümüne bakın. Geliştirici yanıt vermiyorsa WordPress.org benzer işi gören başka bir tema ya da eklentiye geçmeyi öneriyor. Uyumsuz bir eklenti yüzünden sunucuyu yamasız bırakmak, o eklentiyi kaybetmekten daha büyük bir risktir.

Sitem ele geçirilmiş olabilir mi? Neye bakmalı?

22 Ekim itibarıyla baktığımız kaynaklarda doğrulanmış başarılı bir sızma bildirimi yok (ayrıntısı yukarıdaki “Ne kadar acil?” bölümünde). Yine de sitenizin yamasız kaldığı dönem için birkaç işarete bakmak mantıklı. Amazon ilk istismar girişimini 17 Ekim’de gördüğü için incelemenin açıklama tarihinden değil, en az 17 Ekim’den başlatılmasını öneriyor. Wiz’e göre açık, uygulama katmanının altında olduğu için WordPress’in kendi logları az bilgi taşıyabilir.

Loglarda görülebilecek işaretler

• Olağandışı sıklıkta bellek sınırı hataları.
• Tekrarlanan 500 (sunucu hatası) yanıtları.
• Açıklanamayan PHP işçi yeniden başlamaları.
• Betik çalışmadan önce loglara düşen tekrarlı uyarılar, “Maximum execution time exceeded” ve fatal hatalar.

PHP’nin güvenlik bildirimi de log incelemesini öneriyor, ama önemli bir uyarı ekliyor: logda hata görülmemesi güvende olduğunuzu kanıtlamaz. Paylaşımlı hostingde sunucu loglarının bir kısmına erişiminiz olmayabilir; bu incelemeyi hostinginizden isteyin.

Şüphe varsa ilk adımlar

• Logları ve yapılandırmayı silmeyin, saklayın.
• Web kökünde yeni eklenmiş dosyaları, yeni zamanlanmış görevleri (cron) ve yeni yönetici hesaplarını arayın. NCSC, hemen güncelleyemeyenlerin güncellemeden önce sistemde saldırganın bıraktığı arka kapıları (backdoor) aramasını öneriyor.
• WordPress, veritabanı, hosting ve FTP parolalarını, kullandığınız API anahtarlarını değiştirin.
• Hosting firmanıza durumu bildirin ve sunucu tarafında inceleme isteyin.

İnternette “PoC” ya da “test aracı” diye dolaşan dosyaları kendi sitenizde çalıştırmayın. JFrog, GitHub’da bu adla paylaşılan bazı sahte PoC depolarının şaka amaçlı, istenmeyen kod çalıştırdığını buldu. Genel sertleştirme için WordPress güvenliği kontrol listesi yazımıza da göz atabilirsiniz.

Sık Sorulan Sorular

WordPress’i güncellemek PHP2Shell’i kapatır mı?

Hayır. Açık WordPress’te değil, PHP’nin kendisinde. WordPress.org 21 Ekim 2026’da bu sorunlar için bir WordPress güncellemesi gerekmediğini ve planlanmadığını açıkladı. Çözüm, sunucudaki PHP’nin yamalı sürüme yükseltilmesidir; bunu hosting firmanız ya da sunucu yöneticiniz yapar.

Cloudflare kullanıyorum; korunuyor muyum, yine de güncellemem gerekir mi?

Trafiğiniz Cloudflare üzerinden geçiyorsa (proxy’li) ek bir koruma katmanınız var, ama yine de güncellemeniz gerekir. Cloudflare’ı yalnız DNS için kullanıyorsanız bu koruma devrede değildir. Cloudflare ve Imunify360 kuralları sanal yamadır, düzeltme değildir; iki firma da bunu söylüyor. Cloudflare saldırganların kuralları aşmaya çalıştığını da bildirdi.

PHP sürümüm güncel görünüyor; yamalı olup olmadığını nasıl anlarım?

Yalnız sürüm numarasına bakarak anlayamazsınız. Ubuntu ve CloudLinux yamayı eski sürüm numarasını koruyarak uyguluyor; örneğin yamalı Ubuntu paketi 8.3.6, yamalı CloudLinux ea-php84 paketi 8.4.26 görünüyor. Yeni bir numara da işçilerin yeniden başlatıldığını kanıtlamaz. Hostinginize CVE-2026-109618 ve CVE-2026-109619 numaralarıyla, paket değişiklik kaydında bu CVE’lerin bulunup bulunmadığını ve işçilerin yeniden başlatılıp başlatılmadığını sorun.

PHP 7.4 için yama var mı?

PHP projesi 7.4, 8.0 ve 8.1 için yeni sürüm yayımlamıyor; yalnız kaynaktan derleyenler için asgari kaynak kodu yamaları paylaştı. cPanel’in ea-php74 paketi ve Ubuntu Pro gibi bazı paneller ve dağıtımlar yamalı paket sundu. Bu bir köprüdür; kalıcı yol 8.3 ya da 8.4’e geçmektir. Ne yamalı paket ne de hemen geçiş mümkünse CISA sistemi yamalanana kadar çevrimdışı almayı, WordPress.org da sunucusunu kendi yönetenler için bunu düşünmeyi öneriyor.

Sitemin ele geçirilip geçirilmediğini nasıl anlarım?

Kesin tek bir işaret yok; PHP’nin güvenlik bildirimi logda hata olmamasının güvenlik kanıtı olmadığını söylüyor. Web kökünde yeni dosya, yeni cron işi, yeni yönetici hesabı ve açıklanamayan PHP hataları ya da yeniden başlamalar aranır. Şüphede loglar saklanır, parolalar ve API anahtarları değiştirilir, hostinge haber verilir.

Kaynaklar ve son güncelleme

Son güncelleme: 22 Ekim 2026, 09:36 TSİ. Yazıdaki bilgiler 21–22 Ekim 2026’da aşağıdaki kaynaklardan kontrol edildi. İstismar durumu, CISA kataloğu ve hosting paketleri saat saat değişiyor.

Resmi kaynaklar (PHP ve WordPress):

• php.net — Security advisory: Critical remote code execution vulnerabilities, update now (21 Ekim 2026)
• php.net — Supported Versions ve Unsupported Branches (22 Ekim 2026’da okundu)
• php.net — php_sapi_name
• WordPress.org — Critical PHP Security Release (John Blackbourn, 21 Ekim 2026)
• WordPress.org — Update PHP
• WordPress.org — Requirements
• WordPress.org — Site Health Screen
• Make WordPress Core — PHP Compatibility and WordPress Versions
• WordPress.org — Stats (PHP sürümleri) (api.wordpress.org verisi, 22 Ekim 2026’da okundu)
• WordPress.org — PHP Compatibility Checker
• WooCommerce — Server Requirements
• LiteSpeed — lsphp paket deposu (RHEL 9) (22 Ekim 2026’da okundu)
• W3Techs — Usage statistics of PHP (21 Ekim 2026)

Diğer resmi ve kurumsal kaynaklar:

• PHP güvenlik bildirimleri GHSA-w8hw-w9fx-j79w (CVE-2026-109618) ve GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), GitHub php/php-src, 21 Ekim 2026
• NVD kayıtları CVE-2026-109618 ve CVE-2026-109619, 21 Ekim 2026
• CISA, PHP’deki kritik açıklar için acil yama uyarısı, 21 Ekim 2026; KEV kataloğu (21 Ekim 2026 sürümü, 22 Ekim 09:26 TSİ’de yeniden kontrol edildi)
• T.C. Siber Güvenlik Başkanlığı, TR-26-1372 PHP Programlama Dili Güvenlik Bildirimi, 21 Ekim 2026 (22 Ekim 09:35 TSİ’de yeniden okundu, metin değişmemiş)
• T.C. Siber Güvenlik Başkanlığı’nın ulusal güvenlik taraması açıklaması, Anadolu Ajansı aracılığıyla (Milliyet, Sondakika), 21 Ekim 2026
• NCSC (Birleşik Krallık), PHP’yi etkileyen kritik güvenlik sorunu duyurusu, 21 Ekim 2026
• PHP Foundation, güvenlik sürümü ve zaman çizelgesi yazısı, 21 Ekim 2026
• cPanel, EasyApache 4 değişiklik kaydı (25.91) ve MultiPHP Manager belgesi, 21 Ekim 2026
• CloudLinux, PHP CVE-2026-109618 ve CVE-2026-109619 duyurusu (21 Ekim 2026; son güncelleme 22 Ekim 06:00 UTC)
• Cloudflare, PHP açıklarına karşı WAF koruması yazısı, 21 Ekim 2026
• Ubuntu güvenlik takip sayfası CVE-2026-109618; Debian güvenlik takipçisi (DSA-6574-1, DLA-4848-1)
• Red Hat, RHSB-2026-013 güvenlik bülteni ve CSAF/VEX kayıtları (22 Ekim 2026’da okundu)
• Amazon Threat Intelligence, PHP2Shell’in açıklamadan önce MadPot’ta görülen istismarı yazısı (AWS Security Blog, 21 Ekim 2026, 22:36 UTC)
• Hostinger durum sayfası, PHP Security Update Across Managed Hosting Plans (21 Ekim 17:44 UTC – 22 Ekim 03:34 UTC)

Araştırma ve haber kaynakları: Wiz, Calif, Sansec, watchTowr, Imperva, Huntress, JFrog, The Hacker News, BleepingComputer, Help Net Security ve SecurityWeek (21–22 Ekim 2026). Bu kaynakları adlarıyla anıyoruz. Saldırı tekniğini anlatan sayfalara ve kavram kanıtı (PoC) depolarına bilinçli olarak bağlantı vermiyoruz.