21 Ekim Güvenlik Özeti: PHP2Shell'in Hikâyesi, Java, HTTP/3, Node, Railway ve OVH

21 Ekim 2026 güvenlik ekipleri için uzun bir gündü. PHP iki kritik açığı yamaladı, Oracle Java için plan dışı bir uyarı yayınladı, Node.js on açığı kapattı, Railway müşteri secret’larına erişildiğini duyurdu. Bir gün önce de OVHcloud’un komut satırı aracı zararlı sürümlerle dağıtılmıştı.

Bu yazı o günün özeti. Her başlıkta önce ne olduğunu, sonra senin ne yapman gerektiğini yazdım. PHP açıklarının teknik ayrıntısı ayrı yazıda: PHP’de İki Kritik RCE: CVE-2026-109618 ve CVE-2026-109619. Videosu: Pixel Shorts · Dünden bugüne.

Kısaca

PHP2Shell: 2024’ten bugüne

2024: ilk iz

PHP Vakfı’nın açıklamasına göre sorunun ilk izleri 2024’te görüldü. Vakfın sözleşmeli çalıştırdığı bir PHP core developer, Quarkslab’ın 2024 denetiminde bulduğu başka bir açığı düzeltirken out-of-memory (OOM) davranışındaki sorunu fark etti. O zaman somut bir saldırı yolu bulunamadı ve etkisi net olan başka açıklar öne alındı.

Sonraki aylarda güvenlik ekibi birkaç farklı düzeltme hazırladı. The Next Web’in aktardığına göre biri geriye dönük uyumluluğu bozuyordu, biri yeni bir DoS riski getiriyordu, biri de binlerce eklentide değişiklik gerektiriyordu. Uzlaşmayla karar veren küçük ekip seçim yapamadı. Vakıf bunu açıkça “structural failure” olarak tanımladı ve karar sürecini çoğunluk oyuna çevirdiğini duyurdu.

Ağustos 2026: yapay zekâyla yeniden bulundu

Bu yaz iki ekip açığı birbirinden bağımsız olarak, çalışan bir saldırı yoluyla buldu:

• Calif: Wall Street Journal’ın haberine göre bir Calif araştırmacısı açığı OpenAI’ın “Patch the Planet” programı kapsamında GPT-5.6 Sol ile buldu.
• Wiz Research: Wiz’in yazısına göre ilk bulgu 19 Ağustos’ta geldi, 20–21 Ağustos’ta Drupal ve WordPress üzerinde kimlik doğrulamasız RCE doğrulandı, 24 Ağustos’ta PHP’ye bildirildi. Wiz, Wiz Atlas, Gemini 4 Argon ve GPT-5.6 Sol kullandığını yazıyor.

PHP raporları 21 Eylül’de kabul edip koordineli düzeltmeye başladı.

17–21 Ekim: sızıntı ve yama

Sosyal medyada açığı kimin sızdırdığına dair isimler dolaşıyor. Bunları hiçbir birincil kaynakta bulamadım, o yüzden burada yok.

PHP yaması nasıl doğru kurulur

1. Sitenin gerçekten kullandığı PHP’ye bak

Sunucuda birden fazla PHP sürümü varsa terminaldeki php -v sadece varsayılan CLI’ı gösterir. Siteyi çalıştıran PHP-FPM ya da Apache modülü başka bir sürüm olabilir.

php -v                 # terminaldeki (CLI) PHP
php-fpm8.4 -v          # sitenin kullandığı FPM (sürüm numarasını kendi kurulumuna göre değiştir)
ls /etc/php/           # kurulu bütün sürümler (Debian/Ubuntu)

Emin değilsen sitede geçici bir phpinfo() sayfası açıp “Server API” ve sürüm satırına bak, sonra sayfayı sil.

2. Paketi güncelle

Debian ve Ubuntu (dağıtım paketleri): Dağıtımlar güvenlik düzeltmesini genelde eski sürüm numarasına backport eder. Numara değişmediyse paniğe gerek yok; changelog’da CVE numarasını ara.

sudo apt update
sudo apt install --only-upgrade 'php8.4*'
apt changelog php8.4-fpm | grep -E '109618|109619'

Ondřej Surý’nin deposu (deb.sury.org): Bu depo PHP’nin resmi sürüm numaralarını takip eder. Ayrıca 7.4, 8.0 ve 8.1 için 21 Ekim tarihli yeni paketler var. Bunların changelog’unu kendim açıp kontrol ettim; içindeki yama PHP geliştiricilerinin hazırladığı ve “Minimal mitigation for EOL version” notunu taşıyan asgari bir önlem. Yani 8.1 ve öncesi için tam bir çözüm değil, zaman kazandırır. Kalıcı çözüm 8.2 ve üstüne geçmek.

AlmaLinux: Yamalı paketler AlmaLinux 8, 9 ve 10 depolarında.

sudo dnf update 'php*'

Docker: İmajı yeni sürüm etiketiyle yeniden derle (ör. FROM php:8.4.27-fpm) ve konteynerleri yeniden başlat. Sadece docker pull yetmez; eski imajla çalışan konteyner eski kodu çalıştırmaya devam eder.

