# 21 Ekim Güvenlik Özeti: PHP2Shell'in Hikâyesi, Java, HTTP/3, Node, Railway ve OVH > PHP2Shell'in 2024'teki ilk izinden yamaya kadar geçmişi, yamanın doğru kurulması (PHP-FPM, Debian changelog, EOL sürümler) ve aynı gün çıkan Java CVE-2026-91403, HTTP/3 QPACK açığı, Node.js güvenlik sürümleri, Railway environment variable olayı ve OVHcloud CLI tedarik zinciri saldırısı. URL: https://iamcanturk.dev/21-ekim-guvenlik-ozeti-php2shell-java-node-railway-ovh/ Yazar: Can Türk · 22 Ekim 2026 · #güvenlik #php #java #nodejs #cve --- 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](/php2shell-acil-php-guvenlik-yamasi/). Videosu: [Pixel Shorts · Dünden bugüne](/shorts/dunden-bugune/). ## Kısaca | Konu | Kimlik | Ne yapmalı | |---|---|---| | PHP2Shell | [CVE-2026-109618](https://www.cve.org/CVERecord?id=CVE-2026-109618), [CVE-2026-109619](https://www.cve.org/CVERecord?id=CVE-2026-109619) · CVSS v4.0 9.2 | 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35'e geç; PHP-FPM'i ve Apache'yi yeniden başlat | | Java (JSSE) | [CVE-2026-91403](https://openjdk.org/groups/vulnerability/advisories/2026-10-21) · CVSS 9.1 | JDK'yı güncelle ya da `blocked.certs` dosyasını yenile | | HTTP/3 QPACK | CVE-2025-64702 (quic-go), CVE-2026-12523 (quiche) | quic-go 0.57.0, quiche 0.29.3, lsquic 4.9.0; Bun'da HTTP/3'ü kapat | | Node.js | 10 CVE, en ağırı CVE-2026-111497 (Brotli, RCE) | 22.23.4, 24.22.1 ya da 26.12.1 | | Railway | [Olay kaydı QH8L8B3E](https://status.railway.com/incident/QH8L8B3E) | Railway'deki bütün environment variable'ları ve API token'ları değiştir | | OVHcloud CLI | 0.11.0 – 0.15.0 (19 Ekim) | O gün kurduysan diskteki bütün secret'ları değiştir, 0.16.0 kullan | ## PHP2Shell: 2024'ten bugüne ### 2024: ilk iz [PHP Vakfı'nın açıklamasına](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) 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](https://thenextweb.com/news/php-foundation-structural-failure-2024-flaw-leak) 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](https://www.wiz.io/blog/php2shell-php-rce) 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 | Tarih | Ne oldu | |---|---| | 17 Ekim | [Amazon Threat Intelligence](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/), MadPot honeypot ağında duyurudan dört gün önce bir PHP2Shell denemesi gördü. Saldırganın bilgiyi nereden aldığı belli değil. | | 20 Ekim | CVE numaraları yanlış yayın saati ve yanlış puanla (10.0) forumlarda ve sosyal medyada dolaşmaya başladı. PHP ön duyuruyu 19:30 UTC'ye çekti. | | 20 Ekim | Calif, çalışan PoC'nin videosunu yanlışlıkla yayınladı. Vakıf bunun "sınırlı ek ayrıntı" verdiğini yazıyor. | | 21 Ekim 07:41 UTC | Chainguard yamalı imajları planlanan saatten altı saatten fazla önce yayınladı. Vakıf bunu koordineli açıklamayı hiçe saymak olarak niteledi. | | 21 Ekim 14:00 UTC | 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 yayınlandı. | | 21 Ekim | [watchTowr](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/) honeypot ağında saldırı denemeleri gördü, Cloudflare müşterilerine yönelik saldırı trafiği için WAF kuralı yayınladı. Doğrulanmış başarılı bir saldırı raporu yok. | 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. ```bash 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. ```bash 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](https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/) depolarında. ```bash 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. ```bash 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](/php2shell-acil-php-guvenlik-yamasi/). 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: ```text $ 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](https://openjdk.org/groups/vulnerability/advisories/2026-10-21) 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ç: ```bash -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](https://thehackernews.com/2026/10/new-qpack-flaws-can-crash-http3-servers.html)). 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. | Yığın | Durum | |---|---| | quic-go (Caddy, Traefik, cloudflared) | 0.57.0'da düzeldi · CVE-2025-64702 | | Cloudflare quiche | 0.29.3'te düzeldi · CVE-2026-12523 | | lsquic (LiteSpeed, OpenLiteSpeed) | 4.9.0'da düzeldi | | Wireshark (dissector) | 4.6.2 / 4.4.12 · CVE-2025-13945 | | Bun, h3 (hyperium), aioquic/mitmproxy | Yayın anında yamasız | | IIS, Envoy, ngtcp2/nghttp3, Google quiche | FoxIO'ya göre etkilenmiyor | 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](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) 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. ```bash 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](https://blog.gitguardian.com/railway-october-2026-incident-environment-variables/) 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](https://status.railway.com/incident/QH8L8B3E) 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](https://www.bleepingcomputer.com/news/security/ovhcloud-cli-releases-backdoored-on-github-to-steal-developer-secrets/) 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](https://www.php.net/) - [PHP Foundation · Today's PHP Security Release, and How We're Strengthening PHP Security](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) - [The Next Web · PHP knew about one of the flaws in 2024 but could not agree a fix](https://thenextweb.com/news/php-foundation-structural-failure-2024-flaw-leak) - [Wiz Research · PHP2Shell](https://www.wiz.io/blog/php2shell-php-rce) - [AWS Security Blog · PHP2Shell exploitation prior to public disclosure in MadPot](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) - [watchTowr · PHP2Shell FAQ](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/) - [The Hacker News · PHP Issues Emergency Patches](https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html) - [AlmaLinux · Patched PHP packages](https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/) - 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](https://openjdk.org/groups/vulnerability/advisories/2026-10-21) - [The Hacker News · New QPACK Flaws Can Crash HTTP/3 Servers](https://thehackernews.com/2026/10/new-qpack-flaws-can-crash-http3-servers.html) - [Node.js · October 2026 Security Releases](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) - [Railway status · QH8L8B3E](https://status.railway.com/incident/QH8L8B3E) - [GitGuardian · New Railway Incident](https://blog.gitguardian.com/railway-october-2026-incident-environment-variables/) - [BleepingComputer · OVHcloud CLI releases backdoored on GitHub](https://www.bleepingcomputer.com/news/security/ovhcloud-cli-releases-backdoored-on-github-to-steal-developer-secrets/) - [TechCrunch · The internet is having a very bad cybersecurity day](https://techcrunch.com/2026/10/21/the-internet-is-having-a-very-bad-cybersecurity-day/)