Bir Haftada Altı Büyük Olay: Açık Dalgasında Neyi Önce Yamalarsınız?

14 ile 21 Ekim 2026 arasında birbirinden bağımsız altı olay duyuruldu: NGINX’te beş güvenlik açığı, eMudhra’nın sertifika otoritesi anahtarlarında zayıflık, PHP’de iki kritik açık, Node.js’te on açık için güvenlik sürümleri, BIND 9’da dört açık ve LiteLLM’in resmî paketlerinin kötü amaçlı bir sürümle ele geçirilmesi. Sosyal medyada bu yoğunluk, yapay zekâ ajanlarının hızlandırdığı bir “açık zinciri”nin işareti olarak yorumlandı. Bu yazıda önce olguları birincil kaynaklarına dayanarak sıralıyor, sonra bu yorumun neye dayanıp neye dayanmadığını anlatıyor, en sonunda da bir kurumun bu haftanın yama kuyruğunu hangi sırayla eritebileceğini öneriyoruz. Bilgiler 24 Ekim 2026’da derlendi; 30 Ekim 2026’da CISA kataloğundaki, Chrome/eMudhra, LiteLLM ve PHP Vakfı kaynaklarındaki gelişmelere göre güncellendi. Durum hızla değişebilir.

Kısaca

• Altı olay farklı niteliktedir: bellek güvenliği açıkları, bir sertifika otoritesinin anahtar üretim hatası ve bir yazılım tedarik zinciri ele geçirilmesi. Hepsini tek bir nedene bağlayan doğrulanmış bir kaynak bulamadık.
• Sahada istismar var: CISA, PHP’nin iki açığını (CVE-2026-109618 ve CVE-2026-109619) 26 Ekim’de, Node.js’in güvenlik sürümlerinde düzelttiği Brotli açığını (CVE-2026-111497) 27 Ekim’de bilinen sömürülen açıklar kataloğuna ekledi; LiteLLM’de kötü amaçlı sürüm fiilen dağıtıldı. ISC, BIND için bilinen aktif istismar olmadığını söylüyor; NGINX’in beş açığı, Node.js’in diğer üç yüksek açığı ve eMudhra için derlediğimiz kaynaklarda istismar bildirimi görmedik ve bunlar katalogda (29 Ekim sürümü) yok. Katalogda olmamak, istismar olmadığı anlamına gelmez.
• Önce internete açık, yaması mevcut ve istismar bildirimi olan sistemlere bakın. Konteyner imajlarındaki ve tek dosyalık uygulamalardaki gömülü kopyaları (Node.js, Go) unutmayın.
• Google, eMudhra’nın emSign ECC Root CA - G3 kökünün kaldırılmasının, Chrome Root Store’a dayanan tüm cihazlara 27 Ekim sabahı (PDT) ulaşmasının beklendiğini duyurmuştu. Sertifikaları bu hiyerarşiden gelen ya da güven deposunu kendisi yöneten sistemleriniz varsa, bu sertifikaların çalışmaya devam edip etmediğini şimdi doğrulayın.

Ne oldu?

NGINX (14 Ekim)

• nginx.org, 14 Ekim’de beş açığın düzeltmesiyle 1.30.6 ve 1.31.7 sürümlerini yayımladı: CVE-2026-15176 (alias ile rewrite birlikte kullanıldığında tampon taşması), CVE-2026-93479 (değişken içeren ifadelerin değerlendirilmesinde tampon taşması), CVE-2026-95101 (HTTP/3’te istek gövdesi enjeksiyonu), CVE-2026-97629 (TLS oturum bileti anahtarı döndürmede oturum sahteciliği) ve CVE-2026-97205 (ngx_http_ssi_module ile AIO kullanımında use-after-free). Bir ay önce, 15 Eylül’de, HTTP/3 modülündeki başka bir tampon taşması (CVE-2026-90439) için 1.30.5 ve 1.31.6 çıkmıştı.
• Önem derecesi kaynağa göre değişiyor. nginx.org kendi danışma sayfasında beşini de “medium” olarak işaretliyor; CVE numarasını veren F5’in kayıtlarında ise üçü (CVE-2026-15176, CVE-2026-93479, CVE-2026-97205) CVSS v4’te 9.2 ile “kritik”. Açıkların çoğu belirli yapılandırmalara bağlı; bu yüzden kararı önem derecesine değil, kendi yapılandırma dosyalarınıza bakarak verin.