Paylaşımlı hosting ve paneller: Güncellemeyi sağlayıcı yapar. Hangi sürümde olduğunu yazılı olarak sor.

3. Yeniden başlat

PHP-FPM worker’ları ve Apache süreçleri belleğe yüklenmiş eski kodu çalıştırır. Paket güncellense de süreç yeniden başlamadan yama devreye girmez.

sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2      # mod_php kullanıyorsan

4. Geçici ayarlar

php.net’in önerdiği geçici ayarlar (session.upload_progress.enabled = 0, memory_limit = -1, düşük post_max_size, PHP 8.5’te fatal_error_backtraces = 0) sunucuyu güvenli yapmıyor, sadece bazı yolları kapatıyor. Ayrıntısı önceki yazıda. Upload progress özelliğini kullanmıyorsan yamadan sonra da kapalı tutmanın bir zararı yok; ben kendi sunucumda kapalı bıraktım.

Kendi sunucumda

21 Ekim akşamı CloudPanel deposuna düşen sürümleri kurdum: 8.5.12 (17:29) ve 8.4.27 (18:56). 22 Ekim’deki kontrol:

$ php-fpm8.5 -v
PHP 8.5.12 (fpm-fcgi) (built: Oct 21 2026 07:08:08) (NTS)
$ php-fpm8.4 -v
PHP 8.4.27 (fpm-fcgi) (built: Oct 21 2026 07:08:08) (NTS)

Java: CVE-2026-91403

OpenJDK’nın 21 Ekim bildirimine göre sekiz ara CA sertifikası ele geçirildi. Bileşen security-libs/javax.net.ssl (JSSE), puan CVSS 3.1 ile 9.1. JDK 8, 11, 17, 21, 25 ve 27 etkileniyor; OpenJFX etkilenmiyor. Oracle bunu düzenli Ekim CPU’sunun dışında, ayrı bir Security Alert olarak yayınladı.

• Ayrı kurulu (standalone) JDK/JRE: En son güncellemeye geç.
• Güncelleyemiyorsan: İndirilen yeni $JDK_HOME/lib/security/blocked.certs dosyasını yerleştir (JDK 8’de blacklisted.certs; eklediğin satırlar varsa yedekle) ya da revocation kontrolünü aç:

-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true

• İşletim sisteminin OpenJDK’sı: Debian, Ubuntu, Fedora, Red Hat ve Arch’ta sistem sertifikalarını güncellemek genelde yeterli. FreeBSD ve Homebrew paketlerini doğrudan güncelle.

Sunucunda kaç JDK olduğunu bilmiyorsan önce say: CI ajanları, IDE’ler ve uygulamaların içine gömülü runtime’lar ayrı ayrı güncellenir.

HTTP/3: QPACK bellek amplifikasyonu

FoxIO, HTTP/3’ün başlık sıkıştırması QPACK’te bir bellek amplifikasyonu sınıfı yayınladı (The Hacker News özeti). Etkilenen yığınlar sıkıştırılmış girdiyi sınırlıyor ama açılmış başlık listesini sınırlamıyor ya da sınırı geç uyguluyor. Test edilen on HTTP/3 yığınından yedisi etkileniyor. Kimlik doğrulama gerekmiyor, saldırgan küçük bir istekle sunucuya çok daha fazla bellek ayırtabiliyor.

Yamasız yığınlar için geçici önlem: Bun’da HTTP/3 sunucusunu dışarı açma, mitmproxy’de --set http3=false, h3’te max_field_section_size ile bir sınır koy. Yayın anında doğada kötüye kullanım raporu yoktu.

Node.js: 21 Ekim güvenlik sürümleri

Node.js 21 Ekim’de 22.x, 24.x ve 26.x hatlarında 10 CVE kapattı: 4 yüksek, 3 orta, 3 düşük. Düzeltilmiş sürümler 22.23.4, 24.22.1 ve 26.12.1.

Yüksek önemdekiler:

• CVE-2026-111497: Brotli decoder’da out-of-bounds write, uzaktan kod çalıştırmaya (RCE) izin veriyor.
• CVE-2026-105483: IP adresi tam genişlikli (fullwidth) rakamlarla yazılınca TLS sertifika hostname kontrolü atlanıyor.
• CVE-2026-106069: Host gevşek biçimde bir IP adresine çözülünce yine TLS hostname kontrolü atlanıyor.
• CVE-2026-105482: dns.resolve NUL karakteri içeren adları kesiyor.

Orta önemdekiler arasında crypto.randomUUID() ve randomInt() entropi önbelleğinin snapshot ve SEA dosyalarına yazılması (CVE-2026-106074) var: aynı snapshot’tan başlayan süreçler aynı değerleri üretebiliyor. Node.js 20 ve 25 destek dışı, yama almadı; bu sürümleri kullanan uygulamaların ana sürüm yükseltmesi gerekiyor.

node -v

Railway: environment variable’lara erişim

