PHP2Shell: DLE site sahibinin PHP'deki iki RCE hakkında bilmesi gerekenler

21 Ekim 2026'da PHP, site sahiplerine sunucu tarafını kontrol etmek için acil bir neden verdi. Proje, CVE-2026-109618 ve CVE-2026-109619 açıklarını düzeltti: dışarıdan gelen bir isteğin, güncellenmemiş bir web işleyicisinde kod çalıştırmaya yol açabildiği hatalar. DLE sitesi sahibi için ana sonuç basit: motor sürümü ve kurulu modüller riski ortadan kaldırmaz, çünkü açığı olan bileşen PHP katmanındadır.

Düzeltmeleri içeren resmi PHP sürümleri: 8.2.35, 8.3.36, 8.4.27 ve 8.5.12. Eski 8.1, 8.0 ve 7.4 dallarında yalnızca kısa sürüm dizesine bakarak karşılaştırma yapmak güvenilir değildir. Bu dalların standart desteği sona erdi; hosting veya dağıtım sağlayıcısı düzeltmeyi temel numarayı koruyarak kendi paketine taşıyabilir.

Kısaca#

• Açıklar CVE-2026-109618 ve CVE-2026-109619 kimlikleriyle izleniyor; ikisi de CVSS v4.0'a göre 10 üzerinden 9,2 puan aldı.
• Risk PHP-FPM'de, mod_php ile Apache'de ve LiteSpeed ile php-cgi dahil diğer web işleyicilerinde vardır.
• SSH'de php -v, komut satırının sürümünü gösterir. Bu sürüm, site ziyaretçilerine yanıt veren PHP ile aynı olmayabilir.
• WAF, Cloudflare, dosya yüklemeyi kısıtlamak veya tek bir eklentiyi kapatmak güncellemenin yerini tutmaz. Geçici önlemler yalnızca bazı saldırı türlerini azaltır.
• Güncellemeyi kurduktan sonra yeniden başlatılanın gerçekten PHP web işleyicisi olduğundan ve sitenin sayfalarının artık düzeltilmiş sürümde çalıştığından emin olun.

Ne oldu#

PHP'nin acil duyurusunda yorumlayıcının kendisindeki iki bellek yönetimi kusurundan söz ediliyor. Bu, belirli bir şablonun, eklentinin ya da CMS'in sıradan bir sorunu değil.

CVE-2026-109618'de bellek ayırma hatası, isteğin ayrıştırılmasını ara bir durumda kesebilir. Ardından temizleme mantığı, ortaya çıkan yapıların bir kısmına doğru şekilde hazırlanmışlar gibi davranır. CVE-2026-109619 ise sürecin yeniden kullanımıyla ilgilidir: veriler serbest bırakıldıktan sonra süreçte eskimiş bir referans kalabilir ve durum olağan şekilde güncellenmeden önce bir sonraki istek ona erişebilir.

Her iki durumda da başlangıç noktası, dışarıdan erişilebilen bir siteye gelen HTTP isteğidir. Yönetim paneline giriş, açığı olan bir DLE modülü ya da eklenti yüklemek zorunlu koşul değildir. Bu yüzden herkese açık projeler güncelleme sırasının en başına alınmalıdır.

PHP, en yüksek riskin şu anda mod_php ile ilişkilendirildiğini ayrıca belirtiyor: orada, kimliği doğrulanmamış bir isteğin saldırıyı uygulamanın kendi kodu çalışmadan önce başlattığı bir senaryo doğrulandı. Ancak PHP-FPM'i sırf farklı olduğu için güvenli saymak doğru olmaz. Etkilenen web kurulumlarının resmi listesinde farklı seçenekler sayılıyor: PHP-FPM, php-cgi, FrankenPHP; LiteSpeed.

Sorun kimleri ilgilendiriyor#

DLE sitesi sahibi genellikle motor sürümüne ve modül sürümlerine bakar. Bu durumda sıra farklıdır: önce sitenin sayfasını hangi PHP'nin çalıştırdığını bulmak gerekir.

Kontrol edilmesi gerekenler:

