PHP güvenlik açığı: PHP2Shell yaması ve PHP sürümünü kontrol etme (WordPress)

PHP2Shell, 21 Ekim 2026'da yamaları yayımlanan iki PHP güvenlik açığının (CVE-2026-109618 · CVE-2026-109619) adıdır. Oturum açılmamış bir istekle bile sunucuda kod çalıştırılabilen uzaktan kod yürütme açıkları olduğu için önce sitenizin kullandığı PHP sürümünü kontrol edip yamalı sürüme yükseltmeniz gerekir. WordPress 7.1.3 çalışan Nginx + Apache yapılı bir sunucuda PHP sürümünü Site sağlığı ekranından kontrol ettim, yalnızca php paketlerini yamalı sürüme yükselttim ve ardından yeniden kontrol ettim.

1️⃣ PHP güvenlik açığı PHP2Shell: Açıkların çalışma şekli ve etki alanı

Bu açıklar, WordPress kodu çalışmadan önce isteği okuyan PHP motorunun içinde olduğu için eklentileri ve temaları güncel tutsanız bile PHP'yi yükseltmediğiniz sürece olduğu gibi kalır. CERT-EU uyarısına göre iki açığın CVSS puanı da 9,2'dir; teknik ayrıntılar kamuya açıklanmış ve tartışılıyor, ilk kavram kanıtı kodları da dolaşmaya başladı.

CVE-2026-109618, bir istek bellek sınırını (memory_limit) aşıp yarıda kesildiğinde, temizleme sürecinin yarısı başlatılmış istek verilerini geçerli veri gibi ele aldığı açıktır. CVE-2026-109619 ise ölümcül bir hatadan sonra serbest bırakılan belleğin durumunun kaldığı ve aynı worker'ın işlediği sonraki istekte başlatılmadan önce yeniden kullanıldığı açıktır.

php.net duyurusuna göre web isteklerini işleyen tüm PHP kurulumları etkileniyor ve bunların içinde en tehlikeli yapı Apache mod_php olarak görülüyor. Çünkü mod_php üzerinde, oturum açılmamış tek bir isteğin uygulama kodu çalışmadan önce saldırıyı tetiklediği gösterildi.

Düzeltilmiş sürümler 8.2.35, 8.3.36, 8.4.27 ve 8.5.12'dir; bunlardan düşük tüm 8.2–8.5 sürümleri etkilenir. PHP 8.1 ve öncesi, PHP projesinin desteğinin bittiği seriler olduğu için resmi yamalı sürümleri yoktur; dağıtımların ve hosting firmalarının taşıdığı düzeltmelerle (backport) korunur.

CISA 21 Ekim'de duyuru yayımladığında henüz gerçek bir istismar doğrulanmamıştı; ancak CISA sistemleri yamasız bırakmanın tehlikeli olduğunu değerlendirerek internete açık sistemlerden başlayarak hemen yama yapılmasını önerdi. CERT-EU aynı gün yayımladığı uyarıda, kavram kanıtı kodlarının dolaşmaya başlamasıyla saldırganların açıkları zaten istismar ediyor olma ihtimalinin arttığı sonucuna vardı.

2️⃣ PHP sürümünü kontrol etme: Site sağlığı › Bilgiler › Sunucu

Açıkları bilseniz de sitenizin hangi PHP sürümüyle çalıştığını bilmeden ne yapacağınız belli olmaz. Yönetim panelinde [Araçlar › Site sağlığı] ekranını açıp [Bilgiler] sekmesindeki [Sunucu] bölümünü genişlettiğinizde, [PHP sürümü] satırında sitenizin isteklerini gerçekten işleyen PHP sürümü görünür.

[PHP sürümü] satırının hemen altındaki [PHP SAPI] satırı PHP'nin çalışma şeklini gösterir; fpm-fcgi bir PHP-FPM yapısıdır. Burada [Sunucu] bölümündeki [PHP sürümü] ve [PHP SAPI] satırlarına bakmanız yeterli.

Saldırı, oturum açılmamış bir istekle başlar. Özel olarak hazırlanmış isteği PHP'nin WordPress kodundan önce okuduğu aşamada iki açıktan biri tetiklenir ve sunucuda kod yürütmeye varılır. Düzeltilmiş sürümler bu akışı engellediği için yapılacak iş, sitenin PHP'sini düzeltilmiş sürüme veya üzerine yükseltmektir.

