Bir Bakışta

Sizin sisteminiz

Etkileniyor musunuz?

Web isteği karşılayan bir PHP kurulumunuz (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ya da LiteSpeed) varsa ve sürümü 8.2.35, 8.3.36, 8.4.27 ya da 8.5.12'den eskiyse etkilendiğinizi varsayın. WordPress, Drupal, Magento ve Laravel gibi PHP tabanlı uygulamalar da buna dahildir.

TR7 ürünleri

TR7 etkileniyor mu?

Hayır. TR7 cihazında HTTP isteklerini işleyen bir PHP bileşeni bulunmadığından TR7 ürünleri bu açıklardan etkilenmiyor. Ayrıntı: TR7 Etkileniyor mu?

Eylem

Şimdi ne yapmalı?

  1. Web uygulama sunucularınızda PHP'yi güncelleyin ve tüm PHP worker'larını yeniden başlatın.
  2. Bugün güncelleyemiyorsanız bu sunucularda geçici PHP ayarlarını uygulayın.
  3. Güncelleme tamamlanana kadar TR7 WAF-WAAP'ta temel koruma ayarlarını uygulayın; PHP uygulamalarınızı Blocking mode'a almak bunun ilk adımıdır.

Temel Bilgiler

Bülten NoTR7-SA-2026-001
AdPHP2Shell
CVE'lerCVE-2026-109618: bellek yetmezliği bozulması üzerinden uzaktan kod çalıştırma
CVE-2026-109619: bayat genel durum üzerinden uzaktan kod çalıştırma
Resmi bildirimlerPHP Security Team duyurusu
GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
ÖnemCVSS v4.0 9.2, Kritik (PHP Security Team)
Kimlik doğrulamaGerekmez
Yamalı sürümlerPHP 8.2.35, 8.3.36, 8.4.27, 8.5.12
Eski dallarPHP Security Team, PHP 7.4, 8.0 ve 8.1 için kaynak kod yamaları yayımladı. Linux dağıtımları kendi yamalı paketlerini sunuyor.
İstismar durumuİstismar girişimleri bildiriliyor. Başarılı bir ele geçirme 22 Ekim 2026 itibarıyla kamuya açık olarak doğrulanmadı.
CISA KEV21 Ekim 2026 kataloğunda yer almıyor

Ne Oldu

  • 20 Ekim 2026 Açıkların ayrıntıları koordineli yayından önce kamuya açıldı.
  • 21 Ekim 2026 PHP projesi yamalı sürümleri ve GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp güvenlik bildirimlerini yayımladı.
  • 21-22 Ekim 2026 İstismar girişimleri bildirildi; kamuya açık kavram kanıtı (PoC) kodları ortaya çıktı.

Saldırı Nasıl İşliyor

İki açık da uygulama kodunda değil, PHP'nin kendisindedir. Saldırı, PHP gelen isteği okurken, uygulamanızın tek satırı çalışmadan önce gerçekleşir. WordPress'i, bir eklentiyi ya da kendi kodunuzu güncellemek açığı kapatmaz.

  • CVE-2026-109618, PHP'nin belleğinin tükendiği anı kötüye kullanır. Saldırgan, PHP'nin form verisi ve dosya yüklemelerini ayrıştırırken çok bellek kullanmasına yol açan istekler gönderir ve PHP'nin güvensiz bir durumda durmasını sağlar.
  • CVE-2026-109619, bir istekten sonra PHP worker'ında bayat veri bırakır; aynı worker'a gelen ikinci istek bu veriyi kullanır. Belgelenen yollardan biri PHP'nin varsayılan olarak açık olan session upload progress özelliğidir ve PHP_SESSION_UPLOAD_PROGRESS adlı bir form alanıyla tetiklenir.

Bu saldırıları taşıyan istekler çoğunlukla multipart/form-data (dosya yükleme) istekleri, büyük istek gövdeleri ve tekrarlanan isteklerdir. Bu yüzden bir web uygulaması güvenlik duvarı (WAF) bunların önemli bir kısmını görebilir ve sınırlayabilir. PHP'nin belleğinin içinde olanı ise göremez.