• sıradan paylaşımlı hostingdeki bir site;
• nginx ve PHP-FPM'li bir VPS;
• mod_php ya da PHP-FPM ile Apache;
• ISPmanager, Hestia, Plesk, cPanel ve benzeri panellerle yönetilen bir sunucu;
• yalnızca biri DLE kullansa bile aynı sunucudaki birkaç site;
• içinde PHP'nin bağımlılık olarak çalıştığı paneller ve hazır ürünler.

Son maddede hata yapmak kolaydır. Örneğin Plesk, kullanıcıların PHP işleyicilerini ve kendi iç sw-engine bileşenini ayrı ayrı günceller. Yalnızca siteler için PHP'yi güncellemek, panel bileşeninin de güncellendiği anlamına gelmez. Sürümlerin tam listesine ve yamaların durumuna, başkasının kılavuzundan tablo kopyalamak yerine kendi panel sağlayıcınızdan bakın.

Sorunu hangi sürümler kapatıyor#

PHP projesinin desteklediği dallar için düzeltme 21 Ekim'de çıktı:

Projenin kaynak kodundan derlenmiş PHP için daha düşük bir numara, belirtilen düzeltilmiş sürüme geçmeniz gerektiği anlamına gelir. Paket olarak kurulan PHP'de önce dağıtımınızın advisory duyurusuna bakın: sağlayıcı yamayı farklı numaralı bir sürüme taşımış olabilir. "Bende PHP 7.4.33 var" tek başına soruyu yanıtlamaz. Upstream 7.4, 8.0 ve 8.1 dallarının standart desteği sona erdi. PHP minimal kaynak backport dalları hazırladı, bazı dağıtımlar ve LTS sağlayıcıları da düzeltmeleri kendi paketlerine ekledi. Bu durumda temel sürüm numarası aynı kalabilir. Bu, EOL dalları için Plesk tablosunda da görülüyor.

İşte bu yüzden eski bir hostingde yamanın olmadığına kendi başınıza karar vermemeli ve "sunucu otomatik güncelleniyor" gibi genel bir söze güvenmemelisiniz. Desteğe net bir soru yazın: "Sitemin PHP işleyicisi için CVE-2026-109618 ve CVE-2026-109619 düzeltmesini onaylayın, paket sürümünü ve derleme tarihini belirtin." Bu size bir vaat değil, doğrulanabilir bir yanıt sağlar.

php -v neden kontrolün yalnızca başlangıcı#

VPS'te alışkanlıkla şu çalıştırılır:

php -v

Komut faydalıdır, ama komut satırının PHP'sini gösterir. Site başka bir PHP-FPM dalı, panelin alternatif ikili dosyası ya da ayrı bir LiteSpeed işleyicisi tarafından sunuluyor olabilir. Daha karışık durumlar da olur: CLI'de yeni sürüm zaten kurulmuştur, ama eski FPM worker'ları önceki çalışma zamanını bellekte tutmaya devam eder.

Kontrol sırası şöyle olmalı:

1. Hosting panelinde ya da site ayarlarında siteye atanmış PHP sürümünü ve işleyiciyi öğrenin.
2. SSH erişiminiz varsa bunu kurulu paketin sürümüyle karşılaştırın.
3. Güncellemeden sonra tam olarak sitenin web isteklerini işleyen servisi yeniden başlatın.
4. Sürümü, panelin dışarıya kapalı tanılama aracıyla ya da geçici, korumalı bir sayfayla kontrol edin. Sitenin kökünde herkese açık bir phpinfo() bırakmayın: sunucu hakkında gereksiz ayrıntıları ifşa eder.
5. Siteyi açın ve olağan kullanıcı işlemlerini yapın: panele giriş, görsel yükleme, haber kaydetme, iletişim formunun çalışması. Ardından PHP ve web sunucusunun hata günlüklerine bakın.

Paylaşımlı hostingde bunu çoğunlukla sağlayıcı yapar. Sizin göreviniz desteğe "PHP'yi güncelleyin" yazmak değil, belirli siteyi, PHP handler'ı ve iki CVE'yi belirtmektir. Panel PHP 8.4 seçmenize izin veriyorsa, "8.4" seçimi henüz 8.4.27 demek değildir: işleyicinin tam sürümünü göstermelerini isteyin.

VPS'te nasıl hareket edilir#