eMudhra (17-21 Ekim)

• Hindistan merkezli sertifika otoritesi eMudhra’nın (emSign markası) sekiz ara CA sertifikasının özel anahtarı, yeterli rastgelelik olmadan üretildiği için herkese açık sertifikalardan hesaplanabiliyordu. Altısı web sitesi (TLS), ikisi kod imzalama içindi.
• Bir araştırmacının 17 Ekim’de yaptığı bildirimin ardından Chrome ve Mozilla sertifikaları engelledi; Apple 19, Microsoft 20 Ekim’de izledi. Go (20 Ekim) ve Node.js (21 Ekim) güven depolarını güncelledi. Chrome, emSign ECC Root CA - G3 kökünü Chrome Root Store’dan kaldırdı; Google’a göre bu kaldırmanın Chrome Root Store’a dayanan tüm cihazlara 27 Ekim sabahı (PDT) ulaşması bekleniyordu.
• eMudhra’ya göre sekiz ara CA’dan hiçbiri son kullanıcı sertifikası vermedi ve yalnızca biri üretimde dağıtıldı; Chrome’un kök programına göre bu ara CA’lardan zincirlenen hiçbir TLS sertifikası Certificate Transparency kayıtlarında yoktu. Kötüye kullanım kanıtı yok. Ancak tarayıcı dışındaki yazılımlar (Go ve Node.js uygulamaları, Python certifi, özel güven depoları, API istemcileri, cihazlar) iptal bilgisini ya da Certificate Transparency’yi denetlemiyorsa risk sürüyor.
• eMudhra, 28 Ekim tarihli açıklamasında kamuya açık güvenilir TLS hizmetlerini gönüllü olarak sonlandırma sürecinde olduğunu, G1 kökünden de geçiş tamamlanınca TLS sertifikası vermeyi bırakacağını belirtti. eMudhra TLS sertifikası kullanıyorsanız başka bir sağlayıcıya geçişi planlayın.

PHP (21 Ekim)

• PHP projesi iki kritik açığı (CVE-2026-109618 ve CVE-2026-109619; CVSS v4 9.2) 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleriyle kapattı. Malwarebytes, Cloudflare’in teknoloji yöneticisinin “erken saldırılar” uyarısını aktarmıştı; CISA ise iki açığı 26 Ekim’de bilinen sömürülen açıklar kataloğuna ekledi ve hemen yamalanamayan ya da PHP 8.1 ve öncesi gibi desteği bitmiş sürümleri kullanan sistemlerin yama yapılana kadar çevrimdışı alınmasını öneriyor. CISA ayrıca bir Linux çekirdeği açığının (CVE-2026-46300, 28 Ekim’de kataloğa eklendi) bu PHP açıklarıyla zincirlenerek web kabuğu yerleştirmek ve root olarak komut çalıştırmak için kullanılabildiğini belirtiyor; PHP çalıştıran sunucuların çekirdeğini de güncel tutun. Etkilenip etkilenmediğinizi nasıl kontrol edeceğinizi PHP rehberimizde anlattık.

Node.js (21 Ekim)

• Node.js projesi 26.12.1, 24.22.1 ve 22.23.4 sürümlerini yayımladı: on açık, dördü “yüksek”. CVE-2026-111497, Brotli kod çözücüde sınır dışı yazma; Node.js bunun çökmeye, bellek sızıntısına ya da uzaktan kod çalıştırmaya yol açabileceğini belirtiyor (CVE kaydında Google Brotli 1.0.3-1.2.0 etkileniyor, CVSS v4 9.2); CISA bu açığı 27 Ekim’de bilinen sömürülen açıklar kataloğuna ekledi. Diğer üç yüksek açık, DNS adlarının NUL baytında kesilmesi (CVE-2026-105482) ve iki TLS ana makine adı doğrulaması atlatmasıdır (CVE-2026-105483, CVE-2026-106069).
• Node.js 20 ve öncesi için düzeltme yok (Node.js 20, 30 Nisan 2026’da destek ömrünü doldurdu); geçici çözüm de yayımlanmadı. Konteyner imajları ve tek dosyalık uygulamalar kendi Node.js kopyasını taşır: yeniden derlemeden yama uygulanmış olmaz. Brotli’yi kullanan başka yazılımlarınız varsa onların da bağımlılıklarına bakın.

