[ÖNEMLİ GÜVENLİK DUYURUSU] PHP RCE Açıkları (CVE-2026-109618 / CVE-2026-109619): Alınması Gereken Önlemler

PHP projesi 21 Ekim 2026’da iki kritik güvenlik açığını kapatan acil sürümler yayımladı. CVE-2026-109618 ve CVE-2026-109619 kodlu açıklar, belirli koşullar oluştuğunda saldırganın hiçbir oturum açmadan, yalnızca internet üzerinden gönderdiği isteklerle sunucuda kod çalıştırmasına imkân verebiliyor. PHP güvenlik ekibi iki açığı da CVSS v4.0’a göre 9,2 puanla “kritik” olarak sınıflandırıyor.

Bu PHP RCE açığı, WordPress dahil PHP ile çalışan web sitelerinin büyük bölümünü ilgilendiriyor. Panik gerektiren bir durum değil, ama ertelenecek bir iş de değil: Çözüm net ve uygulanabilir. Sitenizin kullandığı PHP sürümünü öğrenmeniz, yamalı sürüme geçmeniz ve güncellemenin gerçekten devreye girdiğini doğrulamanız gerekiyor. Bu duyuruyu web sitesi sahipleri, hosting müşterileri ve kendi sunucusunu yöneten ekipler için hazırladık.

PHP RCE açığı nedir?

RCE (Remote Code Execution), Türkçesiyle uzaktan kod yürütme, bir saldırganın sunucuya fiziksel ya da yetkili bir erişimi olmadan, ağ üzerinden gönderdiği isteklerle o sunucuda kendi komutlarını çalıştırabilmesidir. Bir web sitesinde form göndermek ya da dosya yüklemek gibi sıradan işlemler, açığı olan bir sistemde bu kapının anahtarına dönüşebilir.

Bu iki açıkta kod, PHP’yi çalıştıran web işçisinin (worker) kullanıcı hesabıyla yürütülür. Uygun koşullar oluşursa bunun olası sonuçları şunlardır:

• Sitenin dosyalarını okumak, değiştirmek ya da yeni dosyalar eklemek
• Yapılandırma dosyalarındaki veritabanı şifrelerine ve API anahtarlarına ulaşmak
• Siteye fark edilmesi zor bir arka kapı yerleştirmek
• Sunucuyu spam, kötü amaçlı yazılım dağıtımı ya da başka sistemlere saldırı için kullanmak

Bu sonuçlar her sistemde otomatik olarak gerçekleşmez. PHP’ye göre saldırının başarısı; PHP’nin derleniş biçimine, eklentilere, önündeki web sunucusuna ve bellek düzenine bağlıdır. Yine de kimlik doğrulaması gerektirmemesi ve internete açık her PHP sitesini aday yapması riski ciddi kılıyor.

Güncel durum: Ne biliniyor?

Açıkların ayrıntıları planlanan tarihten önce sızdı ve PHP güncellemeleri 21 Ekim’de yayımladı. ABD siber güvenlik ajansı CISA, 21 Ekim tarihli uyarısında yayın anında istismar gözlemlemediğini belirtti; açıklar 23 Ekim itibarıyla CISA’nın aktif istismar edilen açıklar kataloğunda (KEV) yer almıyor. Bazı güvenlik firmaları ise tuzak sistemlerinde istismar girişimleri gördüğünü bildiriyor. Bu bildirimler girişimlerle başarılı ihlalleri ayırmıyor, ama güncellemeyi ertelememek için yeterli bir sebep.

CVE-2026-109618 ve CVE-2026-109619 arasındaki fark nedir?

PHP, her web isteği için bellek ayırır, isteği işler ve istek bittiğinde bu belleği temizler. İki açık da bu döngüdeki hatalardan doğuyor ve sonuçları benzer; ancak hata mekanizmaları farklı noktalarda ortaya çıkıyor.

CVE-2026-109618: Bellek tükenince yarım kalan veri

PHP, bir isteğe ayrılan bellek sınırına ulaştığında (out of memory, OOM) çalışmayı anında keser. Resmi duyuruya göre bu kesinti bazen isteğe ait iç veriler henüz tam hazırlanmadan gerçekleşiyor ve istek sonundaki temizlik adımı yarım kalan veriyi geçerliymiş gibi işliyor. Ortaya çıkan bozuk bellek durumu, uygun koşullarda kod yürütmeye dönüştürülebiliyor.