Terminaldeki [php -v], yalnızca komut satırının varsayılan PHP sürümünü gösterir. cPanel'in EA-PHP'si veya CloudLinux'un alt-php'si gibi bir sunucuya birden fazla PHP sürümü kurulan yapılarda bu, sitenin kullandığı sürümden farklı olabilir. Bu yüzden ölçüt, Site sağlığındaki [PHP sürümü] değeridir.

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

3️⃣ PHP 8.2'den düşükse: Hosting firmanıza backport uygulanıp uygulanmadığını sorun, yoksa talep edin

Site sağlığındaki [PHP sürümü] 8.2'den düşükse (7.x · 8.0 · 8.1), php.net'in resmi yamalı sürümü yoktur. php.net'in desteklenen sürümler tablosuna (22 Ekim 2026'da kontrol edildi) göre desteklenen seriler yalnızca 8.2, 8.3, 8.4 ve 8.5'tir; 8.1 ve öncesinin resmi sürümleri için güvenlik yaması çıkmaz.

Bunun yerine dağıtımlar ve hosting firmaları, sürüm numarasını aynı bırakıp yalnızca düzeltmeyi taşıyan paketler (backport) yayımlayabilir. Yönetilen bir hosting test sunucusundaki 7.4.33 · 8.0.30 · 8.1.34 paketleri buna bir örnektir. Değişiklik kayıtlarında [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619] satırı vardı.

Sürüm numarası aynı olsa da düzeltmenin içinde olup olmadığını paketin değişiklik kaydında CVE numarasını arayarak kontrol edersiniz. Debian · Ubuntu ailesinde [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618] biçiminde ararsınız. RPM ailesinde biçim [rpm -q --changelog php-common | grep 109618] olur; paket adındaki sürüm numarasını sitenin kullandığı sürüme göre ayarlarsınız.

Bu yüzden 8.2'nin altındaysanız önce hosting firmanıza backport uygulanıp uygulanmadığını sorun; uygulanmadıysa ya da doğrulanamıyorsa desteklenen bir sürüme (8.2 veya üzeri) yükseltmelerini isteyin. Yükseltmeden sonra Site sağlığındaki [PHP sürümü] değeriyle yeniden kontrol edin.

CISA, 8.1 veya daha eski sürüm kullanan ve hemen güncelleyemeyen kuruluşlara, yama ya da yükseltme yapılana kadar PHP tabanlı sistemlerini çevrimdışı tutmalarını önerdi.

Sunucuyu kendiniz yönetiyor ve 8.1 veya öncesini kullanıyorsanız dağıtımınızın backport paketlerini kurabilir ya da PHP güvenlik ekibinin 7.4 · 8.0 · 8.1 için yayımladığı kaynak yamalarını uygulayabilirsiniz. Yine de bunlar desteği bitmiş seriler olduğu için asıl çözüm desteklenen bir sürüme geçmektir.

4️⃣ PHP 8.2 veya üzeriyse: Yamalı sürüme güncelleyip yeniden kontrol edin

8.2 veya üzerindeyseniz ama yamalı sürümün altındaysanız PHP'nin kendisini yükseltirsiniz. Yönetilen ve paylaşımlı hostingde yamayı firma tüm sunucuya uyguladığı için uygulanıp uygulanmadığını ve derlemeyi firmanın duyurularından ya da destekten öğrenin, ardından Site sağlığındaki [PHP sürümü] değerinin değişip değişmediğine bakın. Cloudways durum sayfasındaki duyuruya göre 21 Ekim'de 22:19 UTC'de desteklediği tüm PHP sürümlerine (5.6–8.4) yama uygulamaya başladı. 22 Ekim'de 10:11 UTC'de işin tamamlandığını duyurdu.

Kendi yönettiğiniz sunucuda php.net duyurusunda belirtildiği gibi dağıtımın ya da bir LTS sağlayıcısının deposundaki paketlerle yükseltirsiniz. Güncellemeden önce önizlemede değişecek paketlerin listesini kontrol edip yalnızca php ile başlayan paketlerin yükseldiğini ve başka paketin eşlik etmediğini görün, işletim sisteminin diğer güncellemeleriyle karıştırmayın.

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (php-gd · php-intl gibi eklenti paketi satırları atlandı)

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (eklenti paketi satırları atlandı)

Complete!