TR7 Etkileniyor mu?

Bu açıklar PHP'nin kendi istek işleme katmanında bulunuyor ve PHP çalıştıran uygulama sunucularını etkiliyor. TR7 cihazında HTTP isteklerini işleyen bir PHP bileşeni bulunmadığından TR7 ürünleri bu açıklardan etkilenmiyor.

Şimdi Ne Yapmalısınız

Yapılacaklar iki yerdedir: PHP çalıştıran kendi web uygulama sunucularınız ve TR7 WAF-WAAP. Her bölümün adımları kendi içinde numaralanır.

Kendi sunucularınızda

Adım 1: Web uygulama sunucularınızda PHP'yi güncelleyin (tek tam çözüm)

  1. Web uygulamanızın çalıştığı sunuculardaki PHP'yi 8.2.35, 8.3.36, 8.4.27 ya da 8.5.12 sürümüne yükseltin veya Linux dağıtımınızın yamalı paketini kurun. Dağıtım paketleri çoğu zaman eski sürüm numarasını korur; paketin değişiklik kaydında CVE numaralarını arayın.
  2. Tüm PHP worker'larını yeniden başlatın (PHP-FPM havuzları, Apache, LiteSpeed, uzun çalışan worker'lar). Çalışan süreçler yeniden başlayana kadar eski kodu kullanır.
  3. Kendi PHP'sini içeren konteyner imajlarını yeniden derleyin. Sunucuyu güncellemek imajın içindeki PHP'yi güncellemez.
  4. PHP 8.1 ve öncesi PHP projesinden güncelleme almıyor. Desteklenen bir dala geçişi planlayın.

Adım 2: Web uygulama sunucularınızda geçici PHP ayarları (bugün güncelleyemiyorsanız)

Bu ayarlar web uygulamanızın çalıştığı sunucunun PHP yapılandırmasında (php.ini ya da PHP-FPM havuz ayarları) yapılır. Bu önlemler PHP Security Team tarafından listelenmiştir. Belirli saldırı yollarını daraltır, ancak kurulumu güvenli hâle getirmez.

AyarAmacı
session.upload_progress.enabled = 0CVE-2026-109619'un session upload progress yolunu kapatır. Tüm worker'ları yeniden başlatın. PHP Security Team, bu özelliğe ihtiyaç yoksa yamadan sonra da kapalı tutulmasını önerir.
fatal_error_backtraces = 0 (PHP 8.5)Fatal error backtrace yolunu kapatır.
post_max_size = 8M (yükleme yoksa) ya da 32M (yükleme varsa), upload_max_filesize bunun altındaSaldırganın PHP'ye kullandırabileceği belleği azaltır.
memory_limit = -1, php_admin_value ileDenetlenebilir bellek sınırı hatasını ortadan kaldırır. Bu durumda tek bir istek tüm sunucu belleğini kullanabilir; konteyner ya da cgroup sınırı kullanın, RLIMIT_AS ya da RLIMIT_DATA asla kullanmayın.

TR7 WAF-WAAP'ta

PHP'yi hemen güncelleyebiliyorsanız asıl çözüm budur. Güncelleme hemen mümkün değilse, tamamlanana kadar herhangi bir TR7 güncellemesi almadan, TR7 WAF-WAAP'ın hâlihazırda sunduğu güvenlik ayarlarıyla PHP uygulamalarınızı bu saldırılara karşı koruyabilirsiniz. Adım 1'deki üç ayar temel korumadır; Adım 2'deki ek önlemler saldırı yüzeyini daha da daraltır, uygulamanıza uyanları seçin. Ayarları her vService için ayrı yapın ve önce üretim dışı bir vService'te deneyin.

Adım 1: Temel koruma

1.1 WAF'ı Blocking mode'a alın

