Selam arkadaşlar,
Bu sabah X tarafında epey konuşulan bir konu var: PHP çekirdeğinde iki kritik uzaktan kod çalıştırma (RCE) açığı. PHP güvenlik ekibi acil bir güvenlik sürümü çıkaracağını doğruladı; resmi takvim 21 Ekim 2026, 14:00 UTC (Türkiye saatiyle 17:00). Araştırmacılar hem lab hem saha ortamında yeniden üretebildiklerini söylüyor. Panik yok ama boş da durmayalım: ne olduğunu, kök nedeni ve sunucuları nasıl koruyacağımızı toparlamak istedim.
Bu yazı beyaz şapka / savunma odaklıdır. Çalışır exploit veya PoC kodu yok; yama henüz herkese yayılmamışken canlı bir 0-day'i silahlandırmanın anlamı yok. Amacımız mekanizmayı anlamak ve sistemi kapatmak.
Konuda Anlatılacaklar
- CVE özeti ve resmi durum
- session.upload_progress nedir, neden var
- php_session_rfc1867_callback ve kök neden (UAF)
- Bellek düzeni mantığı (kavramsal)
- Saldırı yüzeyinden RCE'ye giden kavramsal akış
- Kimler etkilenir, hangi sürümler
- Ne yapmalıyız: yama, geçici azaltma, WAF, izleme
- Takip ve kaynaklar
1) CVE özeti
- CVE-2026-109618 ve CVE-2026-109619
- Tür: Heap use-after-free (UAF) — iki ayrı primitif
- Bileşen: PHP session uzantısı, dosya yükleme ilerleme (upload progress) işleyicisi
- Fonksiyon / dosya:·Kod:
php_session_rfc1867_callbackKod:ext/session/session.c - Etki: Uzaktan kod çalıştırma (RCE); raporlanan CVSS bandı kritik (yaklaşık 9.2 / bazı kaynaklarda 10)
- Durum: PHP projesi acil güvenlik sürümünü doğruladı; teknik detayların resmi duyuruyla netleşmesi bekleniyor. Araştırmacılar UAF zincirini lab ve saha ortamında yeniden ürettiklerini belirtti.
Kısaca: multipart dosya yükleme sırasında session'a yazılan "yükleme ilerlemesi" yolunda, heap üzerinde serbest bırakılmış bir bellek bloğuna yeniden erişiliyor. Bu sınıf hatalar doğru koşullarda denetimsiz bellek yazmaya ve oradan da kod çalıştırmaya evrilebiliyor.
2) session.upload_progress ne işe yarar
Büyük bir dosya yüklerken arayüzde yüzde kaçının gittiğini göstermek sık ihtiyaçtır. PHP, bunun için isteğe bağlı bir özellik sunar: session.upload_progress.
Mantık kabaca şöyle:
- İstemci multipart/form-data ile dosya gönderir (RFC 1867 tarzı yükleme).
- PHP, yükleme sürerken ilerlemeyi (kaç byte geldi, dosya adı, yüzde vb.) oturum (session) içinde bir anahtar altında tutar.
- Uygulama ayrı bir AJAX isteğiyle aynı session'dan bu bilgiyi okuyup progress bar çizer.
İlgili php.ini anahtarlarından sık görülenler:
Kod:
session.upload_progress.enabled = On
session.upload_progress.cleanup = On
session.upload_progress.prefix = "upload_progress_"
session.upload_progress.name = "PHP_SESSION_UPLOAD_PROGRESS"
session.upload_progress.freq = "1%"
session.upload_progress.min_freq = "1"Çoğu modern uygulama progress bar'ı kendi JavaScript'iyle veya harici depolamayla çözer; bu PHP özelliği her kurulumda zorunlu değildir. Ama varsayılan olarak açık kalabiliyor — ve işte saldırı yüzeyi tam buradan geliyor: dosya yükleme + session yazımı aynı istek yaşam döngüsünde birleşiyor.
3) Kök neden: php_session_rfc1867_callback ve use-after-free
PHP, multipart yükleme parçalarını işlerken session uzantısına bir geri çağrı (callback) bağlar. Bu callback'in adı kaynakta
Kod:
php_session_rfc1867_callbackKod:
ext/session/session.cUse-after-free'i sade bir dille şöyle düşünün:
- Program heap'ten bir nesne alır (ör. session içindeki bir dizi / zval yapısı).
- Belirli bir koşulda bu nesne serbest bırakılır (free) — bellek ayırıcıya "bu blok artık kullanılmıyor" denir.
- Ama kod yolunun başka bir kolunda hâlâ eski işaretçi (stale pointer) tutulur.
- Sonra o işaretçi üzerinden okuma veya yazma yapılır → use-after-free.
Saha raporlarına göre burada sorun, upload progress yolunda session verisine bağlanan yapıların yaşam süresinin yanlış yönetilmesi: bir referans "öldükten" sonra hâlâ tutuluyor; yükleme callback'i ilerlerken veya session yeniden yazılırken o stale referans tekrar kullanılıyor. İki CVE'nin iki ayrı primitif olarak ayrılması, aynı yüzeyde (aynı callback / aynı özellik) farklı serbest bırakma–yeniden kullanma yollarına işaret ediyor.
Önemli sınır: PHP henüz resmi teknik embargoyu tam kaldırmamış olabilir. Bu yüzden burada yeniden üretim adımı veya offset hesabı yok. Savunmacı için yeterli kök neden şudur: session.upload_progress işleyicisinde heap UAF → bellek bozulması → RCE potansiyeli.
4) Bellek düzeni mantığı (kavramsal)
PHP'nin dahili nesne modeli (zval, HashTable, string, array) heap üzerinde yaşar. Tipik bir UAF → RCE hikâyesi savunma açısından şöyle okunur:
- Free: Hassas bir yapı (ör. session'a yazılacak dizi / string buffer) serbest bırakılır.
- Realloc / spray: Aynı istek içinde veya yakından gelen başka tahsisler, boşalan bloğu yeniden doldurabilir. Saldırgan kontrollü veri (ör. yükleme alanları, session anahtarları, uzun string'ler) heap düzenini şekillendirmeye çalışır.
- Use: Stale işaretçi, artık saldırganın kontrol ettiği içeriği "meşru nesne" sanarak okur/yazar.
- Type confusion / keyfi yazma: Yanlış tipte yorumlanan bellek, işlev işaretçisi veya zend motorunun çağrı yapılarına kadar gidebilir.
- Kod çalıştırma: Zend VM tarafında güvenilir bir çağrı yoluna (ör. fonksiyon çağrı mekanizması) saplanırsa süreç bağlamında RCE oluşur.
Bu zincir build'e, allocator davranışına, ASLR/PIE'ye ve istek zamanlamasına bağlıdır; "her istekte %100" demek doğru olmaz. Ama kritik puanın sebebi tam da bu: başarılı olduğunda sonuç doğrudan sunucu tarafı kod çalıştırmadır, XSS veya bilgi sızıntısı değil.
5) Saldırı yüzeyi — kavramsal akış (exploit yok)
Yüksek seviye bakış (savunma senaryosu):
- Önkoşul: Hedefte PHP çalışıyor ve açık. Session kullanımı ve multipart dosya yükleme kabul eden bir uç nokta var (login formu, medya yükleme, ticket eki… çoğu web uygulamasında bulunur).Kod:
session.upload_progress.enabled - Tetik: Saldırgan, progress özelliğini devreye sokacak şekilde multipart istek gönderir; session tarafında upload progress kayıtları oluşur / güncellenir.
- UAF penceresi: Callback içinde serbest bırakılmış yapıya stale erişim; heap düzeni bozulur.
- Sonuç: Bellek bozulması, uygun koşullarda RCE. Araştırmacı raporlarında zincirin zend çağrı yollarına kadar götürüldüğü iddia ediliyor; resmi teyit yamayla gelecek.
Kimlik doğrulama gerekip gerekmediği sürüm ve yapılandırmaya göre tartışmalı raporlanıyor; pratikte internete açık PHP uygulamalarını yüksek öncelikli sayın. "Sadece admin paneli var" demek yetmez — herkese açık upload veya session açan herhangi bir form yüzey sayılır.
Bu yazıda kasıtlı olarak yok: çalışan PoC, payload, offset, heap spray betiği, php2shell benzeri araç kullanımı. Yama öncesi canlı 0-day'i çoğaltmak forumun da, yasal sınırın da dışındadır. Kendi sisteminizde bile test edecekseniz yama sonrası, izole lab ve yazılı izin şart.
6) Kimler etkilenir
- session.upload_progress etkin olan PHP kurulumları birincil risk grubu.
- Paylaşılan ve saha tartışmalarında etki yüzeyi eski PHP 5 hattından desteklenen 8.x sürümlerine kadar geniş anlatılıyor. Destek süresi bitmiş (EOL) 5.x / 7.x / 8.0 / 8.1 için resmi yama gelmeyebilir — bu makineler zaten ayrı bir acil durum.
- Beklenen sabit sürümler (duyuru öncesi sızıntı / hazırlık notlarına göre, resmi listede teyit edin): 8.5.x, 8.4.x, 8.3.x, 8.2.x acil güvenlik paketleri. Tam sürüm numaraları php.net duyurusuyla kesinleşecek.
- WordPress, Laravel, Drupal, Magento, özel paneller… dil PHP ise ve upload progress açıksa varsayılan olarak ilgili sayın.
- Paylaşımlı hosting'te tek bir zayıf vhost, komşu hesapları da riske sokabilir (süreci paylaşım modeline göre).
Kendi sunucunuzda hızlı kontrol:
Kod:
# Çalışan PHP sürümü
php -v
# Özellik açık mı?
php -i | grep -i upload_progress
# veya
php -r 'echo ini_get("session.upload_progress.enabled") ? "ON\n" : "OFF\n";'7) Nasıl korunulur — yapılacaklar listesi
A) Asıl çözüm: acil güvenlik yamasını hemen alın
- php.net / dağıtımınızın (Debian, Ubuntu, RHEL, Remi, Ondřej PPA, Docker resmi imajı…) güvenlik paketini izleyin.
- Yama çıkınca önce staging, sonra prod; PHP-FPM / Apache / Nginx worker'ları yeniden başlatın ki yeni binary yüklensin.
- EOL PHP kullanıyorsanız "bekleyip görelim" yok: desteklenen 8.2+ hatta taşıyın. Yamasız EOL = açık kapı.
B) Geçici azaltma (yama gelene kadar / yama sonrası bile savunma derinliği)
Progress bar özelliğini kullanmıyorsanız kapatın. Çoğu sitede tek etkisi upload yüzde çubuğunun PHP session üzerinden beslenmemesidir; dosya yüklemenin kendisi çalışmaya devam eder.
Kod:
; php.ini veya conf.d/ altına
session.upload_progress.enabled = OffSonra FPM/Apache'yi reload edin:
Kod:
# örnek
sudo systemctl reload php8.3-fpm
# veya
sudo systemctl reload apache2Doğrulama:
Kod:
php -i | grep session.upload_progress.enabledNot: Bu ayar şu anki kamu bilgisine dayanan geçici azaltmadır; PHP projesinin resmi "tek başına yeterli workaround" diye mühürlediği bir madde olmayabilir. Yamanın yerini tutmaz, ama saldırı yüzeyini daraltır.
C) Maruziyeti azaltma
- İnternete açık gereksiz upload uçlarını kapatın veya VPN / IP allowlist arkasına alın.
- WAF / reverse proxy'de anormal multipart + session cookie desenlerini, aşırı büyük veya tuhaf alan adlı yüklemeleri izleyin / rate-limit uygulayın.
- Paylaşımlı hosting'te hesap izolasyonunu (PHP-FPM pool per user, open_basedir, ayrı uid) gözden geçirin.
- Container imajlarını pin'leyin; "latest" ile kör güncelleme yerine bilinen güvenli tag'e geçin.
D) İzleme (SOC / blue team)
- Web sunucu ve PHP-FPM loglarında ani worker crash / segfault artışı (UAF denemeleri sık process düşürür).
- Alışılmadık multipart istekleri, özellikle progress name alanı ve ardışık session yazan yüklemeler.
- Yama öncesi/sonrası için EDR'de web kökünden çıkan şüpheli process spawn (php-fpm → sh/curl/wget zinciri).
- File integrity: web root ve session kaydetme dizininde beklenmeyen yeni .php dosyaları.
Örnek (kendi sunucunuz, yetkili izleme) — son bir saatte PHP-FPM segfault izi:
Kod:
journalctl -u php*-fpm --since "1 hour ago" | grep -iE 'segfault|killed|oom'8) Ne yapmayın
- Kamuya açık PoC / "php2shell" tarzı araçları prod'a veya müşteri sistemine denemeyin.
- Yama çıkmadan "acaba bizde işliyor mu" diye internete açık sunucuda yarış koşturmayın.
- Sadece WAF kuralına güvenip PHP'yi güncellemeden bırakmayın.
9) Takip listesi
Yama ve CVE metinleri netleştikçe şunları izleyin:
- PHP News Archive — Upcoming Critical PHP Security Release
- php.net güvenlik duyuruları ve ilgili 8.2 / 8.3 / 8.4 / 8.5 sürüm notları
- CVE kayıtları: CVE-2026-109618, CVE-2026-109619 (NVD / MITRE güncellemeleri)
- Dağıtım güvenlik listeleri (Debian Security, Ubuntu USN, Red Hat RHSA vb.)
- Kurumsal CERT duyuruları (ör. CERT-EU özetleri)
X / Twitter tarafındaki erken sızıntılar yön gösterici olabilir ama nihai kaynak php.net ve CVE kaydıdır. CVSS puanı, etkilenen sürüm listesi ve resmi workaround metni oradan teyit edilmeli.
Kısa sonuç
İki kritik UAF, PHP'nin
Kod:
session.upload_progressKod:
php_session_rfc1867_callbackKod:
ext/session/session.c- Envanter: hangi sunucuda hangi PHP var, progress açık mı?
- Mümkünse Kod:
session.upload_progress.enabled = Off - 14:00 UTC civarı (ve sonrasında) resmi paketi uygula, servisleri restart et
- EOL PHP varsa desteklenen sürüme taşı
- Crash / şüpheli upload / web root bütünlüğünü izle
Soruları veya kendi ortamınızda gördüğünüz (hassas olmayan) gözlemleri thread'e yazın; yama notları düştükçe bu konuyu güncelleriz.
Yasal uyarı: Anlatılanlar yalnızca kendi sistemleriniz veya yazılı izniniz olan ortamlar içindir. Başkasına ait sistemlerde deneme TCK 243–245 kapsamında suçtur. TurkTeam beyaz şapka ilkelerine bağlıdır.
Kaynakça / izlenen duyurular
- PHP Group — Upcoming Critical PHP Security Release (20 Ekim 2026 duyurusu; yayın 21 Ekim 2026 14:00 UTC)
- CVE-2026-109618, CVE-2026-109619 (kamu tartışması ve araştırmacı raporları; resmi teknik metin yamayla)
- CERT-EU ve sektör özetleri — kritik PHP RCE hazırlık tavsiyeleri
- Saha: session.upload_progress UAF primitifleri, php_session_rfc1867_callback / ext/session/session.c
