Java Güvenlik Açığı 2026: CVE-2026-91403 ve CVE-2026-114820

Son güncelleme: 26 Ekim 2026

Kısa cevap: Oracle 21 Ekim 2026'da CVE-2026-91403 uyarısını yayımladı. CVSS 3.1 puanı 9,1. JDK güven deposu, özel anahtarları ele geçmiş eMudhra ara sertifikalarını tanımaya devam ediyordu. 24 Ekimde CVE-2026-114820 aynı puanla geldi ve 21 Ekim derlemelerini etkilenen listeye aldı. İkinci uyarı kök sertifikaların depodan çıkarılmasını hedefliyor. java -version çıktısındaki 21.0.13, b32 ile b33 ayrımını göstermez. Bu kayıt uzaktan kod çalıştırma açığı değildir. Risk, dışarı TLS çağrısı yapan Java sürecindedir.

Aynı hafta PHP tarafında da CVSS 9,2 puanlı iki açık kapanmıştı. Ayrıntı PHP güvenlik açığı yazısında. Node.js'in 21 Ekim paketindeki Brotli kaydı da ayrı yazıda: CVE-2026-111497. Puanın tek başına sıra belirlemediğini yama önceliklendirme notunda işlemiştim. Burada 9,1, en kötü durumda gizlilik ve bütünlük etkisinin yüksek olduğunu söyler. Kodun sunucuda kendiliğinden çalışacağı anlamına gelmez.

Tarayıcı düzeldi, JDK duruyor

17 Ekim 2026 akşamından itibaren tarayıcı üreticileri, eMudhra'ya ait sekiz ara sertifika yetkilisini engellemeye başladı. Bu ara sertifikaların özel anahtarları ele geçmiş durumda. Anahtarı elinde tutan biri, o zincire bağlanan ve herhangi bir alan adı için geçerli görünen bir sertifika üretebiliyor. Chrome, Mozilla, Apple ve Microsoft kendi güven listelerini 17 ile 20 Ekim arasında güncelledi.

JDK bu listeleri okumaz. Java'nın TLS yığını JSSE, kurulumla gelen cacerts deposuna bakar. İptal denetimi varsayılan olarak kapalıdır. Sertifika şeffaflığı da zorunlu değildir. Masaüstündeki Chrome uyarısı kalkmış olsa bile aynı gün çalışan bir Java süreci eski zinciri kabul etmeye devam eder. Sunucudaki JVM, geliştiricinin dizüstündeki tarayıcı deposundan habersizdir.

Oracle 20 Ekimde planlı kritik yamasını çıkardı. Ertesi gün bu iş için ayrı bir güvenlik uyarısı gerekti. Numara CVE-2026-91403. 24 Ekimde ikinci uyarı, CVE-2026-114820, köklerin depodan silinmesini hedefledi. İki uyarı da aynı olayı kapatır. Birincisi ara sertifikayı güvensiz sayar. İkincisi, o ara sertifikaların dayandığı kökleri kaldırır. İkisini de kurmadan "Ekim Java yaması geçti" demek erken olur.

Node.js aynı 21 Ekimde kendi gömülü sertifika deposunu da yeniledi. O depo JDK dosyası değildir. Elasticsearch, Jenkins, Tomcat ya da bir Spring hizmetinin içindeki Java, Node.js sürümü yükselince yerinde kalır. Tersi de geçerlidir. Bu yazı yalnızca JDK tarafını anlatır.

CVE-2026-91403 neyi değiştiriyor?

Oracle'ın 21 Ekim risk matrisinde bileşen JSSE. Protokol alanı birden fazla protokolü kapsıyor. Saldırı ağ üzerinden, kimlik doğrulaması olmadan yapılabiliyor. CVSS 3.1 taban puanı 9,1. Vektör CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Gizlilik ve bütünlük yüksek. Erişilebilirlik etkisi yok. Matris kod çalıştırmadan söz etmiyor. Sosyal medyada bu kayda "RCE" denmesi, Oracle'ın metniyle örtüşmez.

Etkilenen desteklenen sürümler şöyle:

Oracle, destek dışındaki daha eski sürümlerin de büyük olasılıkla etkilendiğini ve desteklenen hatta geçilmesi gerektiğini yazıyor. 20 Ekimde kurulan planlı yama bu listede. O kurulum bu açığı kapatmıyor. Liste, "yalnızca bu sürümler" diye okunmamalı. Daha eski 8, 11, 17 ve 21 derlemeleri de aynı depoyu taşıyor olabilir. Destek penceresi dışındaki sürüm için Oracle bu uyarıda ayrı yama dosyası vermez.

