PHP’de Kritik RCE Açığı (PHP2Shell): WordPress Siteniz Etkilenir mi, Yamaya Kadar Ne Yapmalısınız?

Bu sabah hosting sağlayıcımızdan, büyük ihtimalle sizin de aldığınıza benzer bir e-posta geldi: “PHP’nin 5.4’ten itibaren tüm sürümlerinde uzaktan komut çalıştırmaya imkân veren son derece kritik bir güvenlik açığı tespit edilmiştir.”

Bu e-postanın Kan Themes müşterileri için de ne anlama geldiğini kısaca açıklayalım. WordPress PHP ile çalışır. Temalarımız da, kullandığınız eklentiler de PHP ile çalışır. Dolayısıyla bu açık tema ya da eklenti seçiminizle ilgili değildir. Sitenizin üzerinde çalıştığı PHP’nin kendisiyle ilgilidir.

Bu yazıda neyin bilindiğini ve neyin henüz belirsiz olduğunu ayırarak anlatıyoruz. Ardından resmi yama gelene kadar WordPress sitenizi korumak için bugün yapabileceklerinizi adım adım sıralıyoruz.

Kısa özet: Hosting panelinizden session.upload_progress.enabled = Off ayarını yapın, tam yedek alın ve PHP güncellemesi çıkar çıkmaz uygulayın. PHP 8.1 veya daha eski bir sürüm kullanıyorsanız yükseltmeyi planlayın, çünkü bu sürümlere yama gelmeyecek.

Ne oldu?

• 20 Ekim 2026’da PHP güvenlik ekibi, iki kritik açığı kapatacak acil bir sürüm yayımlayacağını duyurdu. Açıkların ikisi de CVSS v4.0 ölçeğinde 9.2 puan aldı.
• Yamanın 21 Ekim 2026 Çarşamba, 14:00 UTC (Türkiye saatiyle 17:00) saatinde yayımlanması planlanıyor. PHP ekibi, detaylar sızarsa ya da aktif saldırı tespit edilirse yamayı daha erken yayımlayabileceğini de belirtti.
• CERT-EU açıkları CVE-2026-109618 ve CVE-2026-109619 olarak listeledi. Güvenlik çevrelerinde bu açıklar “PHP2Shell” adıyla anılıyor.
• Planlanan duyuru tarihinden önce teknik detayların bir kısmı sızdı. Üstelik GitHub’da kavram kanıtı (PoC) olduğu iddia edilen depolar ortaya çıktı. Hosting firmalarının alarma geçmesinin sebebi tam olarak bu: Yama henüz yok ama saldırı kodu dolaşımda.

Neler kesin, neler henüz belirsiz?

WordPress siteleri neden doğrudan hedefte?

Sızan analizlere göre açıklardan biri PHP’nin dosya yükleme ilerleme takibi özelliğinde (session upload progress) bulunuyor. Bu özellik çoğu sunucuda varsayılan olarak açık geliyor. Ayrıca sitenin onu kullanıp kullanmamasından bağımsız olarak, multipart/form-data tipindeki her POST isteğinde devreye giriyor.

WordPress açısından bunun anlamı şu:

• Saldırganın giriş yapmasına gerek yok. Açık, WordPress’e ulaşmadan önce PHP’nin isteği işlediği aşamada tetikleniyor. Güçlü bir yönetici şifresi ya da iki adımlı doğrulama bu senaryoda sizi korumaz.
• Herhangi bir PHP dosyası kapı olabilir. wp-login.php, xmlrpc.php, admin-ajax.php ya da sitenizin ana sayfası, bir PHP dosyasına giden her istek potansiyel bir giriş noktası.
• Tema veya eklenti güncellemesi bu açığı kapatmaz. Sorun PHP çekirdeğinde olduğu için çözüm de PHP tarafında.
• Ele geçirilen bir sunucuda bütün siteler risk altındadır. Saldırgan kod çalıştırabildiği anda wp-config.php dosyasındaki veritabanı bilgilerine erişebilir, yeni yönetici hesabı açabilir, dosyalara arka kapı (backdoor) yerleştirebilir ya da sitenize zararlı yönlendirmeler ekleyebilir.