Bellek tükenmesine giden yolların başında çok parçalı (multipart) form ve dosya yükleme istekleri geliyor. Saldırı Apache mod_php üzerinde varsayılan ayarlarla doğrulanmış; PHP-FPM kaynak kod analizine göre etkilenebilir, ancak FPM için tam bir istismar gösterilmemiş.

CVE-2026-109619: Serbest bırakılmış belleği gösteren eski durum

PHP işçi süreçleri art arda birçok isteğe hizmet verir. Bir istek bittiğinde, o isteğin belleğini gösteren bazı genel durum bilgilerinin sıfırlanması gerekir. Ölümcül hata, zaman aşımı ya da bellek tükenmesi gibi durumlarda bu sıfırlama atlanabiliyor. Aynı işçideki sonraki istek bu eski bilgiye eriştiğinde, artık serbest bırakılmış belleği kullanmış oluyor (“use-after-free”).

İstismar için aynı işçiye ulaşan iki uygun isteğin bir araya gelmesi gerekiyor. Duyuruda doğrulanan yollar arasında PHP 8.5’te açık fatal_error_backtraces ayarı ve varsayılan olarak açık gelen “session upload progress” özelliği var.

	CVE-2026-109618	CVE-2026-109619
Resmi başlık	RCE via OOM corruption	RCE via stale global state
Hata türü	Bellek tükenmesinde yarım kalan veri	Serbest bırakılmış belleğin kullanılması
Tetikleyen durum	Bellek sınırına ulaşan istek	Hatayla biten istekten sonra gelen istek
Doğrulanmış en güçlü senaryo	Apache mod_php, varsayılan ayarlar	PHP 8.5 + fatal_error_backtraces; session upload progress
Önem derecesi (PHP, CVSS v4.0)	9,2 Kritik	9,2 Kritik
Tam çözüm	Yamalı PHP sürümü	Yamalı PHP sürümü

Bu yazıda bilinçli olarak istismar ayrıntısına girmiyoruz; teknik ayrıntılar kaynaklardaki resmi PHP duyurularında yer alıyor.

Kimler risk altında?

PHP’nin duyurusuna göre web isteklerine yanıt veren tüm PHP kurulumları risk altında: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. Risk en yüksek Apache mod_php’de, çünkü burada saldırı uygulamanın kendi kodu hiç çalışmadan tetiklenebiliyor. Etkilenme koşulları yapılandırmaya göre değişse de bu, güncellemeyi ertelemek için bir sebep değildir.

Özellikle şu gruplar durumunu kontrol etmeli:

• PHP tabanlı web siteleri: Kurumsal siteler, e-ticaret mağazaları, forumlar ve özel yazılmış PHP uygulamaları
• WordPress ve benzeri içerik yönetim sistemleri: WordPress, Joomla, Drupal, OpenCart, PrestaShop gibi PHP ile çalışan tüm sistemler
• Paylaşımlı hosting kullanıcıları: PHP’yi sağlayıcı kurar ve günceller, ancak hesabınızda hangi PHP sürümünün seçili olduğu sizin kontrolünüzdedir
• PHP-FPM ya da Apache mod_php çalıştıran sunucular: Kendi VDS’ini ya da fiziksel sunucusunu yöneten işletmeler ve sistem yöneticileri
• Konteyner ortamları: Docker imajlarındaki PHP, imaj yeniden oluşturulmadıkça eski sürümde kalır
• PHP’yi içinde taşıyan ürünler: Bazı hazır yazılım paketleri ve cihaz yönetim panelleri kendi PHP kopyasını kullanır; bunlar için üreticinin güncellemesini beklemek gerekir

WordPress kullanıcıları için önemli bir ayrım var: WordPress çekirdeğini, temanızı ve eklentilerinizi güncellemek uygulama katmanını günceller. Bu açıklar ise uygulamanın altında çalışan PHP motorunda. Yönetim panelinde her şey “güncel” görünürken PHP’nin yamasız bir sürümde çalışması mümkündür. İki katmanın da ayrı ayrı kontrol edilmesi gerekir.

Etkilenen ve düzeltilmiş PHP sürümleri