Yalnız izleyen bir WAF saldırıyı durdurmaz. WAF ilk açıldığında Learning mode'da başlar; Monitor mode yalnız kayıt tutar. Her PHP vService'i için WAF Mode ekranını açın ve Blocking mode'da olduğunu doğrulayın.

Dikkat: Geçmeden önce her alan için öğrenilmiş imza istisnalarını gözden geçirin. Bir alandaki istisnalar Max. owasp exclusions değerini aşarsa o alanda imza denetimi kapanır.

1.2 İki özel kural ekleyin

Signature & Rule Library ekranında (WAF → Signature & Rule Library → Add) aşağıdaki iki kuralı ayrı ayrı ekleyin. İkisini de önce Monitor durumunda başlatın, Event Logs'u inceledikten sonra Enabled yapın. Kurallar WAF ile korunan tüm vService'lere uygulanır.

Kural 1: Session upload progress alanı

  • Pattern (Regex): PHP_SESSION_UPLOAD_PROGRESS
  • Inspection Scopes: Form ve Raw
  • Score: Very High

CVE-2026-109619'un session upload progress yolunu tetikleyen form alanını yakalar. Bu özelliği meşru olarak kullanan uygulamalarda yalnız ilgili yükleme yollarını istisna olarak tanımlayın.

Kural 2: PHPSESSID form alanı

  • Pattern (Regex): ^PHPSESSID$
  • Inspection Scopes: Form
  • Score: Very High

Oturum kimliğini çerez yerine PHPSESSID adlı bir form alanında taşıyan istekleri yakalar; saldırı yollarının bir kısmı bu biçimi kullanır, meşru trafikte ise nadiren görülür. Uygulamanız farklı bir oturum adı kullanıyorsa (session.name) o adı yazın.

Kuralların çalışması için: Kurallar, isteğin eşleştiği sayfa tipinin Form ve RAW denetimleriyle taranır. Form denetimi olmayan bir sayfa tipinde form ve dosya yükleme gövdeleri taranmaz.

  • Any Paths kuralında ve kendi Form ya da RAW denetimi olan sayfa tiplerinde OWASP check açık olsun.
  • Her glob sayfa tipine Add common rule for Form ve Add common rule for Raw butonlarıyla kendi Form ve RAW denetimini ekleyin; devralınan ayarlara güvenmeyin.
1.3 Büyük ve denetlenemeyen gövdeleri engelleyin

WAF Rules ekranında RAW denetiminde iki ayar yapın:

  1. Raw Body Size değerini o path'in ihtiyaç duyduğu en büyük gövdeye ayarlayın (bayt cinsinden; ör. yükleme olmayan yollarda 8388608 = 8 MB, yükleme yollarında 33554432 = 32 MB). Varsayılan aralık 256 MB'a kadar gövdeye izin verir.
  2. Ayrıştırılamayan gövde anahtarını Allow unparsed body konumundan Block unparsed body konumuna getirin. Aksi hâlde denetim tamponuna sığmayan bir gövde hiçbir içerik denetimi yapılmadan Kurum Servisine iletilir.

Nerede? WAF bir isteği yalnız path'ine eşleşen sayfa tipinin ayarlarıyla denetler. Bu iki ayarı Any Paths kuralında, Check Fields sütununda Raw görünen her sayfa tipinde ve her glob sayfa tipinde yapın; RAW denetimi olmayan glob sayfa tipine önce Add common rule for Raw ile ekleyin.

Dikkat: Raw Body Size, Checks ekranında Structure Checks açıkken uygulanır. Meşru büyük yüklemeleri önce test edin. Uzunluğu bildirilmeyen gövdeler bu sınırla ölçülmez; yükleme dışındaki yollarda 2.1 ile engellenebilir.

Adım 2: Ek önlemler

Bu önlemler temel korumayı tamamlar; uygulamanızın yapısına uyanları seçin.

2.1 Gerekmeyen yerlerde dosya yüklemeyi engelleyin

