eMudhra CA anahtarları 1 ile 255 arasında olduğundan sahte sertifikalar üretilebildi; Oracle ikinci bir Java yaması yayımladı

Ne oldu

17 Ekim 2026'da bilinmeyen bir taraf, eMudhra tarafından işletilen sekiz ara sertifika otoritesine ait private key'lerin elinde olduğunu kanıtladı ve onlarla kısa bir mesaj imzaladı: "We have a problem here - Wayne." dev.to'daki ayrıntılı bir yazıya göre sekiz CA'dan altısı Chrome, Firefox, Safari ve Windows tarafından TLS için güvenilir kabul ediliyor, kalan ikisi ise Windows tarafından code signing için güveniliyor. Aynı anahtarlar Sectigo'dan gelen sekiz cross-signature'da da yer alıyor.

Geleneksel anlamda bir şey çalınmadı. Yazı, olay raporundaki Mozilla analizine atıfla, her anahtarın 1 ile 255 arasında bir tam sayı olduğunu açıklıyor — 48 baytın tamamının son bayt hariç sıfır olduğu bir P-384 private key. Public certificate elinde olan herkes 255 adayı neredeyse anında test edebilir; yazıda alıntılanan bir ölçüme göre tam tablonun tamamı 28,7 milisaniye sürüyor. EM OV TLS CA - G3C'ye ait anahtarın 4 sayısı olduğu doğrulanabilir durumda.

Böyle bir anahtara sahip olan herkes herhangi bir hostname için sertifika üretebilir. Tek ek gereksinim, istemci ile sunucu arasındaki ağ yolunda bir konum edinmektir; iptal kontrollerini ve Certificate Transparency'yi atlayan ve kök sertifikalara güvenen istemciler ise sahteciliği tespit etmenin bir yoluna sahip değildir.

Zayıf anahtarlar her kontrolü nasıl geçti

Olay raporundaki eMudhra'nın ön açıklamasına göre anahtarlar 30 Nisan 2025'te bir seremoni sırasında Utimaco donanım güvenlik modüllerinde üretildi. Onaylanmış bir sapma, key wrap ve unwrap testi ekledi. Bu test kodundaki bir hata, HSM içinde ikinci ve daha zayıf bir anahtar çifti üretti; etiketi amaçlanan anahtarınkine benzediğinden zayıf çift, certificate signing request'lerinde sunuldu. Root CA bunları imzaladı ve Sectigo sonucu cross-sign etti.

Aşağı yönlü hiçbir şey itiraz etmedi, çünkü P-384'ün kendisi sağlamdır ve 4 değerindeki bir anahtar matematiksel olarak geçerlidir: herhangi bir anahtar gibi parse edilir, imzalar ve doğrulanır. Format doğrulaması ve sign-and-verify testlerinin tamamı geçti; yazı bunu sorunun neredeyse on sekiz ay fark edilmemesinin nedeni olarak gösteriyor.

Olayın test sunucusunun sunduğu zincir sorunun biçimini gösteriyor: önce bir leaf certificate, ardından EM DV TLS CA - G3B (zayıf ara sertifikalardan biri), sonra emSign Root TLS CA - G3 ve istemcinin trust store'unda kökü emSign ECC Root CA - G3 olan bir zincir. Ara sertifikalar CA:TRUE ve pathlen:0 taşıyor, name constraints ise yok; dolayısıyla sertifikaların kendilerinde hangi hostname'ler için kefil olabileceklerini kısıtlayan bir şey bulunmuyor.

Asıl risk altında olanlar

Tarayıcılar hızlı davrandı: dev.to yazısına göre Chrome ve Firefox saatler içinde, Windows ve Apple cihazları ise günler içinde korunur hale geldi. Açığı tarayıcı dışı TLS oluşturuyor. Güven, TLS protokolünün bir özelliği değildir; her runtime kendi root-certificate dosyasını seçer. İşletim sistemini yamalamak curl'ün dünya görüşünü günceller ama Node için, bir ay önce derlenmiş bir Go binary'si için ya da bir virtualenv içindeki certifi paketi için hiçbir şey yapmaz. Tarayıcı olmayan istemcilerin çoğu varsayılan olarak CRL'leri, OCSP'yi ve Certificate Transparency log'larını kontrol etmez; bu da onları ele geçirilmiş CA'lardan üretilen sertifikalara açık bırakır.

İkinci Java yaması

Yama önerileri hâlâ değişiyor. Oracle, 24 Ekim 2026'da CVE-2026-114820 numaralı ikinci Java yamasını yayımladı; yani daha önce yazılan öneriler — Java build'lerini giderilmiş olarak tanımlayan herhangi bir materyal dahil — güncel değil. 25 Ekim itibarıyla güncel olan yazı, okuyucuları en yeni durum için olay sitesindeki yama listesine yönlendiriyor.

Ne yapmalı

Yazının vardığı çözüm iki kademeli: her runtime'ı trust store'u ile birlikte güncelleyin, ardından bunları gömen her şeyi yeniden derleyin — statik bağlanmış Go binary'leri, container imajları, virtualenv'ler ve paketlenmiş JDK'lar. Özellikle Java için, 24 Ekim'den önce belirtilen herhangi bir yama durumunu güvenilmez olarak kabul edin ve mevcut yama listesiyle yeniden doğrulayın.

Neden önemli

Olay, TLS güveninin bağlantınızın üzerindeki zincirdeki en zayıf anahtar kadar güçlü olduğunu ve trust store'un işletim sistemi yamalarının yaymadığı, runtime başına yapılan bir seçim olduğunu gösteriyor. Ayrıca geleneksel CA kalite güvencesinin sınırlarını ortaya koyuyor: bu kadar zayıf anahtarlar bir buçuk yıl boyunca her format ve imza testini geçti ve ancak biri bunları kamuya açık biçimde kanıtladığında yakalandı. Son olarak, ikinci Oracle CVE'si şunu hatırlatıyor: devam eden bir güvenlik olayı sırasında yama önerilerinin raf ömrü günlerle ölçülür ve tavsiyeler arşivlenmek yerine yeniden kontrol edilmelidir.