Sunucuda internetten tek bir komutu körü körüne kopyalayamazsınız: Debian, Ubuntu, AlmaLinux, kontrol panelleri ve üçüncü taraf depolar PHP'yi farklı şekillerde sunar. Güvenli sıra her yerde aynıdır.

Önce yapılandırmaların yedeğini alın ve mevcut paket sürümlerini kaydedin. Ardından paketleri dağıtımınızın güvenilir deposundan ya da panelinizin deposundan güncelleyin. PHP-FPM kullanılıyorsa, güncellemeden sonra ilgili havuzu ya da servisi yeniden başlatın. mod_php ile Apache için Apache'nin yeniden başlatılması gerekir. Bundan sonra kontrolü yalnızca SSH'de değil, web üzerinden de tekrarlayın.

Ubuntu açıkça uyarıyor: bir paket güncellemesinin otomatik uygulanması, zaten çalışmakta olan uygulamanın yeni kütüphaneyi kullandığını garanti etmez. İşleyici yeniden başlatılmalı ya da sunucu kendi prosedürünüze göre yeniden başlatılmalıdır. Yoğun bir sitede kısa bir bakım penceresi planlayın: önce canlı olmayan örneği, sonra ana düğümü güncelleyin, günlüğü ve erişilebilirliği kontrol edin.

Hestia, ISPmanager, Plesk ya da cPanel kullanıyorsanız, önce o panelin belgelerine bakın. Panel, ayrı PHP paketlerini ve sürümlerini sistemdeki /usr/bin/php'den bağımsız olarak yönetiyor olabilir. "Yeter ki yeni numarayı alayım" diye kendi başınıza üçüncü taraf bir depo kurmak bazen panelle bağlantıyı bozar ve siteye fiilen hizmet veren işleyiciyi kapatmaz.

Site PHP 7.4, 8.0 veya 8.1 üzerinde çalışıyorsa ne yapmalı#

PHP 7.4, 8.0 ve 8.1 ile durum daha karmaşıktır. Eski bir şablon ya da modül yeni dala hazır olmadığı için bir DLE sitesi yıllarca PHP 7.4 üzerinde çalışabilir. Ama "çalışıyor", "güncellemeye gerek yok" demek değildir. PHP projesi bu dallar için artık olağan güncellemeler yayınlamıyor.

Bundan sonra üç gerçekçi yol var.

Birincisi, hosting sağlayıcınızdan ya da Linux sağlayıcınızdan doğrulanmış bir backport almak. Bu, yalnızca mevcut CVE'leri kapatan geçici bir çözümdür, dala tam desteği geri getirmez.

İkincisi, desteklenen bir PHP dalına geçmek ve uyumsuz kodu düzeltmek. Hazırlık ve yedek gerektirir, ama her yeni açığı acil bir arama operasyonuna dönüştürmeyi bırakırsınız.

Üçüncüsü, düzeltme çıkana kadar herkese açık servisi yalıtmak ya da geçici olarak kapatmak. Hoş değil, ama kritik bir RCE'si olan siteyi internete açık bırakıp şansa güvenmekten daha dürüsttür.

Plesk'te bazı EOL dalları için düzeltilmiş paket aynı numarayı koruyup farklı bir derleme tarihine sahip olabilir. Yani 7.4.33 dizesine göre kontrol yetmez. Panel verileri, paket tarihi ya da sağlayıcının resmi yanıtı gerekir.

Geçici önlemler: ne sağlarlar, ne sağlamazlar#

PHP'nin, fiziksel olarak zamanında güncelleme yapamayanlar için önerileri var. Bunlar "güncellemeden nasıl korunulur" başlığına dönüştürülmemeli. Resmi tutum kesin: tam koruma yalnızca düzeltilmiş PHP'nin kurulmasıyla sağlanır.

CVE-2026-109618 için PHP projesi, memory_limit için uygulamanın kontrol ettiği üst sınırın kaldırılmasını, POST isteklerinin boyutunun sınırlandırılmasını ve yükleme sınırının genel POST sınırının altında tutulmasını öneriyor. Bu, kontrollü bellek tükenmesi üzerinden doğrulanmış yolu daraltır, ama gerçek bir bellek ayırma hatasını dışlamaz ve ikinci CVE'yi kapatmaz. Bu önlemlerin tam sınırları PHP advisory duyurusunda listeleniyor.