Saldırının koşulu, Java sürecinin konuştuğu sunucunun önüne geçebilmek. Ağ kesiti, DNS yanıtı ya da vekil sunucu buna örnek. Saldırgan, hedefin alan adı için ürettiği sertifikayı JSSE'ye gösterir. Depo o zincire güveniyorsa uygulama karşı tarafı gerçek sunucu sanır. Giden istekteki belirteçler, gövdeler ve dönen yanıt okunabilir ve değiştirilebilir. Yol üstüne geçmek, tek bir HTTP isteği göndermekten daha pahalı bir konumdur. Bu yüzden kayıt, herkese açık bir formun tek başına yeterli olduğu açıklardan ayrılır. Konum bir kez varsa devamı, güven deposu o zinciri tanıdığı sürece kolaydır.

Oracle, imzalı JAR doğrulamasında da iptal denetimi istiyor. Kod imzalama zinciri aynı olayın parçası. Korumalı alanda çalışan Java Web Start uygulamaları ve applet'ler de notta geçiyor. Günümüzde applet nadir. Giden TLS çağrısı yapan hizmet ise her envanterde var. Oracle'ın kendi notu, açığın JSSE API'lerine veri veren bir hizmet üzerinden kullanılabildiğini de yazar.

Kimi etkiler, kimi etkilemez?

Risk, TLS istemcisi olan Java sürecindedir. Başka bir API'ye, ödeme uç noktasına, paket deposuna, lisans sunucusuna veya mesaj kuyruğuna HTTPS ile giden her süreç bu tanımın içine girer. Maven ve Gradle indirme sırasında aynı depoyu kullanır. Derleme aracının JDK'sı üretimdeki JDK'dan farklı olabilir. İkisi de sayılır. CI aracısının imajı yeşil diye üretim imajının yenilendiği varsayılmaz.

Yalnızca gelen bağlantıyı kendi sertifikasıyla karşılayan bir sunucu, o el sıkışmasında istemci değildir. Tarayıcı, sunucunun sertifikasını kendi deposuyla doğrular. Bu senaryo 9,1'lik kaydın tarif ettiği JSSE istemci yolu değildir. Aynı sürecin dışarı çağrı yaptığı anda konu yeniden açılır. Sağlık kontrolü, webhook, e-posta geçidi, bulut metadata adresi ya da "lisansı doğrula" çağrısı yeter. İstemci sertifikasını JDK deposundaki köklere göre kabul eden bir hizmet de kapsamdadır. Orada sahte bir istemci sertifikası, içeri giren tarafı taklit edebilir.

Envanterde sık unutulan kopyalar şunlar:

• Jenkins, Keycloak, Elasticsearch ve Kafka gibi ürünlerin yanında gelen JRE.
• Android Studio, IntelliJ ve benzeri IDE paketlerinin içindeki runtime.
• SDKMAN, jenv, Homebrew ve Coursier ile kullanıcı dizinine inen ikinci JDK.
• Konteyner imajının derleme aşaması ile çalışma aşamasının ayrı Java'sı.
• Windows hizmetinin PATH'i ile sizin açtığınız terminalin PATH'i.

İşletim sisteminin "Java güncellendi" satırı bu kopyaları değiştirmez. Her biri kendi JAVA_HOME değerinden okunur.

CVE-2026-114820: ilk yama listeden düşmedi

24 Ekim uyarısı da CVSS 3.1 ile 9,1. Bileşen yine JSSE. Vektör aynı. Metin, güncellemenin eMudhra ile ilişkili kök sertifikaları kaldırdığını söylüyor. Etkilenen liste, bir önceki uyarının düzelttiği derlemeler:

21 Ekimde kurulan .0.2 derlemesi, 24 Ekim kaydında etkilenen sürümdür. Ara sertifikayı engellemek ile kökü depodan silmek aynı iş değildir. Scala ekibinin 24 Ekim güncellemesinde aktardığı Sonatype incelemesi, yalnızca blocked.certs listesine yazılan parmak izinin, sertifikanın yeniden kodlanmış bir kopyasında aşılabildiğini gösteriyor. Kök durdukça zincir başka bir kodlamayla yeniden güvenilir hale gelebiliyor. İkinci uyarının gerekçesi bu. Parmak izi listesini tek başına kalıcı çözüm saymayın.

