Ne oldu?
CISA, CVE-2026-109618 ve CVE-2026-109619 numaralı PHP açıklarını 26 Ekim 2026’da aktif istismar edilen güvenlik açıkları kataloğuna ekledi.
PHP2Shell olarak anılan bu iki açık, uygun koşullarda kimlik doğrulaması gerektirmeden sunucuda kod çalıştırılmasına yol açabiliyor. Sorun, PHP’nin istek işleme sırasında bellek ve iç durum bilgisini yönetmesiyle ilgili.
CISA’nın katalog eklemesi, açığın gerçek saldırılarda kullanıldığı anlamına geliyor. KEV listesi yalnızca teorik risk taşıyan açıkları değil, sahada istismar edildiği doğrulanmış açıkları içerir. Bu da kurumlar için takvimi değiştirir: “sıradaki yama döneminde hallederiz” yaklaşımı artık geçerli değil.
PHP geliştirme ekibi düzeltmeleri 21 Ekim’de yayımladı. Yama ile istismarın doğrulanması arasındaki kısa süre, saldırganların düzeltmeyi incelediği yaygın bir tabloya işaret ediyor: yama çıktığında açığın ayrıntıları da görünür hâle gelir.
Yama yayımlandığı andan itibaren güvenlik, yamanın kendisinden çok ne kadar hızlı uygulandığıyla ölçülür.
Hangi sistemler incelenmeli?
Konu belirli bir WordPress eklentisiyle sınırlı değil. PHP çekirdeği etkilendiği için kurumun PHP ile web isteği işleyen bütün sistemleri değerlendirilmelidir.
Kontrol kapsamına şunları alın:
- Kurumsal web siteleri ve içerik yönetim sistemleri.
- E-ticaret uygulamaları, müşteri portalları ve özel yazılımlar.
- PHP içeren yönetim panelleri ve üçüncü taraf ürünler.
- Konteynerlerde veya farklı sunucularda çalışan ayrı PHP kurulumları.
PHP’nin açıklamasında PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed kurulumları kapsamda yer alıyor. Üretici, gösterilmiş istismar nedeniyle mod_php için riski özellikle yüksek değerlendiriyor.
Bu liste, envanterin neden sunucu listesiyle sınırlı tutulmaması gerektiğini de anlatıyor. Aynı fiziksel makinede birbirinden habersiz üç ayrı PHP kurulumu bulunabilir; birinin güncellenmesi diğerlerini kapsamaz.
Bir sistemin dışarıdan normal görünmesi, güvenli olduğu anlamına gelmez.
Hangi sürümler düzeltme içeriyor?
İki PHP2Shell açığı için düzeltme içeren sürümler:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Linux dağıtımları ve uzun süreli destek sağlayıcıları düzeltmeleri kendi paketlerine aktarabilir. Bu nedenle yalnızca görünen sürüm numarasına bakmayın; kullanılan paketin ilgili iki CVE için düzeltme içerdiğini sağlayıcınızdan doğrulayın.
PHP 8.1 ve daha eski dallar için PHP projesinin düzenli desteği bulunmuyor. Sağlayıcınızın sunduğu düzeltmeyi veya desteklenen bir sürüme geçiş planını kontrol edin.
Windows kullananlar için ayrıca bir ayrıntı var: 26 Ekim’de yayımlanan 8.5.12-1, 8.4.27-1, 8.3.36-1 ve 8.2.35-1 paketleri, ayrı bir Brotli açığı için güncellenmiş bağımlılık içeriyor.
Ne yapmalısınız?
- PHP kullanan sistemlerin envanterini çıkarın.
- İnternete açık sistemleri önceliklendirerek düzeltme içeren paketleri uygulayın.
- Çalışan servislerin ve konteynerlerin güncel paketleri kullandığını doğrulayın.
- Güncelleme öncesindeki dönemi de kapsayacak şekilde şüpheli süreçleri ve sunucu kayıtlarını inceleyin.
- Web sunucusu kayıtlarında istek gövdesi işleme hatalarına, açıklanamayan alt süreçlere ve olağandışı dış bağlantılara bakın.
- PHP’nin 23 Ekim tarihli session upload progress duyurusunu da teknik ekibinizle değerlendirin.
- Güncelleme hemen uygulanamıyorsa sağlayıcınızın resmî geçici önlemlerini izleyin ve dış erişimi azaltın.
- Aynı paketi kullanan tüm ortamlarda (test, ön üretim, üretim) güncellemeyi tamamlayın; yarısı güncellenmiş bir yapı, tamamı güncellenmemiş bir yapı kadar risklidir.
Geçici önlemler, güncellemenin yerini tutmaz. Güncelleme de daha önce gerçekleşmiş olabilecek bir ihlali kendiliğinden temizlemez. İstismar doğrulandığına göre, güncelleme öncesi dönemin ayrıca incelenmesi gerekir.
Asıl mesele
PHP çoğu kurumda tek bir sunucuda bulunmaz. Web sitesinde, bir yönetim panelinde veya unutulmuş bir uygulamada ayrı ayrı çalışabilir.
İstismarın doğrulanmış olması, konuyu “yama listesindeki bir madde” olmaktan çıkarıp bir zaman meselesine dönüştürüyor. Buradaki tek değişken, güncellemenin ne kadar sürede kurulduğu.
Bu yüzden “PHP’yi güncelledik” cümlesinin karşılığı bir sistem listesi olmalıdır. Hangi kurulum bulundu, hangi paket uygulandı, hangi servis yeniden başlatıldı ve nasıl doğrulandı?
Yönetici olarak isteyebileceğiniz en somut çıktı budur: kapsamı belli, sorumlusu belli ve tamamlandığı doğrulanmış bir güncelleme kaydı.
CISA’nın katalog eklemesi bir uyarı değil, bir kayıttır: bu açık artık sahada kullanıldı. Kurumun bu kayda vereceği cevap da belgeden değil, güncellenmiş sistemlerden oluşmalı.