Celah Sertifikat eMudhra di Java: CVE-2026-91403, CVE-2026-114820, dan Versi yang Perlu Dipasang

Minggu lalu cukup sibuk bagi tim yang mengelola aplikasi Java. Oracle merilis Critical Patch Update triwulanan pada 20 Oktober 2026. Sehari kemudian, Oracle dan proyek OpenJDK mengeluarkan peringatan darurat untuk CVE-2026-91403 dengan skor 9.1. Lalu pada 24 Oktober muncul CVE-2026-114820, karena perbaikan pertama ternyata belum menutup semua celah. Keduanya bukan bug di kode Java. Sumber masalahnya ada di eMudhra, sebuah certificate authority yang sertifikat intermediate-nya bocor tetapi masih dipercaya oleh JDK. Server yang sudah rajin memasang update Oktober pun bisa saja masih terbuka.

Apa yang Terjadi di eMudhra

eMudhra adalah certificate authority asal Bengaluru, India, yang menjual sertifikat TLS dengan merek emSign. Pada April 2025, perusahaan ini membuat delapan sertifikat intermediate: enam untuk TLS dan dua untuk code signing. Ada kesalahan dalam proses pembuatan kuncinya, sehingga private key kedelapan sertifikat itu sangat lemah. Menurut laporan yang beredar, salah satu kuncinya bahkan bernilai 4. Siapa pun yang berhasil mendapatkan kunci seperti ini bisa menerbitkan sertifikat untuk domain apa saja, dan semua klien yang memercayai rantai sertifikat tersebut akan menerimanya.

Masalah ini terungkap pada akhir pekan 17 Oktober 2026. Chrome memblokir sertifikat intermediate tersebut kurang dari dua jam setelah laporan masuk, Mozilla menyusul malam itu juga, Apple pada 19 Oktober, dan Microsoft pada 20 Oktober. eMudhra mencabut kedelapan sertifikat itu pada 19 Oktober dan menyatakan kunci root mereka tidak terdampak. Chrome menghapus root emSign ECC Root CA G3 mulai 27 Oktober, dan Google meminta pemilik situs yang memakai sertifikat di bawah root itu untuk segera menggantinya.

Browser memperbarui daftar sertifikat tepercayanya secara otomatis. Java tidak. JDK standalone membawa trust store sendiri berupa file bernama cacerts, dan isi file itu hanya berubah ketika JDK diperbarui atau diubah manual oleh administrator.

Dua CVE dalam Empat Hari

CVE kedua muncul karena memblokir delapan sertifikat berdasarkan fingerprint saja ternyata tidak cukup. Kunci lemah yang sama juga sudah di-cross-sign di bawah root milik Sectigo, sehingga rantai lain yang memakai kunci tersebut masih dipercaya. OpenJDK mencatat build .0.2 yang dirilis untuk peringatan pertama, misalnya 25.0.5.0.2 dan 21.0.13.0.2, masih terdampak CVE-2026-114820. Jadi, perbaikan untuk CVE pertama saja belum menutup lubangnya.

Kedua CVE dinilai bisa dieksploitasi lewat jaringan tanpa login dan tanpa interaksi pengguna, dengan dampak tinggi pada kerahasiaan dan integritas data. Syarat utamanya hanya satu: penyerang harus berada di antara aplikasi Java dan server tujuannya. Posisi ini bisa didapat lewat router yang sudah disusupi, Wi-Fi publik, record DNS yang dibajak, atau jaringan tidak tepercaya di sepanjang jalur koneksi. Dari situ, penyerang bisa menyodorkan sertifikat palsu yang diterima Java sebagai sertifikat sah.

Kenapa Tim Backend Perlu Peduli

Bayangan umum soal serangan HTTPS biasanya pengguna browser di Wi-Fi kafe. Untuk Java, skenario yang lebih serius justru layanan backend yang bertindak sebagai klien. Aplikasi Spring Boot yang memanggil payment gateway, API bank, layanan cek resi ekspedisi, atau sistem milik supplier mengirim API key, token, dan data pelanggan lewat TLS. Jika koneksi itu bisa disadap dengan sertifikat yang dipercaya Java, penyerang bisa membaca kredensial tersebut sekaligus mengubah respons yang diterima aplikasi. Hal yang sama berlaku untuk koneksi JDBC lewat TLS, Kafka dan message broker lain, LDAP, pengiriman email lewat SMTP, serta pemanggilan webhook.