Saldırı istekleri çoğunlukla multipart/form-data (dosya yükleme) biçimindedir. Uygulamanızda yalnız birkaç yol dosya kabul ediyorsa, diğer tüm yollara gelen multipart istekleri bir yük dengeleyici kuralıyla engelleyin. Kural iki koşul ve bir Block aksiyonundan oluşur. Tüm ekranlara sol alttaki TR7 logosuyla açılan Configuration Menu üzerinden ulaşılır.

A. Koşulları oluşturun (Load Balancer → Conditions → Add)

  1. Multipart istek koşulu: Criteria = HTTP header, eşleştirme yöntemi Includes, Header Name = Request → Content-Type, Query = multipart/form-data, Case Insensitive açık. Condition Name olarak ör. multipart-istek girin ve Add ile kaydedin.
  2. Yükleme yolları koşulu: Criteria = Path, eşleştirme yöntemi Regex, Query alanına dosya kabul eden yollarınızı girin (ör. ^/(upload|media/upload)). Condition Name olarak ör. yukleme-yollari girin ve Add ile kaydedin.

B. Block aksiyonunu oluşturun (Load Balancer → Actions → Add)

  1. Action Name girin (ör. multipart-engelle), Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 403.
  2. Conditions alanında multipart-istek ve !yukleme-yollari koşullarını aynı koşul grubunda (varsayılan and) seçin. Her koşul listede kendisi ve ! ile başlayan değili (NOT) olarak iki biçimde görünür; !yukleme-yollari, "yükleme yollarından biri değilse" anlamına gelir.
  3. Engellenen istekleri saymak için Hit Counter'ı açın ve Add ile kaydedin.

C. Aksiyonu vService'e ekleyin

  1. Load Balancer → Load Balancer vService List ekranında vService'i seçip Edit'e tıklayın, Details altındaki Actions alanında aksiyonu seçin ve Save ile kaydedin.

D. Uzunluğu bildirilmeyen gövdeleri de engelleyin

  1. Yeni bir HTTP header koşulu oluşturun: eşleştirme yöntemi Is present, Header Name = Request → Content-Length, Condition Name ör. uzunluk-var.
  2. İkinci bir Block aksiyonu oluşturun (On Request, Standard, 403). Conditions alanında hazır If HTTP method is POST koşulunu, !uzunluk-var ve !yukleme-yollari koşullarını aynı koşul grubunda seçin ve aksiyonu vService'in Actions alanına ekleyin. POST koşulu şarttır; eklenmezse gövdesiz GET istekleri de engellenir.

1.3'teki boyut sınırı, uzunluğu bildirilmeden gönderilen gövdenin gerçek boyutunu görmez. Bu kural, yükleme yolu dışındaki adreslerde hem HTTP/1.1 akış hâlinde (chunked) gönderimi hem de uzunluk bildirmeyen HTTP/2 gövdelerini kapsar. Gövdesiz ve Content-Length başlığı göndermeyen POST istekleri de bu kurala takılır; kuralı önce üretim dışı bir vService'te deneyin.

