Tek haftada Node.js, BIND ve Java: Ekim 2026 güvenlik sürümlerine sunucu tarafından bakış

Güvenlik sürümleri nadiren bu kadar üst üste gelir. Tek haftada ISC BIND 9’u yamaladı, Oracle üç aylık Critical Patch Update’ini ve ardından acil bir Java uyarısını yayımladı, Node.js on düzeltme çıkardı ve tarayıcılar, özel anahtarlarının zayıf olduğu anlaşılan sekiz ara sertifika otoritesini engelledi. Her biri tek başına yönetilebilir. Birlikte ise DNS’e, TLS güven zincirine ve sunucudaki en yaygın iki uygulama çalışma ortamına dokunuyorlar; bu yüzden tek bir iş olarak ele almak mantıklı.

Bir bakışta hafta

ISC, BIND sorunlarını 14 Ekim’de müşterilerine erken bildirimle iletti. 17 Ekim’de bir araştırmacı Mozilla’ya sekiz eMudhra ara CA anahtarının ele geçirildiğini bildirdi; Chrome aynı gün engelledi, Apple 19’unda, Microsoft 20’sinde onu izledi. Oracle, Ekim Critical Patch Update’ini 20 Ekim’de yayımladı. 21 Ekim’de ISC BIND bildirimlerini yayımladı, Node.js 22.23.4, 24.22.1 ve 26.12.1’i çıkardı, Oracle Java için CVE-2026-91403 güvenlik uyarısını yayımladı ve eMudhra zayıf anahtarlarla ilgili açıklamasını yaptı.

BIND 9: dört yüksek önem dereceli düzeltme

Puanlanan iki sorun için etkilenen aralıklar 9.11.0 ile 9.18.50, 9.20.0 ile 9.20.29 ve 9.21.0 ile 9.21.26 arası. Düzeltilmiş sürümler 9.20.30 ve 9.21.27; ISC, GSS-TSIG hatası için geçici çözüm listelemiyor. 9.18 dalının ömrü doldu, yani ana yol 9.20’ye geçmek. ISC aktif bir istismardan haberdar olmadığını belirtti.

Kurumsal dağıtımlar eski BIND sürümlerini kendi geriye taşıdıkları yamalarla dağıtır; bu yüzden ana sürüm numarası ölçüt değildir. Bu CVE numaraları için dağıtımınızın errata kayıtlarına ve paket değişiklik günlüğüne bakın.

Node.js ve Java: güven zinciri de değişti

Node.js sürümü dördü yüksek önem dereceli on CVE’yi kapattı ve gömülü c-ares, OpenSSL, Undici ve CA sertifika deposunu güncelledi. CA değişikliği ele geçirilen eMudhra ara sertifikalarını kaldırıyor; bu önemli, çünkü Node.js varsayılan olarak işletim sisteminin değil, kendi gömülü kök sertifikalarını kullanır.

Java’da da durum aynı. Oracle’ın Ekim Critical Patch Update’i 55 Java SE düzeltmesi içeriyordu ve bunların 49’u kimlik doğrulaması olmadan uzaktan istismar edilebilir nitelikteydi. Bir gün sonra Oracle, JSSE bileşeni için 9.1 puanlı CVE-2026-91403 güvenlik uyarısını yayımladı; bu bileşen, ele geçirilen eMudhra ara sertifikalarından gelen sertifikaları kabul etmeye devam edebiliyordu. Haberlerde Ekim güncellemesiyle gelen derlemeler de etkilenenler arasında sayılıyor; yani üç aylık güncellemeyi 20 Ekim’de kurmuş bir sunucunun uyarı düzeltmesine de ihtiyacı var.

Bir BIND sürümünü bildirimlerle karşılaştırın:

Bir BIND sunucusunun hangi rolü üstlendiği nasıl anlaşılır?

BIND bildirimleri role göre ayrışıyor, bu yüzden her sunucu için ilk soru ne iş yaptığı. named-checkconf -p etkin yapılandırmayı yazdırır: allow-recursion listesiyle birlikte bir recursion yes; sunucunun istemciler için ad çözümlediği anlamına gelir, primary ya da secondary türündeki zone tanımları sunucunun yetkili olduğunu gösterir ve birçok sunucu ikisini birden yapar. GSS-TSIG, tkey-gssapi-keytab ya da tkey-gssapi-credential seçeneği olarak görünür; genellikle yanında Kerberos principal’larına kayıt güncelleme hakkı veren bir update-policy bulunur.