Dua dari delapan sertifikat itu adalah sertifikat code signing, sehingga verifikasi tanda tangan file JAR juga ikut terdampak. Tool yang memeriksa tanda tangan JAR bisa saja menerima kode yang ditandatangani dengan sertifikat palsu seolah-olah resmi.

Update Rutin Oktober Tetap Penting

Kasus sertifikat ini membuat Critical Patch Update 20 Oktober agak tenggelam, padahal isinya cukup banyak: 55 perbaikan untuk Java SE, 49 di antaranya bisa dieksploitasi dari jarak jauh tanpa autentikasi. Tidak ada yang skornya di atas 7.5. Dua yang tertinggi adalah CVE-2026-43660 di JavaFX (WebKitGTK), yang butuh interaksi pengguna, dan CVE-2026-91484 di Java plugin, yang butuh akses lokal. Belum ada laporan eksploitasi untuk celah-celah tersebut. Build dasar rilis Oktober adalah 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5, dan 27.0.1. Java 26 sudah habis masa dukungannya pada September 2026 dan tidak mendapat update ini.

Masalahnya, Oracle justru mencantumkan build dasar tersebut sebagai versi yang terdampak CVE-2026-91403. Tim yang sudah update pada 20 Oktober lalu berhenti di situ masih terbuka terhadap celah sertifikat ini.

Build yang Perlu Dipasang

Patokan paling aman datang dari OpenJDK: pasang build yang release notes-nya menyebut JDK-8395690 atau CVE-2026-114820. Penomoran versi berbeda antar vendor, dan build untuk tiap versi Java juga tidak keluar di hari yang sama.

• Oracle JDK: unduh build terbaru untuk versi Java yang Anda pakai, lalu pastikan release notes-nya menyebut CVE-2026-114820. Build yang berakhiran .0.2 baru menutup peringatan pertama.
• Build OpenJDK dari jdk.java.net: versi 27.0.1.0.3 sudah tersedia per 26 Oktober.
• Eclipse Temurin, Amazon Corretto, Microsoft Build of OpenJDK, Azul Zulu, dan Red Hat build of OpenJDK: ikuti release notes masing-masing vendor. Per 26 Oktober, beberapa build Temurin dan paket openjdk versi lama di Homebrew masih tercatat terdampak.
• Java 8: informasi versi untuk Java 8 tidak konsisten antara Oracle dan OpenJDK, jadi berpeganglah pada release notes, bukan hanya pada nomor build.

Paket Linux, Docker, dan Kasus Khusus Debian

Langkah yang perlu diambil bergantung pada dari mana Java mengambil daftar sertifikatnya. Paket OpenJDK di Arch Linux, Fedora, Gentoo, Oracle Linux, dan RHEL membaca trust store milik sistem operasi, jadi memperbarui paket ca-certificates lewat package manager kemungkinan besar sudah cukup. Debian, Ubuntu, dan Devuan berbeda. Karena bug yang sudah lama ada, update ca-certificates dan ca-certificates-java tidak membangun ulang keystore Java. Sebagai root, hapus file /etc/ssl/certs/java/cacerts lalu jalankan update-ca-certificates --fresh.

Paket di FreeBSD dan Homebrew tidak memakai trust store sistem, sehingga paket Java-nya sendiri yang harus diperbarui. Begitu pula image Docker yang dibangun dari JDK standalone, karena file cacerts ikut tersimpan di dalam image. Build ulang image setelah base image merilis tag yang sudah diperbaiki, lalu deploy ulang. Image yang di-build minggu lalu tidak akan berubah dengan sendirinya.

Jangan lupa runtime Java yang tertanam di produk lain. Application server, IDE, agent Jenkins, Elasticsearch, Kafka, dan banyak appliance dari vendor membawa JDK serta cacerts-nya sendiri. Update sistem operasi tidak menyentuh semua itu.

Kalau Belum Bisa Update Hari Ini