PHP projesinin 21 Ekim 2026 tarihli duyurusuna göre desteklenen dallarda düzeltme içeren sürümler 8.5.12, 8.4.27, 8.3.36 ve 8.2.35’tir. PHP 8.1 ve öncesi artık PHP projesinden güncelleme almıyor.

PHP dalı	Etkilenen sürümler	Düzeltilmiş sürüm / izlenecek yol	Yapmanız gereken
8.5	8.5.12 öncesi	8.5.12	8.5.12 ya da dağıtımınızın yamalı paketine güncelleyin
8.4	8.4.27 öncesi	8.4.27	8.4.27 ya da dağıtımınızın yamalı paketine güncelleyin
8.3	8.3.36 öncesi	8.3.36	8.3.36 ya da dağıtımınızın yamalı paketine güncelleyin
8.2	8.2.35 öncesi	8.2.35	Güncelleyin; 8.2’nin desteği 31 Aralık 2026’da bitiyor, 8.3 ya da üstüne geçişi planlayın
8.1, 8.0, 7.4	Etkilenmiş kabul edin	PHP projesinden yeni sürüm yok; dağıtım ya da LTS üreticisi yaması veya PHP’nin yayımladığı kaynak kod yamaları	Desteklenen bir dala geçin; geçemiyorsanız üreticinizin yamasını doğrulayın
7.3 ve öncesi	Etkilenmiş kabul edin	PHP’nin yayımladığı kaynak kod yamaları bu dalları kapsamıyor	Desteklenen bir dala geçiş planlayın, o zamana kadar riski azaltın

PHP’nin resmi duyurusu destek dışı dallar için ayrı bir etkilenme listesi vermiyor. Ancak PHP’nin 7.4, 8.0 ve 8.1 için kaynak kod yaması yayımlaması ve Birleşik Krallık Ulusal Siber Güvenlik Merkezi’nin (NCSC) “PHP’nin herhangi bir sürümünü kullanan kurumlar etkileniyor” değerlendirmesi nedeniyle bu sürümleri etkilenmiş kabul etmek gerekir.

Dağıtım paketlerinde dikkat edilmesi gereken bir nokta var: Debian, Ubuntu ve Red Hat tabanlı dağıtımlar yamayı çoğu zaman kendi sürüm numaralarındaki pakete ekler. PHP resmi duyurusunda dağıtımların yamaları önceden aldığını belirtiyor. Bu nedenle php -v çıktısında 8.3.36’dan küçük bir numara görmek, paketin yamasız olduğu anlamına gelmeyebilir. Doğru yöntem, paketin değişiklik kaydında CVE numarasını aramaktır.

Alınması gereken önlemler: 10 adımlık kontrol listesi

1. Tüm PHP kurulumlarınızın envanterini çıkarın. Canlı siteler, test ortamları, konteynerler ve PHP’yi içinde taşıyan ürünler listeye girmeli; unutulmuş bir test sitesi de sunucuyu riske atar.
2. İnternete açık sistemlerden başlayın. CISA ve NCSC de önceliği doğrudan erişilebilen sitelere ve yönetim panellerine veriyor.
3. Sitenin gerçekten kullandığı sürümü kontrol edin. php -v yalnızca komut satırındaki PHP’yi gösterir; web sunucusu başka bir sürüm kullanıyor olabilir. Kontrol panelinizdeki PHP sürümü ekranına ya da WordPress’te Araçlar → Site Sağlığı → Bilgi → Sunucu bölümüne bakın.
4. Düzeltmeyi içeren sürüme yükseltin. Hedef, dalınızın yamalı sürümü ya da dağıtımınızın yamalı paketidir. Destek dışı dallarda kalıcı çözüm desteklenen bir dala geçmektir.
5. Önce yedek alın, mümkünse test edin. Aynı dal içindeki güvenlik sürümleri genellikle sorun çıkarmaz, ama yedek geri dönüş yolunuzdur. Dal değiştiriyorsanız (örneğin 7.4’ten 8.3’e) tema ve eklenti uyumluluğunu önce test edin.
6. PHP süreçlerini yeniden başlatın. Paket güncellense bile çalışan PHP-FPM ve Apache süreçleri eski kodu bellekte tutar. Konteynerlerde imajı yeniden oluşturup konteyneri yeniden başlatın.
7. Düzeltmenin etkin olduğunu doğrulayın. Web tarafındaki sürümü tekrar kontrol edin; dağıtım paketlerinde değişiklik kaydında CVE numarasını arayın.
8. Günlükleri inceleyin. Olağandışı çok parçalı istekleri, sık “Allowed memory size exhausted” ve beklenmedik ölümcül hata kayıtlarını arayın. CISA, PHP işçilerinin kabuk (sh, bash) ya da indirme araçları (curl, wget) başlatmasını bir belirti olarak gösteriyor.
9. Şüpheli bir iz varsa ihlal incelemesi yapın. Güncelleme, önceden yerleştirilmiş bir arka kapıyı silmez. Yükleme klasörlerindeki yeni PHP dosyalarını, tanımadığınız yönetici hesaplarını ve yeni cron görevlerini kontrol edin; iz bulursanız uzman desteği alın.
10. Güncelleme gecikiyorsa geçici önlemleri değerlendirin. Aşağıdaki resmi önlemler saldırı yüzeyini daraltır ama sistemi güvenli hale getirmez. NCSC, ikisinin de mümkün olmadığı sistemleri çözüme kadar çevrimdışı almayı önerir.