allow-recursion ayarı açık bırakılmış bir çözümleyici, CVE-2026-19630 için en kötü durumdur, çünkü ona sorgu gönderebilen herkes kaynak tüketimini tetikleyebilir. Özyinelemeyi kendi ağlarınızla sınırlamak hatayı düzeltmez, ama yükseltme tamamlanana kadar ona ulaşabilecek kişilerin sayısını daraltır.

Her güven deposunda eMudhra ara sertifikaları nasıl kontrol edilir?

Her depo farklı bir komuta yanıt verir. İşletim sistemi paketi, Red Hat ailesi sistemlerde trust list | grep -i emsign ile listelenebilir. Bir JDK’nın kendi deposu keytool -list -cacerts ile okunur ve aynı şekilde filtrelenir. Node.js kök sertifikalarını ikili dosyanın içinde tutar, bu yüzden en hızlı kontrol çalışma ortamının 22.23.4, 24.22.1 ya da 26.12.1 sürümünde olduğunu doğrulamaktır; gömülü deposu güncellenen derlemeler bunlardır.

İki uyarı. Listede emSign adlı bir kök kaydın bulunması, ele geçirilmiş bir ara sertifikayla aynı şey değildir; engellenen sertifikalar ara sertifikalardı ve birçok proje bunları yeni bir kök listesi yayımlayarak değil, güvenini kaldırarak ya da silerek ele aldı. Bu yüzden elle bir şey silmeden önce sağlayıcınızın duyurusunu okuyun. Ayrıca bir servis, değişen depoyu ancak yeniden başladığında devreye alır.

Bir cPanel sunucusundan saha notu

cPanel sunucularımızdan birinde bind paketi kurulu; sürümü 9.11.36’nın Red Hat geriye taşımalı bir derlemesi. Ama sunucu bu BIND açıklarına açık değil: cPanel PowerDNS kullanacak şekilde yapılandırılmış ve named çalışmıyor. Paket, araçları için orada. Ders şu: acil bir yükseltme planlamadan önce paket listesine değil servise bakın, paketi de yine güncel tutun ki bir gün açıkta kalan o olmasın.

Üç sürüm birbirine nasıl bağlanıyor?

Her sağlayıcının sürümünü ayrı bir ticket olarak ele almak cazip gelir. Pratikte ise ortak bir bağımlılıkları (TLS güven zinciri) ve ortak bir kısıtları (yeniden başlatmalar) var. BIND, DNS tarafında ayrı duruyor; ama Java ve Node.js servisleriyle aynı bakım penceresinde yükseltilip yeniden başlatılan bir çözümleyici, ikinci bir değişiklik onayı turundan ve panelleri izleyerek geçen ikinci bir geceden kurtarır.

Bizim izlediğimiz sıra şöyle: önce DNS, çünkü diğer tüm servisler ad çözümlemeye bağlıdır ve bozuk bir çözümleyici sonraki her sorunu gizler; ardından işletim sistemi güven paketi; sonra çalışma ortamları, her birinin ardından onu kullanan servislerin yeniden başlatılmasıyla; en son da sunucuların kendilerinin sunduğu sertifikaların kontrolü. Her adımın kendi doğrulaması vardır ve bir sonraki adım ancak önceki temiz çıktığında başlar.

Java, uygulamaları bozmadan nasıl güncellenir?

Java, belirli bir derlemeye en sık sabitlenen çalışma ortamıdır; ya tek bir sürümü sertifikalandıran bir sağlayıcı yüzünden ya da kendi JRE’siyle paketlenmiş bir uygulama yüzünden. Bu da envanteri işin zor kısmı yapar. Uygulama dizinlerinin altındaki kopyalar dahil sunucudaki her java ikili dosyasını arayın ve hangilerinin işletim sistemi tarafından yönetildiğini, hangilerinin bir ürünün içinde geldiğini not edin.