ops.java yayın matrisi Ekim 2026 sütununda bir sonraki Oracle derlemelerini de gösteriyor: 8u511b33, 11.0.33.0.3, 17.0.21.0.3, 21.0.13.0.3, 25.0.5.0.3 ve 27.0.1.0.3. Kuracağınız dosyayı bu tabloya ezberden bağlamak yerine Oracle'ın yama belgesindeki en yeni derlemeyle karşılaştırın. Matris sürümün çıktığını gösterir. İndirdiğiniz arşivin o derleme olduğunu garanti etmez. GraalVM için de aynı iki uyarıdaki sürüm satırını okuyun. Enterprise Edition 21.3.20.0.2, ikinci uyarıda etkilenen listededir.

java -version çoğu kurulumda 21.0.13 yazar. b32 ile b33 bu satırda kaybolur. Derleme, özelliklerden okunur.

java -XshowSettings:properties -version

Çıktıda java.runtime.version ve java.vendor satırlarına bakın. Aynı makinede birden fazla JDK varsa komut, PATH'teki ilk ikiliyi gösterir. Hizmetin kullandığı JAVA_HOME ayrı sorulur. Windows hizmetinde bu değer, hizmetin ortamından gelir. Linux'ta systemd biriminin Environment= satırı ya da betiğin başındaki export geçerlidir. Terminalde gördüğünüz sürüm, gece çalışan işin sürümü olmayabilir.

Güven deposu nereden geliyor?

Kurulumun kaynağı, düzeltmenin adresini değiştirir.

Temurin imajının içinde apt upgrade ca-certificates çalıştırmak, JDK'nın kendi cacerts dosyasını silmez. USE_SYSTEM_CA_CERTS=1 sistem köklerini üste ekler. Eski kökü çıkarmak bu anahtarın işi değildir. Azul 21 Ekimde yeniden derleme yayımladı. Temurin ve Corretto'nun ekim ortasındaki durumu üreticiye göre değişiyordu. Sürüm numarasını "Ekim yaması" diye etiketlemek yetmez. Aşağıdaki takma adlar duruyorsa depo hâlâ riskli kabul edilir. Üretici notu yoksa Oracle'ın geçici adımı uygulanır ve not çıktığında asıl derlemeye geçilir.

Dağıtım paketinde de bir tuzak vardır. Bazı OpenJDK paketleri işletim sisteminin deposunu kullanır, bazıları kendi cacerts kopyasını taşır. Paket notunu okumadan ca-certificates güncellemesini yeterli saymayın. Güncellemeden sonra aynı keytool -list komutunu o paketin JAVA_HOME değeriyle yeniden çalıştırın.

Güncellemeyi hemen kuramazsanız

Oracle'ın ops.java/emudhra sayfası iki geçici yol veriyor. Sayfanın tarihi 24 Ekim 2026. Birincisi, yedekten sonra dört kökü silmek. JDK 11 ve sonrasında:

keytool -delete -cacerts -alias "emsignrootcag1 [jdk]"
keytool -delete -cacerts -alias "emsignrootcag2 [jdk]"
keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

JDK 8'de depo yolu farklıdır. Oracle'ın komutları şöyle:

keytool -delete -keystore "$JDK_HOME/jre/lib/security/cacerts" -alias "emsignrootcag1 [jdk]"
keytool -delete -keystore "$JDK_HOME/jre/lib/security/cacerts" -alias "emsignrootcag2 [jdk]"
keytool -delete -keystore "$JDK_HOME/jre/lib/security/cacerts" -alias "emsigneccrootcag3 [jdk]"
keytool -delete -keystore "$JDK_HOME/jre/lib/security/cacerts" -alias "comodoaaaca [jdk]"

Silmeden önce cacerts dosyasının kopyasını alın. JDK 11 ve sonrasında dosya $JDK_HOME/lib/security/cacerts altındadır. Dokunulmamış bir deponun parolası changeit olur. Parola değiştirildiyse kurumun kendi parolası sorulur. Komut her kurulum için ayrı çalışır. Canlı süreç, dosya değişince eski depoyu bellekte tutmaya devam eder. JVM yeniden başlatılır. Konteynerde yapılan silme, imaj yeniden kurulunca kaybolur. Kalıcı düzeltme imajın içine yazılır. Birden fazla replica varsa hepsi aynı imajdan kalkmalıdır. Biri eski imajda kalırsa o kopya zinciri tanımaya devam eder.

İkinci yol iptal denetimini açmaktır. TLS kullanan uygulamanın komut satırına şu iki özellik eklenir:

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