Özellikle yüksek trafikli haber siteleri ve e-ticaret mağazaları bu tür toplu taramalarda öncelikli hedeflerdir. Kanews ile haber sitesi ya da WooCommerce ile mağaza yönetiyorsanız bugün aşağıdaki adımları atlamayın.

Yamaya kadar yapmanız gerekenler

1. PHP sürümünüzü öğrenin

WordPress panelinde Araçlar → Site Sağlığı → Bilgi → Sunucu bölümüne gidin. Orada sitenizin kullandığı PHP sürümünü görebilirsiniz. Bu bilgi iki açıdan önemli:

• PHP 8.2, 8.3, 8.4 veya 8.5 kullanıyorsanız bu sürümler için yama bekleniyor.
• PHP 8.1 ve öncesi (8.0, 7.x, 5.x) kullanıyorsanız durum farklı. Bu sürümlerin desteği sona erdi ve resmi yama alması beklenmiyor. Aşağıdaki geçici önlemleri uygulayın ve yükseltmeyi bugünden planlayın.

Unutmayın: Bir sunucudaki tek bir eski site bütün sunucuyu riske atar. Unuttuğunuz test kurulumlarını, eski demo sitelerini ve alt alan adlarını da kontrol edin.

2. session.upload_progress.enabled ayarını kapatın

Hosting sağlayıcıların ve güvenlik araştırmacılarının önerdiği geçici önlem şu satır:

session.upload_progress.enabled = Off

Bu ayar WordPress sitenizi bozar mı? Hayır. WordPress medya yükleyicisi yükleme ilerlemesini tarayıcı tarafında (JavaScript ile) gösterir ve PHP’nin bu özelliğini kullanmaz. Kanews, Geoit, Xentra ve Yazai temalarımızı da kontrol ettik. Hiçbiri bu özelliği kullanmıyor. Dosya yüklemeleri normal şekilde çalışmaya devam eder. Yalnızca bu özelliğe özel olarak bağlı nadir bir eklenti kullanıyorsanız ilerleme çubuğu görünmeyebilir.

Sizin yapmanız gerekiyor mu? Birçok hosting firması bu ayarı paylaşımlı sunucularda kendisi yaptı. Yine de doğrulamanızı öneriyoruz. VPS veya sunucunuz kendi yönetiminizdeyse ayarı büyük ihtimalle sizin yapmanız gerekir.

Ortamınıza göre ayarı şu yollarla yapabilirsiniz:

cPanel: MultiPHP INI Editor → Editor Mode bölümünden alan adınızı seçin, satırı ekleyip kaydedin.

Plesk: Web Siteleri ve Alan Adları → PHP Ayarları → Ek yapılandırma yönergeleri alanına satırı ekleyin.

Panel yok, PHP-FPM/CGI çalışıyorsa: Sitenizin kök dizinindeki (wp-config.php ile aynı yerdeki) .user.ini dosyasına ekleyin. Dosya yoksa oluşturun:

session.upload_progress.enabled = 0

.user.ini değişikliğinin devreye girmesi 5 dakika kadar sürebilir.

Panel yok, Apache mod_php çalışıyorsa: .htaccess dosyasının en üstüne ekleyin:

php_flag session.upload_progress.enabled off

Bu satır mod_php dışındaki ortamlarda 500 hatasına yol açabilir. Siteniz açılmazsa satırı hemen kaldırıp .user.ini yöntemini kullanın.

VPS / kendi sunucunuz: php.ini dosyasını veya PHP-FPM havuz (pool) yapılandırmasını düzenleyin:

; php.inisession.upload_progress.enabled = Off; veya /etc/php/8.x/fpm/pool.d/www.confphp_admin_flag[session.upload_progress.enabled] = off

Ardından PHP-FPM’i yeniden yükleyin:

sudo systemctl reload php8.3-fpm

Sunucuda birden fazla PHP sürümü yüklüyse (8.1, 8.2, 8.3 gibi) ayarı her sürüm için ayrı ayrı yapın.

ini_set() ile bu ayar değiştirilemez. Bu yüzden wp-config.php veya functions.php içine kod eklemek işe yaramaz.

Ayarın uygulandığını nasıl doğrularım?

Kök dizinde tahmin edilmesi zor bir isimle (örneğin kontrol-8f3k2.php) şu içerikte bir dosya oluşturun:

<?php phpinfo();

Dosyayı tarayıcıda açın ve session.upload_progress.enabled satırının Off olduğunu kontrol edin. Ardından dosyayı hemen silin. phpinfo çıktısı sunucunuz hakkında saldırganların işine yarayacak çok fazla bilgi içerir.

Terminalde php -i komutu yalnızca komut satırı (CLI) ayarlarını gösterir. Web sunucusunun kullandığı ayar farklı olabilir. Doğrulamayı tarayıcıdan yapın.

Bu ayar tek başına yeterli mi?

Hayır. Bağımsız analizler, iki açıktan yalnızca birinin bu yolla engellendiğini ve diğerinin dosya yükleme isteklerini işleyen kısımda olabileceğini söylüyor. Bu ayar riski ciddi ölçüde azaltır ama yamanın yerini tutmaz. Aşağıdaki adımları da uygulayın.

3. Şimdi tam yedek alın

Yamadan önce, sitenizin temiz olduğundan emin olduğunuz bu saatlerde dosyaların ve veritabanının tam yedeğini alın:

• Yedeği sunucunun dışında saklayın (bilgisayarınız, bulut depolama). Saldırgan sunucuya erişirse sunucudaki yedeklere de erişebilir.
• UpdraftPlus, All-in-One WP Migration veya hosting panelinizin yedekleme aracı işinizi görür.
• Yedeğin tarihini not edin. Olası bir saldırıda “temiz” son noktanız bu olacak.

4. Önünüzde bir WAF varsa kurallarını sıkılaştırın

Cloudflare veya benzeri bir güvenlik duvarı kullanıyorsanız:

• Yönetilen (managed) kural setlerinin açık olduğundan emin olun. WAF sağlayıcıları bu tür olaylarda genellikle hızla acil kural yayımlar.
• wp-login.php ve /wp-admin/ erişimini mümkünse kendi IP adreslerinizle sınırlayın.
• Sitenize ziyaretçilerin dosya yüklemesi gerekmiyorsa, sizin IP’niz dışından gelen multipart/form-data POST isteklerini geçici olarak engellemeyi düşünebilirsiniz. Cloudflare özel kural örneği:

(http.request.method eq "POST" and any(http.request.headers["content-type"][*] contains "multipart/form-data") and not ip.src in {SIZIN.IP.ADRESINIZ})

Dikkat: Contact Form 7, Elementor Form gibi birçok form eklentisi, dosya alanı olmasa bile formu multipart/form-data ile gönderir. Bu kuralı uygularsanız iletişim formlarınızı ve WooCommerce akışınızı mutlaka test edin. Gerekirse kuralı yalnızca Managed Challenge modunda çalıştırın.

5. WordPress tarafında saldırı yüzeyini küçültün

Bu adımlar PHP açığını kapatmaz. Ama olası bir saldırının etkisini sınırlar ve zaten uygulanması gereken iyi pratiklerdir.

wp-content/uploads klasöründe PHP çalışmasını engelleyin. Yükleme klasöründe PHP dosyası olmasına gerek yoktur ve arka kapılar en sık buraya bırakılır. wp-content/uploads/.htaccess dosyasına:

<FilesMatch "\.(php|phtml|phar)$">    Require all denied</FilesMatch>

Nginx kullanıyorsanız:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {    deny all;}

Panelden dosya düzenlemeyi kapatın. wp-config.php dosyasına:

define( 'DISALLOW_FILE_EDIT', true );

XML-RPC’yi kullanmıyorsanız kapatın. Jetpack veya mobil uygulama kullanmıyorsanız xmlrpc.php dosyasını güvenlik eklentiniz veya sunucu kuralıyla engelleyebilirsiniz.

WordPress çekirdeğiniz güncel mi? Eylül ayında WordPress 7.1.0 ve öncesini etkileyen Click2Shell adlı ayrı bir zincir açıklanmıştı. Bu açık, yöneticinin hazırlanmış bir bağlantıya tıklatılmasıyla sitede PHP kodu çalıştırılmasına imkân veriyordu ve WordPress 7.1.1 ile kapatıldı. Hâlâ 7.1.1 öncesinde kalan bir siteniz varsa bugün onu da güncelleyin.

6. Şüpheli izleri takip edin

Yama çıkana kadar ve çıktıktan sonraki birkaç gün boyunca şu belirtilere dikkat edin:

• Tanımadığınız yeni yönetici hesapları
• wp-content/uploads içinde PHP dosyaları
• Son günlerde değiştirilmiş, tanımadığınız ya da kodu karmaşık hale getirilmiş (obfuscated) PHP dosyaları
• Sitenizin Google’da spam başlıklarla görünmesi veya ziyaretçilerin başka sitelere yönlendirilmesi
• Hosting panelinde açıklanamayan CPU artışı ya da PHP-FPM süreçlerinin sık sık çökmesi

SSH ve WP-CLI erişiminiz varsa hızlı bir kontrol için:

# Yönetici hesaplarını listelewp user list --role=administrator# WordPress çekirdek dosyalarını orijinalleriyle karşılaştırwp core verify-checksums# Eklenti dosyalarını WordPress.org sürümleriyle karşılaştırwp plugin verify-checksums --all# uploads klasöründeki PHP dosyalarını bulfind wp-content/uploads -type f -name "*.php"# Son 2 günde değişen PHP dosyalarını listelefind . -type f -name "*.php" -mtime -2

SSH erişiminiz yoksa Wordfence gibi bir güvenlik eklentisiyle tam tarama yapabilirsiniz. Sunucu tarafında ImunifyAV, Linux Malware Detect (maldet) veya ClamAV gibi araçlar da işinizi görür. Birçok hosting firması bunlardan birini panelde sunuyor.

PoC kodlarını kendi sunucunuzda denemeyin. GitHub’da “test edin” diye paylaşılan exploit paketlerinin bir kısmı zararlı yazılım içerebilir. Açığın sizde olup olmadığını öğrenmenin güvenli yolu PHP sürümünüze ve yukarıdaki ayara bakmaktır.

Yama yayımlandığında

Sansec’in tahminine göre yama yayımlandıktan sonraki ilk 15 dakika içinde toplu saldırılar başlayabilir. Çünkü yamadaki kod değişiklikleri, açığın tam olarak nerede olduğunu herkese gösterecek. Bu yüzden yamayı ertelemeyin:

1. PHP’yi güncelleyin. Paylaşımlı hostingde bunu çoğunlukla firma yapar. Panelinizden veya destek ekibinden güncellemenin uygulandığını teyit edin. VPS’te paket yöneticinizle (apt, dnf) güncelleyip PHP-FPM’i yeniden başlatın.
2. Sürümü kontrol edin. Site Sağlığı ekranından ve php.net duyurusundaki yamalı sürüm listesinden emin olun. Ubuntu, Debian veya CloudLinux gibi dağıtımlar yamayı kendi paket sürümlerine “backport” edebilir. Bu durumda sürüm numarası değişmeyebilir. Dağıtımınızın güvenlik duyurusuna bakın.
3. Geçici önlemleri gözden geçirin. session.upload_progress ayarını kapalı bırakmanın WordPress için bir dezavantajı yok. Açık bırakmanızı öneriyoruz. Cloudflare’de eklediğiniz sıkı kuralları ise formlarınızı etkiliyorsa kaldırabilirsiniz.
4. Taramayı tekrarlayın. Yamadan önce sızılmış bir site, yamadan sonra da arka kapıyla açık kalır. Yukarıdaki kontrolleri bir kez daha yapın.
5. Şüphe varsa anahtarları yenileyin. Herhangi bir iz bulduysanız veritabanı şifresini, wp-config.php içindeki güvenlik anahtarlarını (salts) ve tüm yönetici şifrelerini değiştirin.