Yönetilen kopyalarda Ekim güncellemesini ve CVE-2026-91403 düzeltmesini uygulayın, servisleri yeniden başlatın ve ilk bir saat boyunca günlüklerinde TLS el sıkışma hatalarını izleyin; güven deposu değişikliği ilk orada kendini gösterir. Ürünle birlikte gelen kopyalarda ise çalışma ortamını ürünün altından değiştirmek yerine sağlayıcıdan uyarı düzeltmesini içeren bir derleme isteyin, çünkü bu değişiklik ürünün desteğini geçersiz kılabilir. Sağlayıcının yanıtını ve tarihini kaydedin ki istisnanın bir sahibi ve bir bitişi olsun.

Sunucularınızda yapmanız gerekenler

1. Her named’i bulun. Her sunucuda systemctl is-active named ve named -v çalıştırın; yetkili sunucu mu, çözümleyici mi, ikisi birden mi olduğunu ve GSS-TSIG kabul edip etmediğini not edin.
2. BIND’i yükseltin. 9.20.30 ya da 9.21.27’ye ya da dağıtımınızın düzeltilmiş paketine geçin ve named‘i yeniden başlatın. Önceliği çözümleyicilere ve GSS-TSIG dinamik güncellemelerini kabul eden sunuculara verin.
3. 9.18 ve öncesini emekliye ayırın. Bunlar ISC’den GSS-TSIG düzeltmesini almayacak.
4. Her güven deposunu güncelleyin. İşletim sistemi paketi (ca-certificates), kurulu her JDK’nın cacerts dosyası ve Node.js’in gömülü kök sertifikaları birbirinden ayrı. Birini güncellemek diğerlerini güncellemez.
5. Java envanteri çıkarın. Uygulamalarla birlikte gelen kopyalar dahil sunucudaki her JDK ve JRE’yi listeleyin; hem Ekim güncellemesini hem de CVE-2026-91403 uyarı düzeltmesini uygulayın.
6. Node.js’i güncelleyin. 22.23.4, 24.22.1 ya da 26.12.1; paneller, derleme araçları ve süreç yöneticilerinin kullandığı kopyalar dahil.
7. Servisleri yeniden başlatın. Java ve Node.js süreçleri yeniden başlayana kadar eski çalışma ortamını ve güven deposunu bellekte tutar.
8. Kendi sertifikalarınızı kontrol edin. Sunduğunuz herhangi bir sertifika bir eMudhra ara sertifikasına bağlanıyorsa, istemciler ona güvenmeyi bırakmadan önce başka bir CA’dan yeniden aldırın.

Aynı ayın başında PHP, acil PHP2Shell sürümünü yayımlamıştı; bunu PHP2Shell yama günü rehberinde ele aldık. Sunucu sıkılaştırmanın çekirdek tarafı ise paylaşımlı bir Linux sunucu için beş çekirdek ayarı yazısında.

Kısaca

Haftanın sürümleri birbiriyle ilgisiz üç ticket gibi görünüyordu, ama güven ve yeniden başlatmalarla ilgili tek bir iş olduğu ortaya çıktı. Önce DNS’i, sonra güven paketlerini, sonra çalışma ortamlarını ele alın, her birini kendi doğrulamasıyla; en sonda da kendi sunucularınızın sunduğu sertifikaları kontrol ederek bitirin. Emeğin büyük kısmı envanterdir: hangi sunucularda named çalıştığını, hangi JDK’ların nerede bulunduğunu ve hangi süreçlerin hâlâ bellekte eski bir çalışma ortamı tuttuğunu bilmek. Bir sonraki böyle haftayı kısaltan da yine bu envanterdir.

SSS: Node.js, BIND ve Java güvenlik sürümleri, Ekim 2026

Ekim 2026’da duyurulan CVE-2026-94300 açığı hangi BIND sunucularını etkiliyor?

BIND 9.11.0 ile 9.18.50, 9.20.0 ile 9.20.29 ya da 9.21.0 ile 9.21.26 arası bir sürüm çalıştıran ve GSS-TSIG mesajlarını kabul eden sunucular; bu genellikle Kerberos ya da Active Directory dinamik güncellemeleri içindir. ISC geçici çözüm listelemiyor, dolayısıyla çözüm 9.20.30, 9.21.27 ya da yamalı bir sağlayıcı paketidir.

BIND 9.18, Ekim 2026 GSS-TSIG düzeltmesini ISC’den alacak mı?