OpenJDK menyediakan langkah sementara di openjdk.org/emudhra, termasuk program kecil CheckCerts.java untuk mengecek apakah sebuah runtime masih memercayai rantai sertifikat yang bermasalah. Halaman tersebut tidak lagi menyarankan penggantian file blocked.certs, karena cara itu hanya menangani CVE pertama. Sebagai gantinya, ada dua pilihan.

1. 1Backup file cacerts di setiap instalasi Java. Untuk JDK 11 ke atas, lokasinya di $JDK_HOME/lib/security/cacerts, sedangkan untuk JDK 8 di $JDK_HOME/jre/lib/security/cacerts.
2. 2Hapus empat root dengan keytool -delete -cacerts -alias, masing-masing untuk "emsignrootcag1 [jdk]", "emsignrootcag2 [jdk]", "emsigneccrootcag3 [jdk]", dan "comodoaaaca [jdk]". Di JDK 8, tambahkan opsi -keystore dengan path di atas. Pesan "does not exist" berarti root tersebut memang sudah tidak ada.
3. 3Restart semua proses Java yang memakai instalasi tersebut. JVM yang sedang berjalan tetap memakai trust store yang dimuat saat start.
4. 4Ulangi untuk setiap JDK di server itu, termasuk yang tertanam di software lain.

Pilihan kedua adalah mengaktifkan pengecekan pencabutan sertifikat. Menjalankan Java dengan -Dcom.sun.net.ssl.checkRevocation=true dan -Dcom.sun.security.enableCRLDP=true membuat koneksi TLS menolak sertifikat intermediate eMudhra yang sudah dicabut. Cara ini bergantung pada pengambilan daftar pencabutan lewat jaringan, yang bisa gagal atau menambah latensi, jadi anggap saja sebagai penambal sementara. Untuk file JAR bertanda tangan di JDK 17 ke atas, jarsigner -verify -revcheck -strict melakukan pengecekan yang sama.

Ada satu hal yang perlu diwaspadai, baik saat update maupun saat menghapus root secara manual. AAA Certificate Services adalah root lama yang masih menjadi ujung sebagian rantai sertifikat yang sah. Jika ada API mitra yang masih memakai rantai seperti itu, koneksi dari Java bisa gagal setelah perubahan ini. Uji dulu koneksi keluar ke payment gateway, bank, dan layanan penting lain di staging sebelum dirilis ke production.

Bukan Hanya Java

Semua runtime yang membawa trust store sendiri ikut bergerak. Go merilis versi 1.27.3 dan 1.26.10 untuk masalah yang sama dengan nomor CVE-2026-111943, sementara Python certifi, pip, Electron, dan rustls-webpki juga sudah diperbarui. Rilis keamanan Node.js tanggal 21 Oktober pun ikut memperbarui daftar root certificate bawaannya karena alasan ini. Kalau sistem Anda memakai beberapa bahasa pemrograman sekaligus, periksa setiap runtime satu per satu. Jangan berasumsi satu kali update sistem operasi sudah mencakup semuanya.

Daftar Periksa

1. 1Data semua runtime Java yang dipakai: application server, container, agent CI, dan produk yang membawa JDK sendiri.
2. 2Catat sumber sertifikat masing-masing: file cacerts bawaan JDK atau trust store sistem operasi.
3. 3Pasang build yang release notes-nya menyebut CVE-2026-114820, atau update ca-certificates di distro yang memakai trust store sistem. Di Debian dan Ubuntu, bangun ulang keystore Java seperti dijelaskan di atas.
4. 4Build ulang dan deploy ulang image container, lalu restart semua proses Java.
5. 5Jalankan CheckCerts.java dari openjdk.org/emudhra di setiap runtime untuk memastikan rantai sertifikat yang bermasalah sudah tidak dipercaya.
6. 6Uji koneksi TLS keluar ke layanan pihak ketiga yang penting.
7. 7Masukkan Critical Patch Update berikutnya, yang dijadwalkan 19 Januari 2027, ke jadwal maintenance.

Kejadian seperti ini memperlihatkan pentingnya catatan inventaris runtime. Tim yang tahu di mana saja JDK terpasang bisa menyelesaikan pekerjaan ini dalam satu sore. Tim yang tidak punya catatan itu bisa menghabiskan berhari-hari hanya untuk mencarinya. Jika Anda butuh bantuan mengaudit atau memperbarui layanan Java di server maupun container, tim managed service kami siap membantu.