Railway 21 Ekim’de müşteri environment variable’larını saklayan sistemlerde olağan dışı etkinlik tespit etti. GitGuardian’ın özetine göre yetkisiz bir taraf şifrelenmiş değerlere, bir kısmında da çözülmüş değerlere erişmiş olabilir. Railway olayı, AI inference sağlayıcılarını hedefleyen ve platform şirketlerine yönelen bir saldırı dizisiyle ilişkilendiriyor.

Durum sayfasına göre build’ler bütün platformda durduruldu, OAuth oturumları geçersiz kılındı, bucket credential’ları yenilendi ve 22 Ekim 04:17 UTC’de bütün Railway API token’ları iptal edildi. 22 Ekim sabahı Pro ve Enterprise build’leri yavaş da olsa çalışıyordu, Hobby build’leri henüz açılmamıştı.

Railway kullanıyorsan:

1. Önce bağlı servislerdeki (AWS, GCP, GitHub, AI sağlayıcıları) key’leri yenile, sonra Railway’deki değerleri güncelle.
2. Sealed variable’ları da değiştir; olayın onları kapsayıp kapsamadığı açıklanmadı.
3. Private registry credential’larını değiştir.
4. Bu credential’ları kullanan servislerin kayıtlarında olağan dışı erişim ara. Railway AWS, GCP ve GitHub için rehber yayınladı.
5. Yeni bir Railway API token’ı oluştur; eskileri çalışmıyor.

Railway’den kripto varlıkların da çalındığına dair iddialar sosyal medyada dolaşıyor; birincil kaynakla doğrulayamadım.

OVHcloud CLI: tedarik zinciri saldırısı

BleepingComputer’ın haberine göre saldırganlar bir geliştiricinin GitHub hesabını ele geçirip OVHcloud CLI’ın mevcut release dosyalarını değiştirdi. 0.11.0’dan 0.15.0’a kadar olan sürümler 19 Ekim’de yaklaşık 14:47–16:21 arasında (kaynaklara göre saat dilimi farklı veriliyor, süre yaklaşık 94 dakika) zararlı dosyalarla dağıtıldı.

• Zararlı yazılım diskteki secret’ları toplayan bir infostealer. İçinde gizli bir preinstall.js yükleyici ve ikinci aşamayı Solana memo üzerinden alan bir dead drop var. OpenSourceMalware saldırıyı GlassWorm adlı bir operasyonla ilişkilendiriyor.
• Etkilenen platformlar macOS (Intel, ARM), Linux (x86_64, ARM64) ve Windows x86-64. Kaynaktan derlenen sürümler ve Docker imajları etkilenmedi.
• Release’ler GitHub’ın release immutability ayarı kapalı olduğu için CI/CD’ye uğramadan değiştirilebildi. OVHcloud ayarı açtı.
• 0.10.0 ve 0.16.0 temiz.

Bu bir müşteri verisi sızıntısı değil; OVHcloud altyapısına ya da müşteri veritabanlarına erişildiğine dair bir rapor yok. Ama 19 Ekim’de bu aralıkta CLI’ı kurduysan ya da güncellediysen OVHcloud CEO’su Octave Klaba’nın tavsiyesi net: o makinedeki bütün secret’ları değiştir.

Bugünün kontrol listesi

• PHP: sitenin PHP-FPM sürümü 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35 mi? Değilse güncelle, sonra PHP-FPM’i ve Apache’yi yeniden başlat.
• PHP 8.1 ve öncesi: asgari yamayı kur, 8.2 ve üstüne geçişi planla.
• Java: her JDK/JRE kurulumunu güncelle ya da blocked.certs’i yenile.
• HTTP/3: quic-go, quiche, lsquic sürümlerine bak; Bun’da HTTP/3’ü kapat.
• Node.js: 22.23.4, 24.22.1 ya da 26.12.1.
• Railway: bütün environment variable’ları, registry credential’larını ve API token’ları yenile.
• OVHcloud CLI: 19 Ekim’de 0.11–0.15 kurduysan secret’ları değiştir, 0.16.0’a geç.

Kaynaklar

• php.net · 21 Ekim güvenlik sürümleri
• PHP Foundation · Today’s PHP Security Release, and How We’re Strengthening PHP Security
• The Next Web · PHP knew about one of the flaws in 2024 but could not agree a fix
• Wiz Research · PHP2Shell
• AWS Security Blog · PHP2Shell exploitation prior to public disclosure in MadPot
• watchTowr · PHP2Shell FAQ
• The Hacker News · PHP Issues Emergency Patches
• AlmaLinux · Patched PHP packages
• packages.sury.org · php7.4 7.4.33-31, php8.0 8.0.30-25, php8.1 8.1.34-9 (21 Ekim derlemeleri, debian/changelog)
• OpenJDK Vulnerability Advisory 2026/10/21
• The Hacker News · New QPACK Flaws Can Crash HTTP/3 Servers
• Node.js · October 2026 Security Releases
• Railway status · QH8L8B3E
• GitGuardian · New Railway Incident
• BleepingComputer · OVHcloud CLI releases backdoored on GitHub
• TechCrunch · The internet is having a very bad cybersecurity day