Hayır. 9.18 dalının ömrü doldu ve GSS-TSIG düzeltmesini ana projeden almıyor. 9.20’ye geçin ya da düzeltmeyi kendi BIND paketine geriye taşıyan ve bunu errata kayıtlarında belirten bir dağıtım kullanın.

BIND çözümleyici mi yetkili sunucu mu: Ekim 2026 düzeltmelerinde hangisi daha fazla risk taşıyor?

Riskin büyük kısmını çözümleyiciler taşıyor. CVE-2026-19630 ile RPZ ve redirect bölgesi çökmeleri özyinelemeli sunucuları ilgilendiriyor, CVE-2026-94300 ise role değil GSS-TSIG’e bağlı. İkisini birden yapan bir sunucu önce yükseltilmeli.

bind paketi kurulu ama named çalışmıyorsa sunucu açıkta mı?

Bu ağ hatalarına karşı değil, çünkü dinleyen bir şey yok. systemctl is-active named ile kontrol edin. Paketi yine de güncel tutun, çünkü ileride yapılacak bir yapılandırma değişikliği servisi eski bir derlemeyle başlatabilir.

Ekim 2026’da eMudhra ara sertifika otoritelerinin sertifikalarına ne oldu?

Bir araştırmacı 17 Ekim’de sekiz eMudhra ara CA’sının özel anahtarlarının ele geçirildiğini bildirdi. eMudhra, bir anahtar üretme kusurunun zayıf anahtarlar ürettiğini açıkladı. Tarayıcılar ara sertifikaları 17 ile 20 Ekim arasında engelledi, Node.js ve Java da güncellemelerle onları izledi.

Java Ekim CPU mu CVE-2026-91403 güvenlik uyarısı mı: sunucuların ikisine de ihtiyacı var mı?

Evet. 20 Ekim tarihli Critical Patch Update 55 Java SE düzeltmesi içeriyordu, 21 Ekim tarihli uyarı ise JSSE’deki eMudhra güven sorununu ele aldı. Haberlerde Ekim güncellemesindeki derlemeler de etkilenenler arasında sayılıyor, bu yüzden uyarının belirttiği derlemeyi kurun.

Node.js, bir Linux sunucuda işletim sisteminin sertifika deposunu kullanır mı?

Varsayılan olarak hayır. Node.js, --use-system-ca ile başlatılmadıkça ya da kendisine ek sertifikalar verilmedikçe ikili dosyaya derlenmiş bir CA listesine güvenir; bu yüzden yalnızca ca-certificates paketini güncellemek bir Node.js servisinin neye güvendiğini değiştirmez.

Ekim 2026 güvenlik düzeltmeleri hangi Node.js sürümlerinde bulunuyor?

21 Ekim 2026’da yayımlanan Node.js 22.23.4, 24.22.1 ve 26.12.1. Bu sürümler dördü yüksek önem dereceli on CVE’yi düzeltiyor ve gömülü c-ares, OpenSSL, Undici ve CA deposunu güncelliyor. Node.js 20 ve öncesi bunların hiçbirini almıyor.

eMudhra ara sertifikası altında verilmiş bir web sitesi sertifikasını yeniden aldırmak gerekir mi?

Evet, etkilenen ara sertifikalardan birine bağlanıyorsa. Bunları zaten engellemiş istemciler sertifikayı reddedecektir; bu yüzden daha fazla istemci güncellenip ziyaretçiler hata görmeye başlamadan önce sertifikayı başka bir CA’dan alınmış bir sertifikayla değiştirin.

ca-certificates ya da bir JDK güncellendikten sonra çalışan servisler yeni güven deposunu alır mı?

Hayır. Java ve Node.js süreçleri güven depolarını başlangıçta yükler ve yeniden başlayana kadar tutar; uzun süre çalışan birçok servis de aynı şekilde davranır. Güncellemeden sonra onları yeniden başlatın, yoksa eski güven kararları geçerli kalmaya devam eder.

Kaynaklar

• CVE-2026-94300 ve CVE-2026-19630, ISC Knowledge Base
• CVE-2026-97313, ISC Knowledge Base
• Ekim 2026 güvenlik sürümleri, nodejs.org
• Oracle Ekim 2026 Critical Patch Update, Tenable
• Google ve Mozilla eMudhra ara sertifikalarını iptal etti, CSO Online