Doğrulama: Yükleme yolu dışındaki bir adrese multipart istek (curl -s -o /dev/null -w '%{http_code}\n' -F 'a=b' https://www.example.com/), HTTP/1.1 chunked istek (curl -s -o /dev/null -w '%{http_code}\n' --http1.1 -H 'Transfer-Encoding: chunked' -d 'a=b' https://www.example.com/) ve uzunluk bildirmeyen HTTP/2 isteği (printf 'a=b' | curl -s -o /dev/null -w '%{http_code}\n' --http2 -X POST -T - https://www.example.com/) 403 almalı, yükleme yollarınızdaki istekler geçmelidir. HTTP/1.1 testinde --http1.1 şarttır: curl https'te varsayılan olarak HTTP/2 kullanır ve HTTP/2'de Transfer-Encoding başlığını göndermez. Sayaç, vService panosundaki Action Hits sekmesinde görünür.

Dikkat: Koşul hiç seçilmeyen bir Block aksiyonu vService'e gelen tüm isteklere uygulanır. Yükleme yolları listesini eksiksiz çıkarın ve kuralı önce üretim dışı bir vService'te deneyin.

2.2 İstemci başına POST isteklerini sınırlayın

Bu kural hedefli bir saldırıyı durdurmaz: istismar az sayıda istekle çalışabilir. Ancak çok sayıda hedefi deneyen otomatik araçların deneme maliyetini artırır. Kural, her istemci IP'sinin POST isteklerini sayar ve eşiği aşan istemcinin POST isteklerini 429 ile engeller. Sayaç eşiğin altına inince engel kendiliğinden kalkar.

A. Sayaç aksiyonunu oluşturun (Load Balancer → Actions → Add)

  1. Action Name girin, Action Type = Advanced Traffic Inspection, Fields to Track = Client IP address, Traffic Tag = ör. post-hiz (3-20 karakter; harf, rakam, -, _), Tracking Period = 1 dakika.
  2. Conditions alanında hazır If HTTP method is POST koşulunu seçin ve Add ile kaydedin. Böylece yalnız POST istekleri sayılır.

B. Eşik koşulunu oluşturun (Load Balancer → Conditions → Add)

  1. Criteria = Tracking Condition, Tracked Table = post-hiz, Tracking Criteria = HTTP requests, Tracking Operator ile eşik (ör. > 100). Add ile kaydedin.

C. Block aksiyonunu oluşturun (Load Balancer → Actions → Add)

  1. Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 429.
  2. Conditions alanında 3. adımdaki eşik koşulunu ve If HTTP method is POST koşulunu aynı koşul grubunda (varsayılan and) seçin. POST koşulu eklenmezse eşiği aşan istemcinin GET istekleri de engellenir. Add ile kaydedin.

D. Aksiyonları vService'e ekleyin

  1. vService'in Edit formunda Details → Actions alanında önce sayaç aksiyonunu, sonra Block aksiyonunu seçin ve Save ile kaydedin. Aksiyonlar listedeki sırayla işlenir.

Doğrulama: VService'in Logs & Tracking sekmesinde Logs Type listesinden sayaç aksiyonunun takip tablosunu seçin; istemci başına POST sayaçları görünür. Eşiği uygulamanızın normal trafiğine göre belirleyin: meşru istemcilerin (ör. API kullanan sistemler, ortak çıkış IP'si kullanan kurumlar) dakikadaki POST sayısını tablodan gözlemleyip eşiği bunun üstüne koyun.

2.3 L7 DDoS korumasını Active yapın

Bot/DDoS koruması lisansınızda varsa, L7 DDoS Protection altındaki Source IP Request Protection tek bir kaynak adresin belirli bir süredeki toplam istek sayısını sınırlar. 2.2'den farklı olarak tüm istekleri sayar ve ek kural gerektirmez.

  1. vService'in Edit formunda Details altındaki L7 DDoS & Threat Protection kutusunu işaretleyip Save ile kaydedin (açık değilse). Koruma açıldığında L7 DDoS Protection Monitor modunda başlar; bu modda sınır aşımı yalnız olay olarak kaydedilir.
  2. Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management sekmesinde L7 DDoS Protection kartının Edit bağlantısına tıklayın.
  3. DDoS Protection = Active seçip Edit butonuyla kaydedin.
  4. Kartta Source IP Request Protection bloğunun kalem ikonuna tıklayın. Time Window (varsayılan 10 seconds), Request Limit (varsayılan 1000) ve Limit Action (varsayılan Show Captcha; Block de seçilebilir) değerlerini uygulamanızın trafiğine göre ayarlayıp Edit butonuyla kaydedin.

Dikkat: Active'e geçmeden önce Monitor modunda bir süre olayları izleyin. Request Limit'i düşürdüğünüzde aynı gözlemi tekrarlayın.

Hedef alınıp alınmadığınızı kontrol edin

Tespit ve İzleme bölümüne bakın. İstismar girişimlerinin kamuya açıklanmadan önce başladığı bildirildiği için kayıtları 17 Ekim 2026'dan itibaren inceleyin.