BIND 9 (21 Ekim)

• ISC, 21 Ekim’de dört açığı duyurdu ve 9.20.30 ile 9.21.27’yi yayımladı (erken bildirim 14 Ekim’de yapılmıştı). En ciddisi CVE-2026-94300: eşzamanlı GSS-TSIG iletileri bellek bozulmasına yol açıyor; çökmeye, belirli koşullarda uzaktan kod çalıştırmaya neden olabilir (CVSS 8.1, saldırı karmaşıklığı yüksek). Diğer üçü hizmet reddi (CVSS 7.5): CVE-2026-19630 (gelen ileti işlemede kaynak tüketimi), CVE-2026-96888 (redirect bölgesi ile katı QNAME minimizasyonu) ve CVE-2026-97313 (belirli RPZ yapılandırmaları).
• ISC “bilinen aktif istismar yok” ve “bilinen geçici çözüm yok” diyor. Etkilenen aralık 9.18.50’ye kadar uzanıyor, ancak danışma metinlerinde 9.18 için düzeltilmiş sürüm listelenmiyor. 9.18 çalıştırıyorsanız ISC’nin “mevcut sürümünüze en yakın yamalı sürüme geçin” yönlendirmesine göre 9.20’ye geçişi planlayın; dağıtım paketlerinizi de kontrol edin.

LiteLLM (21 Ekim)

• Bu bir güvenlik açığı değil, tedarik zinciri ele geçirilmesidir. LiteLLM’in kendi olay raporuna göre 21 Ekim’de PyPI’daki litellm==1.107.0 (UTC 11:39-13:23) ve Docker Hub ile GHCR’deki v1.107.0, latest, main-latest, main-stable etiketleri (Docker Hub’da 11:46-14:20) kimlik bilgilerini çalan ve uzaktan kod çalıştırma araçları yükleyen kötü amaçlı kod içeriyordu. LiteLLM’in 23 Ekim’de yayımladığı kanonik rapora göre (ilk raporun bazı varsayımları sonradan yanlış ya da eksik çıktı) saldırı, 27 Mayıs’ta herkese açık bir depoya yanlışlıkla işlenen ve iptal edilmeyen, dahili deneysel bir hizmetin (Agent Platform) yönetici anahtarıyla başladı. Saldırgan bu anahtarı 10 Ekim’de kullanarak bir GitHub kuruluş sahibinin GitHub CLI OAuth belirtecini aldı ve ele geçirdiği geliştirici belirteçleriyle yayın hattını kötüye kullandı.
• LiteLLM, önceki tüm sürümlerin güvenli olduğunu söylüyor ve litellm==1.106.2 ya da bundan önceki bir sürüme sabitlemeyi öneriyor. 1.107.0’ı çalıştırdıysanız sistemi ele geçirilmiş kabul edin. Yalnızca paketi kaldırmak yetmez: kötü amaçlı kod, Python her başladığında yeniden çalışan cook.pth ve sitecustomize.py dosyalarıyla yerleşiyor. İmajları ve sanal ortamları sıfırdan kurun, erişilebilir tüm kimlik bilgilerini (bulut rolü, proxy veritabanındaki sağlayıcı anahtarları, ana ve sanal anahtarlar, DATABASE_URL parolası, ortam değişkenleri) döndürün ve bulut günlüklerinde bu kimlik bilgilerinin kurumunuz dışından kullanılıp kullanılmadığına bakın.
• Aynı ürün 2026’da başka açıklar da yaşadı: CVE-2026-42208 (SQL enjeksiyonu) ve CVE-2026-42271 (komut enjeksiyonu) CISA’nın bilinen sömürülen açıklar kataloğunda; CVE-2026-42208, NVD’de yayımlandığı gün (8 Mayıs 2026) kataloğa eklendi.