El sıkışma, sertifika yetkilisinin iptal listesine ulaşamazsa başarısız olur. Ağda bu adreslere çıkış yoksa uygulama durur. Bunu üretimde açmadan önce aynı yolda bir deneme yapın. İmzalı JAR için JDK 17 ve sonrasında Oracle jarsigner -verify -revcheck -strict kullanımını yazıyor. Web Start tarafında, JDK 8'de güvenlik düzeyinin Very High yapılması öneriliyor. High ayarı, iptal durumu öğrenilemezse kullanıcıya sorup devam edebiliyor.

Kontrol için aynı sayfadaki CheckCerts.java programı JDK 8 ve sonrasında çalışıyor. Takma adları kendiniz de listeleyebilirsiniz:

keytool -list -cacerts | grep -Ei 'emsign|comodoaaaca'

Windows'ta grep yoksa findstr /I "emsign comodoaaaca" aynı işi görür. Satır dönüyorsa o çalışma zamanı henüz temizlenmemiş demektir. Satır dönmemesi, başka bir JAVA_HOME altındaki ikinci kopyayı temizlemez.

Yeni derleme kurumun kendi iç kökünü de keserse eksik kök elle eklenir. eMudhra takma adları geri yüklenmez. "Sertifika hatası aldı, depoyu eski haline döndürelim" refleksi olayı geri getirir. Eksik olan, kurumun kendi köküdür. Dört eMudhra takma adı değildir.

Kayıt tutmak, yamadan sonra da işe yarar. Hangi makinede hangi JAVA_HOME, hangi satıcı ve hangi java.runtime.version kaldığını bir tabloya yazın. Üç gün sonra ikinci bir uyarı gelirse, 21 Ekimde bitmiş sandığınız satırlar bu tablodan okunur. Tablo yoksa aynı envanter ikinci kez yürüyerek çıkar. eMudhra takma adının silindiği saat de satıra eklenir. Böylece "kim, hangi dosyayı, yeniden başlatmadan önce mi sildi" sorusu kayıttan cevaplanır.

Bu hafta sıra

1. Her JDK için satıcı, java.runtime.version ve dört takma adın durup durmadığı yazılır. IDE ve arama motoru gibi gömülü JRE'ler satıra eklenir.
2. Oracle'da 24 Ekim uyarısından sonraki derleme kurulur. Diğer satıcılarda o satıcının eMudhra notu okunur. Not yoksa kökler yukarıdaki komutlarla silinir ve süreç yeniden başlatılır.
3. Dağıtım paketinde ca-certificates güncellenir. Bu adım, yanında duran Temurin kurulumunu temizlemez.
4. Derleme imajı ile çalışma imajı ayrı kontrol edilir.
5. Dışarı HTTPS çağıran hizmetler aynı gün ele alınır. Yalnızca kendi sertifikasıyla içerik sunan ve dışarı çıkmayan işler haftanın içine yayılabilir.

Node.js tarafının kendi sürüm numarası vardır. Onu bu listenin yerine saymayın. O yazı ayrı duruyor.

Sık sorulan sorular

java -version 21.0.13 diyorsa güvende miyim?

Hayır. 21.0.13, 21.0.13.0.2 ve sonraki derleme bu çıktıda aynı görünebilir. java.runtime.version satırı ve keytool -list sonucu birlikte okunur.

Tarayıcı güncel diye Java da güncel midir?

Hayır. Tarayıcının engellediği zincir, JDK deposunda durmaya devam eder. Masaüstündeki Chrome sürümü sunucudaki JVM'yi değiştirmez.

Yalnızca sunucu Java'm var, dışarı istek atmıyor. Yine de kurmalı mıyım?

Gelen bağlantıyı kendi sertifikanızla karşılıyorsanız bu kayıt sizi istemci olarak hedeflemez. Envanterde tek bir giden HTTPS çağrısı, arka planda çalışan bir sağlık kontrolü ya da lisans sunucusu bu varsayımı bozar. Depoyu güncellemek, o çağrı eklenmeden önce yapılan iştir.

WAF bu açığı keser mi?

Kayıt, yayınladığınız HTTP arayüzüne gelen bir istek kalıbı değildir. Araya giren taraf, sürecin dışarı açtığı TLS oturumunu hedefler. WAF o oturumun üzerinde durmaz.

21 Ekim derlemesini kurdum. 24 Ekim uyarısı beni yeniden etkiler mi?

Evet, .0.2 derlemeleri ikinci uyarının etkilenen listesindedir. Kökler depoda duruyorsa iş bitmiş sayılmaz.

Kaynaklar

• Oracle Security Alert CVE-2026-91403
• Oracle Security Alert CVE-2026-114820
• CVE-2026-114820 risk matrisi, metin biçimi
• Oracle: eMudhra ara sertifikalarını güvensiz sayma
• JDK yayın matrisi