Kritik Java JSSE açığı CVE-2026-91403, ele geçirilen eMudhra CA'larından gelen sertifikalara güveniyor

Kritik Java güven açığı, ele geçirilen CA'lardan gelen sertifikaları kabul ediyor

21 Ekim 2026'da Oracle Java SE'nin TLS güven yönetimindeki kritik bir açıklık CVE-2026-91403 olarak yayımlandı ve CVSS v3.1 taban puanı 9.1 olarak belirlendi. dev.to'da yayımlanan bir duyuruya göre kök neden Java'nın kendisinin dışında: eMudhra'nın (emSign) işlettiği sekiz ara sertifika otoritesinin özel imzalama anahtarları ele geçirildi. On altı sertifika etkileniyor; bunlar emSign ve bir Sectigo AAA cross-signing zincirini kapsıyor ve Ekim 2026 öncesinde yayımlanan Java runtime'ları bunların tümünü hâlâ güvenilir sayıyor.

Açık, kırık veya riskli bir kriptografik algoritma kullanımı anlamına gelen CWE-327 altında sınıflandırıldı ve buna karşılık gelen bir GitHub advisory'si var: GHSA-9h75-rf66-wh3r. CVSS vektörü — ağ üzerinden erişilebilir, düşük saldırı karmaşıklığı, ayrıcalık veya kullanıcı etkileşimi gerektirmiyor — gizlilik ve bütünlük üzerinde ciddi etki, erişilebilirlik üzerinde ise etki olmadığı anlamına geliyor; bu da sessiz dinlemeden çok bir çökmeyi andırıyor. Rapor mevcut bir proof-of-concept'ten, yüzde 0,38'lik bir EPSS skorundan ve henüz CISA'nın Known Exploited Vulnerabilities kataloğunda listelenmediğinden söz ediyor.

Bypass nasıl çalışıyor

Duyuruda açıklandığı gibi Java'nın Secure Socket Extension'ı sertifika zincirlerini paketle birlikte gelen cacerts keystore'u üzerinden doğrularken, Java 11 ve sonrasında blocked.certs, Java 8'de ise blacklisted.certs olan ayrı bir deny-list ele geçirildiği bilinen sertifikaları reddetmek için tasarlanmış. Sorun şu ki Java, çevrimiçi iptal kontrolünü (OCSP ve CRL) varsayılan olarak kapalı tutuyor.

Ekim 2026 blocklist güncellemesinden önceki sürümlerde 16 ele geçirilmiş ara CA'nın hiçbiri bu deny-list'te yer almıyor; dolayısıyla sahte bir sertifika ile başarılı bir handshake arasında hiçbir şey yok. Bir Java istemcisi ile sunucusu arasına konumlanan kimliği doğrulanmamış bir saldırgan, şifreli trafiği aktarım sırasında okuyup değiştirebilir ya da kod imzası doğrulamasını atlayabilir ve uygulama hiçbir hata görmez.

Etkilenen sürümler

Rapor Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition ve OpenJDK'nın yanı sıra Eclipse Temurin, Red Hat OpenJDK, Amazon Corretto ve Azul Zulu gibi downstream dağıtımları etkilenen olarak listeliyor.

Yamalı Oracle Java SE sürümleri 8u511 ve sonrası, 11.0.33, 17.0.21, 21.0.13 ve 25.0.5'in .0.2 revizyonları ile 27.0.1 olarak belirtiliyor. OpenJDK dağıtımları 25.0.5+8'den itibaren ve güncel blocklist'i içeren ilgili 21.0.13 ile 17.0.21 sürümlerinde yamalı sayılıyor; GraalVM düzeltmeleri ise Oracle'ın bu CVE'ye ilişkin güvenlik duyurusu kapsamında ele alınıyor.

Nasıl giderilir

Duyuru, tam yükseltmelerden manuel geçici çözümlere kadar birkaç yol tarif ediyor:

• Tüm Java kurulumlarını, güncellenmiş blocked.certs veritabanını içeren yamalı bir sürüme yükseltin.
• Yükseltme hemen mümkün değilse, ele geçirilmiş ara CA'ların 16 SHA-256 parmak izini blocked.certs'e (Java 8'de blacklisted.certs'e) ekleyin.
• Deny-list desteklenmiyorsa, etkilenen root alias'larını — emsigneccrootcag3, comodoaaaca, emsignrootcag1 ve emsignrootcag2 — keytool aracıyla cacerts'ten kaldırın.
• Debian ve Ubuntu ana makinelerinde ile JVM keystore'unu sistem güven deposuna bağlayan container imajlarında ca-certificates paketini güncelleyin ve /etc/ssl/certs altında Java güven deposunu yeniden oluşturun.
• Güncellenen güven malzemesinin yüklenmesi için tüm çalışan JVM'leri, uygulama sunucularını ve container servislerini yeniden başlatın, ardından Oracle'ın CheckCerts.java aracıyla ya da topluluk tarayıcılarından biriyle doğrulayın; giderilmiş bir runtime, ele geçirilmiş ara CA'lara dayanan zincirleri bir ValidatorException ile reddetmelidir.

Neden önemli

Bu açık, sertifika doğrulamasının iptal yolununun kadar güçlü olduğunu bir kez daha hatırlatıyor. Java, OCSP ve CRL kontrollerini açıkça etkinleştirilmedikçe atladığından blocklist, bir CA ele geçirilmesine tepki veren fiilen tek mekanizma ve eksik bir kayıt, üçüncü taraf bir ihlali her yamasız JVM'de şeffaf bir TLS bypass'ına dönüştürüyor. Java'nın ayak izi bu yüzeyi devasa kılıyor: uygulama sunucuları, build pipeline'ları, container'lar ve uzun ömürlü cihazlar kendi cacerts'lerini taşıdığından yalnızca işletim sistemini yamamak boşluğu kapatmıyor. Düşük EPSS skoru fırsatçı sömürünün henüz yaygın olmadığına işaret ediyor; ancak Java servisleri hassas trafik taşıyan her kurum için runtime envanterini çıkarmak ve blocklist güncellemesini uygulamak acil eylemdir.