Linux sunucularda sürüm ve süreç kontrolü

Paket ve servis adları dağıtıma göre değişir; 8.3 kısmını kendi kurulumunuza göre düzenleyin.

# Komut satırındaki PHP sürümü
php -v

# Çalışan PHP-FPM servisleri
systemctl list-units --type=service | grep -i php

# Apache'de mod_php yüklü mü?
apachectl -M 2>/dev/null | grep -i php

# Debian/Ubuntu: kurulu paketin değişiklik kaydında CVE araması
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep "CVE-2026-1096"

# RHEL/AlmaLinux/Rocky: aynı kontrol
rpm -q --changelog php-common | grep "CVE-2026-1096"

Güncellemeden sonra ilgili servisleri yeniden başlatın:

sudo systemctl restart php8.3-fpm   # Debian/Ubuntu
sudo systemctl restart php-fpm      # RHEL tabanlı dağıtımlar
sudo systemctl restart apache2      # mod_php kullanan Apache (RHEL'de: httpd)

cPanel ya da Plesk kullanan sunucularda PHP paketleri panel üreticisinin depolarından gelir; panelin güncelleme aracını kullanın ve üreticinin duyurusunu takip edin.

Güncelleme hemen yapılamıyorsa: Resmi geçici önlemler

PHP’nin önerdiği geçici önlemler yalnızca sunucu yöneticileri içindir ve sitenizin dosya yükleme ya da bellek davranışını değiştirebilir. Hepsini birden uygulamak yerine yapılandırmanızı tanıyan biri tek tek değerlendirmelidir. Ayarlar php.ini, FPM havuzu ya da sunucu yapılandırmasında yapılmalı (ini_set() ya da .user.ini ile değil) ve ardından tüm PHP işçileri yeniden başlatılmalıdır.

Önlem	İlgili açık	Dikkat edilecek nokta
session.upload_progress.enabled=0	CVE-2026-109619	Doğrulanmış oturum yollarını kapatır. Dosya yükleme ilerleme çubuğu bu özelliğe dayanıyorsa önce test edin.
PHP 8.5’te fatal_error_backtraces=0	CVE-2026-109619	Yalnızca doğrulanmış en güçlü senaryoyu kapatır, diğer yolları değil
Düşük post_max_size (yükleme yoksa 8M, varsa 32M)	CVE-2026-109618	upload_max_filesize bu değerin altında kalmalı; büyük dosya yükleyen siteler etkilenir
Web sunucusu ya da proxy düzeyinde istek sınırları	CVE-2026-109618	İstek boyutu, alan, parça ve başlık sayısı sınırlanır; Content-Length bilgisi olmayan istekleri de kapsamalı
memory_limit=-1	CVE-2026-109618	PHP’nin bellek sınırını kaldırır; kontrolsüz bellek kullanımına karşı konteyner ya da cgroup sınırı gerekir. Uzman kararı olmadan uygulamayın.