WAF Neyi Yapabilir, Neyi Yapamaz

WAF şunları yapabilirWAF şunları yapamaz
Session upload progress alanı gibi bilinen istek biçimlerini engellemekPHP'nin içindeki açıklı kodu düzeltmek
Gövde boyutunu, yükleme yollarını ve istek hızını sınırlamakPHP sürecinin içindeki bellek kullanımını ölçmek
Gerekmeyen yollarda dosya yüklemeyi engellemekKendisinden geçmeden sunucunuza ulaşan istekleri görmek
Engellenen ve sınıra takılan istekleri kayda almakSunucuda çalışmış kodu geri almak

WAF kuralları güncelleme için zaman kazandırır; kalıcı çözüm PHP'yi güncellemektir. Bu korumaların etkili olması için PHP uygulamalarınıza gelen tüm trafiğin TR7 WAF-WAAP üzerinden geçmesi gerekir.

Tespit ve İzleme

TR7'de

  • WAF ile korunan her vService'in Event Logs ekranında kayıtları özel kurallarınıza göre süzün; eşleşen alana ve puana bakın.
  • Aynı ekranda gövde boyutu ve ayrıştırılamayan gövde kurallarıyla engellenen istekleri inceleyin.
  • Ek önlemleri uyguladıysanız yük dengeleyici kurallarının sayaçlarını vService panosundaki Action Hits sekmesinde, POST hız sınırına takılan istemcileri Logs & Tracking sekmesindeki takip tablosunda izleyin.

Sunucularınızda

  • PHP hata kayıtlarında Allowed memory size ... exhausted gibi hataları, worker çökmelerini ve tekrarlanan HTTP 500 yanıtlarını arayın; özellikle büyük multipart/form-data isteklerinin hemen ardından gelenlere dikkat edin.
  • Yanıtlarda olağandışı büyük ya da bozuk PHPSESSID çerezleri olup olmadığına bakın.
  • Web kök dizinlerinde yeni ya da değişmiş dosyaları, web sunucusu kullanıcısının başlattığı beklenmedik süreçleri, yeni cron görevlerini ve beklenmedik dış bağlantıları kontrol edin.

Sık Sorulan Sorular

Hayır. TR7 cihazında HTTP isteklerini işleyen bir PHP bileşeni bulunmadığından TR7 ürünleri bu açıklardan etkilenmiyor. Bkz. TR7 Etkileniyor mu?

Hiçbir WAF bu açıklara karşı tam koruma sağlayamaz. TR7 WAF-WAAP saldırı yüzeyini daraltır ve bilinen saldırı yollarını engeller; tek tam çözüm PHP'yi güncellemektir.

PHP2Shell'e karşı TR7 WAF-WAAP 1.2'deki iki özel kuralı kullanın; kurallar WAF ile korunan tüm vService'lere hemen uygulanır.

Hayır. Açıklar PHP çalışma ortamındadır. PHP'nin kendisini güncelleyin ya da barındırma sağlayıcınızdan güncellemesini isteyin.

Bozabilir. Gövde boyutu sınırları, yükleme engeli ve özel kurallar meşru yüklemeleri ve formları etkileyebilir. WAF kurallarında Monitor mode'da başlayın, Event Logs'u inceleyin, sonra Blocking mode'a geçin. Yük dengeleyici kurallarını (2.1, 2.2) önce üretim dışı bir vService'te deneyin.

Güncelleme Geçmişi

  • 23.10.2026 İlk yayın.

Kaynaklar

Bu ayarları uygulamak için yardım mı gerekiyor?

TR7 Destek Ekibi, WAF yapılandırmanızı inceleyip bu korumaları devreye almanıza yardımcı olabilir. TR7 temsilcinize ya da support@tr7.com adresinden TR7 Destek Ekibi'ne başvurun.

TR7 WAF-WAAP'ı inceleyin İletişim Acil Destek