Bu denemede yalnızca php ile başlayan paketler yamalı sürüme yükseldi ve paket kurulumu bitince php-fpm kendiliğinden yeniden başladı. Düzeltilmiş sürüm, php-fpm worker'ları yeniden başladığında devreye girer; otomatik yeniden başlatma olmayan ortamlarda [systemctl restart php-fpm] komutunu kendiniz çalıştırın.

Yükseltmeden sonra [php -v] ile Site sağlığı [Bilgiler] sekmesindeki [PHP sürümü] satırının ikisinin de yamalı sürüm veya üzeri olup olmadığına bakın, php-fpm hizmetinin durumunu ve sitenin yanıtını da kontrol edin. Yalnızca komut satırı değeri değişip [PHP sürümü] değeri aynı kaldıysa php-fpm'i yeniden başlatıp tekrar kontrol edin.

Güncellemeden sonra da aynı [Araçlar › Site sağlığı] ekranının [Bilgiler] sekmesinde [Sunucu] bölümünü genişletip [PHP sürümü] satırına bakın. Bu değer yükselttiğiniz sürüme değiştiyse php-fpm worker'ları da yeni sürümle çalışıyor demektir.

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

200

Sürüm numarasının kendisi yükselen paketlerde yamayı yeni sürüm numarasından, sürüm numarasını aynı bırakan backport paketlerinde ise değişiklik kaydındaki CVE numarasından anlarsınız. Bu sunucu ilk türdendi; [rpm -q --changelog php-common] içinde CVE numarası geçen satır yoktu ve yamayı değişiklik kaydının ilk satırındaki yeni sürüm numarasıyla doğruladım.

5️⃣ Hemen yükseltemiyorsanız: php.net'in önerdiği geçici önlemler

Hemen yükseltilemeyen sunucular için php.net aşağıdaki ayarları geçici önlem olarak önerirken, bu önlemlerin yalnızca belirli saldırı yollarını daralttığını ve kurulumu güvenli hâle getirmediğini açıkça belirtti. Bellek sınırını bunun yerine RLIMIT_AS veya RLIMIT_DATA ile koymanın, tam da açığa yol açan bellek ayırma hatalarını tetikleyebileceği için kullanılmaması gerektiğini de yazdı.

php_admin_value, uygulamanın geri alamayacağı sunucu tarafı bir ayar olduğu için paylaşımlı hosting kullanıcıları bunu çoğu zaman kendileri değiştiremez ve bu durumda da sonunda hosting firmasına başvurmaları gerekir. php.net ayrıca web sunucusu veya proxy aşamasında da istek gövdesi boyutuna, girdi alanı sayısına, multipart parça sayısına, başlık sayısına ve iç içe geçme derinliğine üst sınır konmasını öneriyor.

🔢 SSS & önerilen içerikler

🔗 Önerilen içerikler

Güvenlik WP güvenliği: wp-admin güvenliği Giriş adresini değiştirip giriş denemelerini sınırlayarak ve XML-RPC'yi engelleyerek yönetim ekranını koruyan ayarlar. Yazıyı oku →

Güvenlik wp-config.php güvenlik açıkları wp-config.php dosyasının açığa çıkmasını önleme ve güvenlik ayarlarını güçlendirme yolları. Güvenlik WordPress XML-RPC xmlrpc.php saldırılarını kayıtlardan ayırt etme ve devre dışı bırakmanın üç yolu. Sunucu php-fpm max_children uyarısı Worker sayısını artırmadan önce uyarının nedenini kayıtlardan bulan bir ölçüm.

ℹ️ Satış ortaklığı bildirimi
Bu sitenin içeriklerinde satış ortaklığı bağlantıları bulunur. Bir ziyaretçi bu bağlantılar üzerinden ürün veya hizmet satın alırsa bu site satıcıdan komisyon alır. Bu süreçte alıcının ödediği tutar ^{(kampanya indirimlerinde tutar düşer↓)} artmaz. Yayımlanan fiyat, indirim ve stok bilgileri yazının yazıldığı zamana aittir ve gerçek durumdan farklı olabilir; bu yüzden satın almadan önce son bilgiyi satıcıdan kontrol etmenizi rica ederiz. Ürünler kendi ölçütlerimize göre seçilir ve değerlendirilir; komisyon alınıp alınmaması tanıtım sırasını veya değerlendirme içeriğini etkilemez.