CVE-2026-109619 için, isteğin ayrıştırılmasından önce uygulanan yapılandırma düzeyinde session.upload_progress.enabled ayarının kapatılması ve worker'ların zorunlu olarak yeniden başlatılması anılıyor. Bu, oturumlar üzerinden doğrulanmış yolları kapatır, ama olası tüm varyantları değil. Bunu bir DLE modülü içinde ini_set() ile ya da .user.ini ile değiştirmek yetmez: kod çalıştığında istek zaten ayrıştırılmış olur.

Cloudflare, WAF ve istek filtreleri PHP'nin belleğini düzeltmez ve güncellemeyi ertelemek için bir neden olmamalıdır. Aynısı dosya yükleme formunu kaldırmak için de geçerli: bu, tüm çalışma zamanının güvenli olduğunun kanıtı değildir.

Güncellemeden sonra DLE sitesinde neler kontrol edilmeli#

Güncellemeden sonra ana sayfayı bir kez açmak yetmez. PHP güncellemesi eklentileri, OPcache'i, görsel işlemeyi, eski fonksiyon çağrılarını ve kodlama ayarlarını etkileyebilir.

Ana sayfa ve birkaç farklı bölümle başlayın. Ardından yönetim paneline girin, bir haberi düzenlemeye açın, herkese açık olmayan bir kategoride test kaydı kaydedin ya da kontrolden sonra silin, test görseli yükleyip silin, etkinse yorumları ya da iletişim formunu kontrol edin. PHP'nin error_log dosyasına ve web sunucusu günlüğüne bakın: ziyaretçinin görmediği uyarılar, eski bir modülün uyumsuzluğunu çoğu zaman ilk gösteren şeydir.

Kuyrukları, ayrıştırıcıları ya da cron görevleri olan bir sitede bunları da kontrol edin. Bunlar web'den farklı bir CLI PHP kullanıyor olabilir, bu yüzden zamanlayıcı görevinde aynı düzeltilmiş dal ya da backport içeren doğrulanmış paket belirtilmelidir. Yedek ve geri alma planı olmadan sürümü canlıda tüm siteler için aynı anda değiştirmeyin.

Ele geçirilme şüphesi varsa#

Yama bilinen yolu durdurur, ama sunucuda zaten bırakılmış kodu silmez. Herkese açık bir sitede öncelik erişimi kısıtlamak ya da düzeltmeyi kurmaktır; bunu uzun bir denetim uğruna ertelemeyin. Durum elveriyorsa, çalışmadan önce ya da hemen sonra web sunucusu ve PHP günlüklerini, son değiştirilen dosyaların listesini, cron görevlerini ve paneldeki yeni kullanıcılarla ilgili verileri saklayın. Ardından yükleme klasörlerindeki şüpheli PHP dosyalarını, bilinmeyen cron görevlerini, fazladan yönetici hesaplarını, .htaccess içindeki değişiklikleri ve giden bağlantıları kontrol edin.

Antivirüs bir şey bulmadı diye siteyi temiz ilan etmeyin. Her tuhaf dosyayı da otomatik olarak bu açığın sonucu saymayın: tarihlerin, günlüklerin ve dosyanın amacının kontrol edilmesi gerekir. Birleşik Krallık NCSC, hızla güncelleme yapamayan ya da servisi kapatamayanlara, çalışmadan önce sistemi ele geçirilme belirtileri açısından değerlendirmelerini ve gerekirse olay müdahale uzmanlarından destek almalarını öneriyor.

Kaynaklar#

• PHP: Security advisory: Critical remote code execution vulnerabilities, update now
• ENISA: Joint statement on critical PHP vulnerabilities
• NCSC UK: Critical security issue affecting PHP
• Ubuntu: php2shell vulnerability fixes available
• Plesk: PHP RCE in PHP shipped with Plesk

Kaynaklara göre kontrol edildi: 22.10.2026. Teknik önerileri kendi hosting ve panel belgelerinizle karşılaştırın: paket içerikleri ve yeniden başlatma yöntemleri sağlayıcıdan sağlayıcıya farklılık gösterir.

Test edildi: Официальные источники PHP, ENISA, NCSC, Ubuntu и Plesk — 22.10.2026