PHP, RLIMIT_AS ve RLIMIT_DATA sınırlarının bellek sınırı yerine kullanılmamasını özellikle belirtiyor; bu sınırlar açığı tetikleyen bellek hatasına yol açabilir. PHP 23 Ekim’deki ek bilgilendirmesinde session.upload_progress.enabled=0 ayarını yamalı sistemlerde de bir sonraki olağan sürüme kadar korumayı öneriyor. Bu not, yalnızca olağandışı bir yapılandırmada ortaya çıkan ayrı bir açıkla (CVE-2026-115560) ilgili.

WAF ve diğer koruma katmanlarının rolü

Bir web sitesinin güvenliği tek bir araçla sağlanmaz; her katmanın görevi farklıdır:

• PHP güncellemesi: Açığın kaynağını ortadan kaldırır. Bu iki CVE için tek tam çözümdür.
• WAF (web uygulaması güvenlik duvarı): Siteye gelen HTTP isteklerini inceler; bilinen saldırı kalıplarını, kötü niyetli botları ve şüpheli istekleri sunucuya ulaşmadan süzer.
• Ağ güvenlik duvarı: Hangi portlara ve IP adreslerine erişilebileceğini belirler; uygulama içeriğine bakmaz.
• Rate limit: Aynı kaynaktan gelen aşırı istekleri sınırlar ve deneme yanılma saldırılarını yavaşlatır.
• DDoS koruması: Hizmeti hacim yoluyla erişilemez kılmaya çalışan saldırıları karşılar.

Bu açıklar özelinde bir WAF, istek boyutunu ve çok parçalı istekleri sınırlayarak PHP’nin önerdiği ön uç sınırlamalarına yardımcı olabilir; CISA da WAF’ın geçici koruma sağlayabileceğini belirtiyor. Ancak herhangi bir WAF kuralının bu iki açığı tamamen engellediğine dair resmi bir doğrulama yok. WAF’ın hangi saldırılara karşı nasıl çalıştığını ve sınırlarını WAF nedir ve web sitenizi nasıl korur? rehberimizde ayrıntılı olarak anlattık.

Önem Bilişim’in Layer 7 WAF koruması; HTTP flood, kötü niyetli bot ve rate limit gibi uygulama katmanı tehditlerine karşı sitenizi taşımadan, DNS yönlendirmesiyle devreye girer. Bu hizmet PHP güncellemesinin yerine geçmez ve bu CVE’ler için bir çözüm olarak sunulmamalıdır. Güncellemeyi yaptıktan sonra savunmanıza ek bir katman eklemek istiyorsanız Layer 7 WAF koruma hizmetimizi inceleyin.

İlginizi çekebilir: VDS Sunucunuzu Hackerlardan Korumak İçin Yapmanız Gereken İlk 5 Ayar

Önem Bilişim kullanıcıları ne yapmalı?

Atmanız gereken adımlar, kullandığınız hizmetin türüne ve sunucuda kimin yetkili olduğuna göre değişir:

• Paylaşımlı hosting kullanıyorsanız: Hosting paketlerinde sunucunun bakımı ve güvenlik güncellemeleri sağlayıcının sorumluluğundadır. Sizin tarafınızdaki iş, kontrol panelinizde hesabınıza hangi PHP sürümünün seçili olduğunu kontrol etmektir. 7.4, 8.0 ya da 8.1 gibi destek dışı bir dal seçiliyse, sitenizin uyumluluğunu kontrol ederek desteklenen bir dala geçin. Hosting altyapısında sorumlulukların nasıl paylaşıldığını görmek için Profesyonel SSD Hosting hizmetimizi inceleyin.
• WordPress siteniz varsa: Hem PHP sürümünü hem de WordPress çekirdeği, tema ve eklenti güncellemelerini ayrı ayrı kontrol edin. Site Sağlığı ekranı, sitenizin kullandığı PHP sürümünü kendi gözünüzle görmenin en kolay yoludur. WordPress için ayrılmış kaynaklar ve panelden yönetilebilen PHP ayarlarıyla bir altyapı arıyorsanız WordPress hosting çözümlerimizi inceleyin.
• Kendi VDS’inizi ya da fiziksel sunucunuzu yönetiyorsanız: Sunucuda yönetici (root) yetkisi sizdeyse PHP güncellemesi, servislerin yeniden başlatılması ve doğrulama da sizin sorumluluğunuzdadır. Yukarıdaki kontrol listesini sunucunuzdaki her PHP kurulumu için ayrı ayrı uygulayın.
• Yönetici yetkiniz ya da teknik bilginiz yoksa: Rastgele PHP ayarı değiştirmek, açığı kapatmadan sitenizi bozabilir. Bu durumda müşteri panelinden destek talebi açmanız ya da destek ekibimize yazmanız daha güvenli bir yoldur.