Bu olaylar yapay zekâyla mı ilgili?

23 Ekim’de X’te geniş okunan bir paylaşımda, son günlerin olayları, kötü niyetli aktörlerin binlerce yapay zekâ ajanıyla açık bulup istismar ettiği ve bu sürecin yeni açıkları da saatler içinde ortaya çıkardığı bir “açık zinciri” olarak yorumlandı. Bu yorumu ciddiye alıyoruz ama olgu olarak sunmuyoruz:

• Olaylar aynı türden değil. NGINX, PHP, Node.js ve BIND’deki açıklar bellek ve ayrıştırma hatalarıdır; eMudhra’da anahtar üretiminde bir tören hatası (şirketin açıklamasına göre anahtar sarma ve açma hatası), LiteLLM’de çalınmış geliştirici belirteçleriyle yapılan bir yayın hattı saldırısı var. Zamanlama da farklı: NGINX düzeltmeleri 14 Ekim’de çıktı; BIND açıkları 14 Ekim’de erken bildirimle paylaşılmış, 21 Ekim’de kamuya açılmıştı.
• Altı olayı tek bir nedene bağlayan bir kaynak bulamadık. Hiçbir üretici duyurusu ya da bağımsız analiz, bu olayları tek bir saldırgan dalgasına bağlamıyor. Yapay zekâ destekli araştırma ise bazı açıkların bulunuşunda ve doğrulanışında yer alıyor: PHP Vakfı, PHP’yi bu yıl Anthropic’in Claude Mythos modeliyle taradıklarını, raporların ve istismarların doğrulanmasında OpenAI’ın Daybreak Red aracını kullandıklarını ve teşekkür ettikleri araştırmacılar arasında OpenAI Codex Security’nin de bulunduğunu yazıyor; Node.js da Brotli açığını bildirenler olarak OpenAI Codex Security’yi anıyor. Bunlar savunma tarafındaki keşif ve doğrulama süreçleridir; saldırganların aynı yöntemleri kullandığını göstermez.
• Ölçülebilen bir şey var: açık hacmi. NIST’in ulusal güvenlik açığı veritabanında (NVD) aylık yayımlanan yeni CVE kaydı sayısı Ocak 2022’de 2.016 iken Eylül 2026’da 14.933’e çıktı.

Grafik: NIST NVD verisinden, 24 Ekim 2026’da Seemarter Security tarafından çizilmiştir (reddedilen kayıtlar hariç; 2026 ayları vurgulanmıştır).

Bu sayı tek başına riskin arttığını göstermez: CVE numarası veren kuruluşların sayısı, toplu kayıtlar ve açık bulma yöntemleri sayıyı etkiler. Savunma tarafı için tartışmasız sonucu ise yama kuyruğunun uzamasıdır.

• Yapay zekâ destekli keşif beklentisi gerçek; ama bu haftanın nedeni olarak kanıtlanmış değil. Anthropic, Nisan 2026’da Claude Mythos Preview modelinin “binlerce yüksek önemde açık” bulduğunu duyurdu ve modeli genel kullanıma açmadı (şirketin kendi beyanıdır, bağımsız olarak doğrulanmamıştır). Bu tür sistemler yaygınlaştıkça açıkların bulunması ve istismar kodunun hazırlanması hızlanabilir. Bu haftaki olaylarda yapay zekâ destekli araçların savunma tarafındaki rolünü üreticiler kendileri belirtiyor (yukarıda); saldırı tarafında böyle bir bağ gösteren bir kaynak bulamadık.

Nedenden bağımsız olarak savunma tarafı için sonuç aynıdır: keşfedilen açık sayısı arttıkça ve duyurudan istismara geçen süre kısaldıkça, kurumun envanteri, önceliklendirmesi ve doğrulaması belirleyici olur.

Yama önceliğini nasıl belirlersiniz?

Aynı hafta içinde birden çok bileşen için güncelleme gerektiğinde şu sırayı öneriyoruz:

1. Envanteri çıkarın. Hangi sistem hangi bileşeni, hangi sürümle, nerede çalıştırıyor? Ters vekil ve web sunucusu (NGINX), DNS (BIND), uygulama çalışma zamanı (PHP, Node.js), yapay zekâ ağ geçidi ve kütüphaneleri (LiteLLM), güven depoları (eMudhra) için ayrı ayrı bakın. Komut satırındaki sürüm hizmetin gerçekte kullandığından farklı olabilir; konteyner imajları ve ikili dosyalar kendi kopyasını taşır.
2. İnternete açık olanları öne alın. Dışarıdan erişilebilen bir NGINX, PHP uygulaması ya da DNS çözümleyici, yalnızca iç ağda çalışanların önüne geçer.
3. İstismar bildirimi olanları öne alın. CISA’nın bilinen sömürülen açıklar kataloğu, üretici duyuruları ve güvenilir tehdit istihbaratı bu kararda kullanılır. Katalogda olmamak güvende olduğunuz anlamına gelmez: PHP açıkları 23 Ekim kataloğunda yoktu, ama erken saldırı bildirimleri vardı ve CISA bunları 26 Ekim’de kataloğa ekledi.
4. Yapılandırma koşuluna bakın. NGINX açıklarının çoğu belirli yapılandırmalara (alias ile rewrite, map ve değişkenler, HTTP/3, SSI ve AIO, TLS oturum bileti) bağlı; BIND açıkları GSS-TSIG, redirect bölgesi ve RPZ gibi özelliklere bağlı. Bu özellikleri kullanmıyorsanız aciliyet düşer, ancak bunu varsayımla değil yapılandırma dosyalarına bakarak doğrulayın ve güncellemeyi yine de planlayın.
5. Düzeltmenin gerçekten uygulandığını doğrulayın. Dağıtım paketlerinde yama, sürüm numarasına yansımadan uygulanmış olabilir; paketin değişiklik kaydına bakın. Konteyner imajlarını ve Node.js ya da Go ile derlenmiş ikili dosyaları yeniden derleyip yeniden dağıtın.
6. Destek ömrünü doldurmuş sürümleri ayrı bir listeye alın. Node.js 20 ve öncesi, PHP 8.1 ve öncesi ve BIND 9.18 için bu haftanın düzeltmeleri ya yok ya da sınırlı. Çözüm sürüm yükseltmesidir ve ayrı bir iş olarak planlanmalıdır.
7. Tedarik zinciri olaylarında önce temizliği düşünün. LiteLLM 1.107.0 gibi bir olayda “güncellemek” yetmez; paketin çalıştığı sistemi ele geçirilmiş sayıp kimlik bilgilerini döndürmek gerekir. Bağımlılık sürümlerini sabitlemek ve yeni yayımlanan sürümleri birkaç gün bekletmek (ör. npm’deki min-release-age ayarı) bu tür olaylarda maruz kalma süresini kısaltır.
8. Sertifika güvenini kontrol edin. Sertifika zincirlerinizde emSign (eMudhra) var mı, kod imzalama için eMudhra kullanıyor musunuz? Özel güven depolarınız ya da gömülü CA paketleriniz (certifi, Node.js, Go, konteyner imajları) güncel mi? Mozilla, iptal kontrolünün güvenilir yapılmadığı yazılımlarda sekiz ara CA’yı elle engellemeyi öneriyor. Google kökü Chrome Root Store’dan kaldırdığı için bu zincirle çalışan web sitelerinin başka bir hiyerarşiye geçmesi gerekir.
9. İzleyin. Güncelleme, daha önce gerçekleşmiş olabilecek bir ele geçirmeyi ortadan kaldırmaz. Web sunucularında, DNS sunucularında ve derleme makinelerinde olağan dışı süreç, ağ trafiği ve kimlik bilgisi kullanımını izleyin.

Zafiyet taraması ve sızma testi bu haftada ne işe yarar?

Önce sınırı koyalım: Zafiyet taraması ve sızma testi, henüz kamuya açıklanmamış bir açığı önceden bulmak için tasarlanmış araçlar değildir ve hiçbir test bu konuda garanti vermez. Bu haftanın tablosunda değerleri üç yerde görünür olur:

1. Dışarıdan görünen yüzey ve sürümler. Dış ağ zafiyet taraması, internete açık IP adreslerinizi, alan adlarınızı ve yayındaki servisleri çıkarır; servis sürümlerini bilinen zafiyetlerle (CVE) eşler. Unutulmuş test ortamları, eski kampanya siteleri ve hosting sağlayıcısında duran sistemler envanterde çoğu zaman en geç fark edilenlerdir. Kurum içindeki sistemler için iç ağ zafiyet taraması, mümkün olduğunda kimlik doğrulamalı yapılarak eksik yamaları daha ayrıntılı gösterir. Farkı zafiyet taraması ile sızma testi yazımızda anlattık.
2. Etkinin sınırı. Bir NGINX, Node.js ya da PHP sunucusu ele geçirilirse saldırgan oradan nereye ulaşır; sunucuda hangi sırlar (örneğin bir yapay zekâ ağ geçidinin sakladığı sağlayıcı anahtarları, bulut kimlik bilgileri) duruyor? Dış ağ sızma testi ve iç ağ sızma testi bu soruları ağ bölümlendirmesi, yetkiler ve gizli bilgiler açısından kontrollü biçimde sınar. Yamadan önce de sonra da önemli olan, tek bir açığın tüm ağa yayılmasını engelleyen katmanların gerçekten çalışıp çalışmadığıdır.
3. Yeniden test. Düzeltmeler uygulandıktan sonra yapılan yeniden test ve doğrulama raporu, dışarıdan görünen sürüm ve servis bilgisinin düzeldiğini gösterir. Dışarıdan yapılan bir tarama yapılandırma ayarlarını, dağıtım yamalarını ya da konteyner imajı içindeki kopyaları göremez; bunların sistem tarafında ayrıca doğrulanması gerekir.

Seemarter Security ile

Dış ağınızın mevcut durumunu görmek için dış ağ zafiyet taraması ve dış ağ sızma testi hizmetlerimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz. Tüm çalışmalar, sistem sahibinin yazılı yetkisiyle ve önceden belirlenen kapsamda yapılır.

Kaynaklar

• nginx.org güvenlik danışmaları ve nginx.org duyuruları (14 Ekim 2026: 1.30.6 ve 1.31.7)
• NVD kayıtları (önem dereceleri ve tarihler): CVE-2026-15176, CVE-2026-93479, CVE-2026-97205, CVE-2026-111497
• The Hacker News: eMudhra’nın sekiz CA anahtarı ele geçirildi
• SecurityWeek: Tarayıcılar, kurtarılabilir özel anahtarlar nedeniyle eMudhra ara CA’larını engelledi
• Google: Chrome ve Android kullanıcılarının eMudhra ara CA’larına karşı korunması (20 Ekim 2026) ve eMudhra olay durum sayfası (28 Ekim güncellemesi)
• PHP resmî güvenlik duyurusu (21 Ekim 2026) ve Malwarebytes: PHP2Shell, PHP Vakfı: 21 Ekim güvenlik sürümü ve PHP güvenliğinin güçlendirilmesi
• Node.js: Ekim 2026 güvenlik sürümleri
• ISC: BIND 9’da dört açık (oss-security, 21 Ekim 2026), ISC CVE-2026-94300, ISC CVE-2026-96888
• LiteLLM olay raporu (21 Ekim 2026), LiteLLM kanonik kök neden raporu (23 Ekim 2026) ve Datadog Security Labs analizi
• CISA bilinen sömürülen açıklar kataloğu (29 Ekim 2026 sürümü), CISA: PHP açıkları için acil yama uyarısı ve NIST NVD (aylık sayımlar NVD API’sinden alınmıştır)
• Anthropic: Project Glasswing (şirket beyanı)
• X’te John Gedmark’ın 23 Ekim 2026 tarihli paylaşımı (yorumun kaynağıdır, olguların kaynağı değildir)

Bu yazı 24 Ekim 2026’da yayımlandı; 30 Ekim 2026’da CISA kataloğundaki, Chrome/eMudhra, LiteLLM ve PHP Vakfı kaynaklarındaki gelişmelere göre güncellendi. Gelişmelere göre güncellenir.