Henüz resmî olmayan kaynaklar beklenen yamalı sürümleri 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 olarak gösteriyor. Kesin liste için mutlaka php.net duyurusunu esas alın.

Eski PHP sürümündeyseniz: Yükseltme zamanı

PHP 7.4 veya 8.0/8.1 ile çalışan siteler bu açık için resmi yama almayacak. Hosting firmanızın eski sürümler için özel yama (backport) sunup sunmadığını sorabilirsiniz. Ama kalıcı çözüm, desteklenen bir PHP sürümüne (8.2 ve üzeri, tercihen 8.3 veya 8.4) geçmektir.

Yükseltmeden önce:

• Sitenizin bir kopyasını (staging) oluşturup yeni PHP sürümünü önce orada deneyin.
• Temanızı ve eklentilerinizi güncel sürüme yükseltin. Yıllardır güncellenmemiş tema ve eklentiler yeni PHP sürümlerinde hata verebilir.
• Kan Themes temalarından birini kullanıyorsanız hesabınızdaki İndirmeler bölümünden son sürümü indirin. Takıldığınız bir nokta olursa Hesabım → Destek Talepleri üzerinden bize yazın.

Sık sorulan sorular

Temamı veya eklentilerimi güncellemek bu açığı kapatır mı? Hayır. Açık PHP çekirdeğinde. WordPress, tema ve eklenti güncellemeleri bu açığı kapatmaz. Çözüm PHP güncellemesidir. Yine de güncel bir WordPress kurulumu, olası bir saldırının etkisini sınırlamaya yardımcı olur.

session.upload_progress.enabled = Off yapınca medya yükleme bozulur mu? Hayır. WordPress yükleme ilerlemesini tarayıcı tarafında gösterir. Dosya yüklemeleri normal şekilde çalışmaya devam eder.

Hosting firmam ayarı yaptığını söyledi. Benim bir şey yapmam gerekiyor mu? Ayarın sitenize gerçekten uygulandığını phpinfo ile doğrulamanızı, yedek almanızı ve yama sonrası PHP sürümünün güncellendiğini teyit etmenizi öneriyoruz. Ayrıca bu ayarın iki açıktan yalnızca birini engellediği düşünülüyor.

Sitem Cloudflare arkasında. Güvende miyim? Cloudflare WAF riski azaltabilir ama tek başına garanti değildir. Saldırgan sunucunuzun gerçek IP adresini biliyorsa Cloudflare’i atlayabilir. PHP ayarı ve yama yine gerekli.

Sitemin hacklendiğinden şüpheleniyorum. Ne yapmalıyım? Önce sitenin o anki halinin yedeğini alın (inceleme için). Ardından hosting firmanıza haber verin, şifreleri ve güvenlik anahtarlarını değiştirin, temiz olduğundan emin olduğunuz yedeğe dönmeyi değerlendirin. Saldırganın bıraktığı arka kapıları tek tek temizlemek çoğu zaman temiz yedekten dönmekten daha risklidir.

Sonuç

Bu açık internetin büyük bölümünü etkiliyor ve WordPress siteleri de bunun dışında değil. İyi haber şu: Yama bugün geliyor ve o zamana kadar riski azaltmak için yapılabilecekler belli. Ayarı kapatın, yedek alın, yama çıkar çıkmaz uygulayın, sonra sitenizi tarayın.

Bu yazıyı yama yayımlandığında, kesinleşen sürüm listesi ve yeni bilgilerle güncelleyeceğiz.