Sık sorulan sorular

PHP RCE açığı nedir?

Uzaktan kod yürütme (RCE), saldırganın ağ üzerinden gönderdiği isteklerle sunucuda kendi kodunu çalıştırabilmesidir. CVE-2026-109618 ve CVE-2026-109619, uygun koşullarda bunu oturum açmadan mümkün kılabilen iki PHP açığıdır.

CVE-2026-109618 ile CVE-2026-109619 arasındaki fark nedir?

CVE-2026-109618’de bellek tükendiğinde yarım kalan veri, temizlik sırasında geçerliymiş gibi işlenir. CVE-2026-109619’da ise önceki istekten kalan ve serbest bırakılmış belleği gösteren durum, aynı işçideki sonraki istek tarafından kullanılır. Sonuçları benzer, mekanizmaları farklıdır.

Hangi PHP sürümüne güncelleme yapmalıyım?

Kullandığınız dalın yamalı sürümüne: 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35. Dağıtım paketi kullanıyorsanız dağıtımınızın yamalı paketi de yeterlidir. 8.1 ve öncesini kullanıyorsanız desteklenen bir dala geçmeniz gerekir; 8.2’nin de desteği 31 Aralık 2026’da bitiyor.

WordPress’i güncelledim, yine de risk var mı?

Evet, olabilir. WordPress güncellemesi uygulamayı günceller; bu açıklar ise WordPress’in altında çalışan PHP motorundadır. Site Sağlığı ekranından sitenizin kullandığı PHP sürümünü kontrol edin ve yamalı sürümde olduğundan emin olun.

WAF kullanmak bu PHP güvenlik açığını kapatır mı?

Hayır. WAF bazı saldırı yollarını zorlaştırabilir ve güncellemeye kadar geçen sürede ek bir katman sağlayabilir. Ancak açığı kapatmaz; PHP’ye göre tek tam çözüm yamalı sürüme güncellemektir.

Hosting sağlayıcımın PHP’yi güncellediğini nasıl anlarım?

Kontrol panelinizdeki PHP sürümü bilgisine ya da WordPress Site Sağlığı ekranına bakabilirsiniz. Sürüm numarası dağıtım paketi nedeniyle farklı görünüyorsa sağlayıcınıza bu iki CVE’nin yamalanıp yamalanmadığını doğrudan sorun.

Sonuç: Kontrol edin, güncelleyin, doğrulayın

Bu iki açık ciddi, ama çözümleri belli. Öncelik sırası şöyle:

1. Sitenizin kullandığı PHP sürümünü kontrol edin.
2. İlgili güvenlik düzeltmesini gecikmeden uygulayın.
3. PHP süreçlerini yeniden başlatıp düzeltmenin etkin olduğunu doğrulayın.
4. Emin olmadığınız her adımda teknik destek alın.

Sisteminizin durumunu bugün değerlendirmeniz, olası bir ihlalle uğraşmaktan çok daha az zaman alır. Hangi sürümü kullandığınızdan ya da güncellemenin nasıl yapılacağından emin değilseniz Önem Bilişim teknik destek ekibiyle iletişime geçin.

Kaynaklar

Bu yazıdaki teknik bilgiler 23 Ekim 2026 itibarıyla aşağıdaki resmi kaynaklardan doğrulanmıştır. Durum değişebileceği için güncel bilgiyi kaynakların kendisinden takip edin.

• PHP: Security advisory: Critical remote code execution vulnerabilities, update now (php.net, 21 Ekim 2026)
• PHP: Informational advisory: Session upload progress (php.net, 23 Ekim 2026)
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618) (PHP güvenlik ekibi, 21 Ekim 2026)
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619) (PHP güvenlik ekibi, 21 Ekim 2026)
• NCSC: Critical security issue affecting PHP (Birleşik Krallık NCSC, 21 Ekim 2026, son güncelleme 23 Ekim 2026)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (ABD CISA, 21 Ekim 2026)
• NHS England Digital: Cyber Alert CC-4875 (NHS England)