Kembali

2026/10/30

Browser Terlindungi dalam Hitungan Jam. Bagaimana dengan Java di Lingkungan Enterprise? Respons LOGIQ terhadap Insiden Sertifikat eMudhra

Browser memblokir intermediate eMudhra yang disusupi dalam hitungan jam, tetapi tiap JDK punya trust store sendiri. Rilis Azul dan BellSoft, langkah LOGIQ, dan yang perlu dicek.

Poin-poin penting

  • Pada 17 Oktober 2026, Mozilla menerima laporan bahwa kunci privat dari delapan sertifikat CA intermediate milik eMudhra telah disusupi. Browser memblokirnya dalam hitungan jam hingga hari. eMudhra menyatakan tidak mengetahui adanya bukti bahwa kunci tersebut telah dieksploitasi.
  • Java tidak menggunakan keputusan kepercayaan (trust) dari browser maupun sistem operasi. Setiap JDK, serta setiap image kontainer atau aplikasi yang membundelnya, membawa trust store sendiri. Masing-masing perlu diperbarui secara terpisah.
  • Azul merilis dua pembaruan Zulu di luar siklus, pada 21 Oktober dan 24 Oktober. Pembaruan kedua ada karena perbaikan pertama belum cukup, sehingga workaround 21 Oktober tidak lagi memadai jika diterapkan sendirian.
  • BellSoft mencantumkan build Liberica yang sudah diperbaiki untuk Java 8, 11, 17, 21, 25, dan 27. LOGIQ memperoleh build ini melalui kanal dukungan BellSoft kami dan menyediakannya bagi pelanggan kami.
  • Yang perlu dilakukan: temukan setiap runtime Java yang Anda jalankan, periksa vendor dan build yang tepat, beralih ke build perbaikan dari vendor tersebut, uji koneksi TLS Anda, dan terus pantau rilis di luar siklus.

Apa yang terjadi

Pada Sabtu, 17 Oktober 2026, pukul 20:06 UTC, Mozilla menerima laporan bahwa kunci privat dari delapan sertifikat intermediate eMudhra telah disusupi. Mozilla memblokir kedelapan sertifikat tersebut di Firefox melalui OneCRL, daftar pencabutan (revocation list) terpusat miliknya, dan pembaruan itu telah sampai ke pengguna dengan pengaturan standar pada pukul 22:59 UTC, kurang dari tiga jam kemudian. Mozilla mengungkapkan insiden ini secara publik pada 20 Oktober. Mozilla juga merilis versi minor Firefox bagi pengguna yang pengaturannya memblokir pembaruan OneCRL, dan menghapus sertifikat root yang menandatangani intermediate tersebut dari trust store NSS.

Risikonya adalah pemalsuan sertifikat. Siapa pun yang memegang salah satu kunci ini dapat menerbitkan sertifikat HTTPS untuk situs yang tidak mereka kendalikan. Jika mereka juga dapat menyusup di antara klien dan situs tersebut, mereka dapat menyamar sebagai situs itu serta membaca atau mengubah lalu lintasnya.

Sejauh ini tidak ada bukti bahwa hal tersebut terjadi. Dalam pernyataan insidennya, eMudhra menyatakan bahwa kedelapan intermediate itu dicabut pada 18 Oktober, bahwa tidak satu pun di antaranya pernah menerbitkan sertifikat end-entity, dan bahwa eMudhra “tidak mengetahui adanya bukti bahwa kunci lemah tersebut telah dipulihkan atau dieksploitasi oleh siapa pun sebelum masalah ini diungkapkan.” eMudhra menyebut penyebabnya adalah kunci lemah yang dihasilkan dalam key ceremony tahun 2025. eMudhra menyatakan belum memastikan akar penyebab yang sebenarnya, dan investigasinya masih berlangsung. Program root browser mencabut kepercayaan terhadap root eMudhra di atas intermediate ini sebagai langkah pencegahan.

Jadi, artikel ini membahas penutupan jendela keterpaparan, bukan serangan yang sudah terkonfirmasi.

Mengapa Java memerlukan perbaikan sendiri

Browser dan sistem operasi memiliki mekanisme otomatis untuk berhenti memercayai suatu otoritas sertifikat, dan mekanisme itu digunakan dengan cepat. Menurut uraian Azul tentang insiden ini, Chrome memblokir sertifikat tersebut pada hari yang sama, Apple pada 19 Oktober, dan Microsoft pada 20 Oktober.

Java tidak mewarisi satu pun dari langkah ini. Sebuah JDK menentukan sertifikat mana yang dipercaya berdasarkan file-filenya sendiri:

  • Trust store sendiri. Setiap JDK menyertakan file cacerts sendiri. Memperbarui bundel sertifikat sistem operasi, atau me-restart browser, tidak mengubahnya.
  • Tidak ada pemeriksaan pencabutan secara default. Seperti dinyatakan dalam dokumentasi Azul, Java memercayai sertifikat root yang menjadi ujung rantai intermediate ini dan “tidak memeriksa pencabutan secara default.” Pencabutan intermediate oleh eMudhra, dengan sendirinya, tidak melindungi klien Java.
  • Banyak salinan. Sebuah server dapat menjalankan JDK sistem, JDK yang dibundel di dalam aplikasi, runtime jlink, dan beberapa image kontainer, masing-masing dengan salinan trust store sendiri. Setiap salinan tetap terpapar hingga diperbarui atau di-build ulang.

Jadi, layanan Java yang melakukan panggilan TLS keluar masih dapat menerima sertifikat palsu meskipun semua browser di gedung yang sama sudah terlindungi. Celah inilah yang dibahas artikel ini.

Dua pembaruan darurat dari Azul

Azul merilis dua pembaruan di luar siklus untuk Azul Zulu setelah rilis kuartalan Oktober:

  • 21 Oktober: pembaruan di luar siklus pertama menambahkan kedelapan intermediate yang disusupi ke daftar blokir JDK (blocked.certs di JDK 11 dan yang lebih baru, blacklisted.certs di versi yang lebih lama). Pembaruan ini mencakup Zulu 27, 25, 21, 17, 11, 8, 7, dan 6. Daftar CVE Azul mencatatnya sebagai CVE-2026-91403. Untuk runtime yang tidak dapat segera diperbarui, Azul juga menerbitkan workaround manual yang mengganti file daftar blokir.
  • 24 Oktober: Azul menemukan bahwa daftar blokir tidak sepenuhnya menutup masalah. Pembaruan di luar siklus kedua memperbaiki CVE-2026-114820 (JSSE, skor dasar 9.1) dengan menghapus sertifikat CA tertentu dari cacerts sepenuhnya. Pada saat artikel ini ditulis, build ini tersedia untuk lini CPU Azul yang hanya berisi perbaikan keamanan, baik pada basis CPU Oktober 2026 (misalnya Zulu 21.53.114, 17.69.114, 11.91.114, dan 8.97.0.112) maupun pada basis CPU Juli 2026. Azul menyatakan build PSU “kemungkinan akan” menyusul dalam pembaruan terpisah.

Pembaruan 24 Oktober mengubah rekomendasi. Halaman workaround Azul kini memperingatkan bahwa workaround tersebut “tidak lagi sepenuhnya mengatasi masalah,” dan Azul meminta semua pelanggan memperbarui ke rilis terbaru. Jika Anda sudah menerapkan pembaruan 21 Oktober atau workaround tersebut, Anda tetap memerlukan build 24 Oktober. Dalam tulisannya sendiri, Azul menyatakan bahwa dibutuhkan sekitar 12 jam sejak keputusan untuk melakukan respin hingga build khusus keamanan sampai di tangan pelanggan.

Apa yang dirilis BellSoft untuk Liberica JDK

BellSoft menerbitkan rilis Liberica JDK Oktober 2026 regulernya pada 21 Oktober. Rilis kuartalan tersebut mencantumkan 52 CVE yang diperbaiki dan menyertakan build CPU untuk Java 6 dan 7 (6u521 dan 7u521). Catatan rilisnya tidak membahas masalah eMudhra.

BellSoft membahas eMudhra dalam panduan terpisah, “Distrusting compromised eMudhra intermediates in Java” (terakhir diperbarui 27 Oktober). Panduan itu mencantumkan build perbaikan sebagai Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 dan 27.0.1.0.3+5. Untuk sistem yang belum dapat diperbarui, panduan tersebut memberikan mitigasi sementara: hapus root yang terdampak dari trust store. Panduan itu memperingatkan bahwa langkah ini dapat merusak rantai sertifikat yang sah dan harus diuji terlebih dahulu.

Ada dua hal penting saat Anda membandingkan vendor:

  • Daftar CVE-nya tidak sama. Azul dan BellSoft masing-masing menerbitkan daftar CVE sendiri untuk siklus Oktober, dan jumlah serta catatannya berbeda. Dua ID CVE Azul di atas berasal dari catatan Azul. Panduan BellSoft tidak menyebutkannya. Periksa catatan rilis vendor Anda sendiri untuk mengetahui perbaikan yang tepat di build Anda, dan jangan berasumsi bahwa daftar dari satu vendor berlaku untuk JDK vendor lain.
  • Java 6 dan 7 tidak ada dalam daftar eMudhra BellSoft. Build Java 6 dan 7 terbaru dari BellSoft tersedia, tetapi daftar build perbaikan dalam panduan eMudhra-nya dimulai dari Java 8. Jika Anda menjalankan Liberica 6 atau 7, tanyakan apakah build Anda mencakup perubahan trust store sebelum Anda mengandalkannya, atau terapkan mitigasi dari vendor. Azul mencantumkan build 24 Oktober untuk Zulu 6 dan 7.

Respons LOGIQ

Kami mendistribusikan build Java dari BellSoft dan Azul kepada pelanggan kami dan membantu mereka bermigrasi dari versi Oracle JDK yang lebih lama. Berikut langkah yang telah kami lakukan, beserta status setiap item pada saat artikel ini ditulis (29 Oktober).

Selesai

  • 21–22 Oktober: pemberitahuan vendor ditinjau. Kami menerima dan meninjau pemberitahuan di luar siklus Azul tanggal 21 Oktober dan pemberitahuan rilis Oktober 2026 dari BellSoft. Pada hari yang sama, kami membuka tugas pengunduhan dan repositori untuk kedua vendor. Kami menangani kedua rilis secara terpisah dan tidak berasumsi bahwa rilis kuartalan BellSoft berisi perbaikan eMudhra yang sama dengan rilis Azul.
  • 23 Oktober: build kuartalan Liberica disiapkan. Kami mengunduh build Liberica JDK Oktober 2026 dari portal dukungan BellSoft dan menambahkannya ke repositori tempat pelanggan kami mengunduh.
  • 24–25 Oktober: pembaruan Azul kedua dipantau. Kami menindaklanjuti pemberitahuan Azul tanggal 24 Oktober, termasuk sarannya untuk memperbarui meskipun build 21 Oktober sudah terpasang.
  • 27–28 Oktober: build Liberica perbaikan diperoleh melalui BellSoft. Melalui hubungan dukungan komersial kami, kami meminta BellSoft menyediakan build terbaru di portal dukungan kami. BellSoft mengunggahnya pada 28 Oktober, termasuk build perbaikan untuk Java 8, 11, 17, 21, 25, dan 27 serta build Java 6 dan 7 terbaru. Sebagian pelanggan masih memerlukan Java 8 32-bit, sehingga kami juga meminta BellSoft menambahkan installer 8u513+9 32-bit untuk Windows dan Linux ke portal kami. BellSoft menambahkannya pada hari yang sama.
  • 28–29 Oktober: repositori dan pemetaan migrasi diperbarui. Kami menambahkan build ini ke repositori unduhan pelanggan dan memperbarui panduan migrasi Oracle JDK ke Liberica agar merujuk ke build tersebut, dengan engineer kedua meninjau pembaruan itu.

Pelanggan Azul Zulu

Build Azul tanggal 21 Oktober dan 24 Oktober tersedia bagi pelanggan berlangganan Azul melalui Azul. Build yang tepat bergantung pada versi Java Anda, apakah Anda menggunakan lini CPU atau PSU, dan basis mana (Oktober atau Juli) yang Anda gunakan. Periksa catatan rilis Azul untuk build Anda yang tepat, atau hubungi kami dan kami akan membantu Anda mengidentifikasinya.

Java 6 dan 7 lama

Sebagian pelanggan masih menjalankan Java 6 atau 7, sering kali pada aplikasi yang tidak dapat dimigrasikan dengan cepat. Oracle tidak lagi menyediakan pembaruan publik untuk versi ini, tetapi bukan berarti tidak ada pilihan. Kami membantu pelanggan bermigrasi dari build Oracle JDK 6 dan 7 lama ke build Liberica JDK 6 dan 7 terbaru, dan build Oktober 2026 dari BellSoft untuk kedua versi tersebut tersedia bagi kami melalui portal dukungan BellSoft. Jika perbaikan atau paket yang kami perlukan untuk versi ini tidak tersedia, kami mengeskalasinya ke BellSoft melalui kanal dukungan komersial kami. Untuk insiden ini, lihat catatan di atas: pastikan build Java 6 atau 7 Anda mencakup perubahan trust store terkait eMudhra sebelum Anda mengandalkannya.

Yang perlu Anda lakukan sekarang

1. Temukan setiap runtime Java

Data setiap tempat Java berjalan, bukan hanya JDK sistem. Ini mencakup application server, runtime yang dibundel di dalam produk vendor, image jlink, agen build CI, dan setiap image kontainer. Di Linux, perintah berikut menemukan binary Java pada sebuah host:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

Untuk image kontainer, jalankan pemeriksaan di dalam image, misalnya docker run --rm --entrypoint java <image> -version.

2. Periksa vendor dan build yang tepat

Versi mayor saja tidak cukup. Anda memerlukan vendor dan nomor build lengkap untuk dicocokkan dengan daftar build perbaikan dari vendor:

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

Sebagai indikator cepat, Anda juga dapat menampilkan daftar root eMudhra (emSign) di trust store sebuah runtime:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

Dalam pengujian kami dengan image kontainer publik BellSoft, build Liberica 21.0.10 yang lebih lama menampilkan lima root emSign, sedangkan build perbaikan 21.0.13.0.3+5 dan 8u513 tidak menampilkan satu pun. Hasil kosong adalah pertanda baik, tetapi bukan bukti. Perbaikan Azul 21 Oktober, misalnya, memblokir intermediate tanpa menghapus root. Nomor build adalah pemeriksaan yang andal. Artikel kami sebelumnya tentang pemeriksaan truststore Java membahas pemeriksaan yang lebih mendetail.

3. Dapatkan patch terbaru yang berlaku

  • Azul Zulu: beralih ke build di luar siklus 24 Oktober untuk lini Anda (CPU atau PSU, basis Oktober atau Juli), meskipun Anda sudah memasang build 21 Oktober atau menerapkan workaround. Jika Anda menggunakan build PSU, pantau rilis PSU lanjutan dari Azul.
  • Liberica JDK: beralih ke build perbaikan yang dicantumkan oleh BellSoft (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5).
  • Vendor lain dan runtime yang dibundel: periksa advisory dari vendor tersebut. JDK di dalam produk pihak ketiga diperbarui oleh vendor produk itu, bukan oleh pembaruan OS Anda.
  • Kontainer: build ulang image di atas base image yang sudah diperbaiki, lalu deploy ulang. Menambal kontainer yang sedang berjalan tidak mengubah image-nya.

4. Validasi TLS sebelum dan selama rollout

Menghapus root dari trust store dapat memutus koneksi yang sah, misalnya ke situs yang masih menggunakan sertifikat dengan rantai ke root eMudhra yang dihapus. eMudhra menyatakan sedang menerbitkan ulang sertifikat pelanggan yang terdampak dari hierarki CA alternatif. Sebelum rollout secara luas, uji koneksi TLS keluar yang diandalkan aplikasi Anda, terutama ke mitra atau layanan yang mungkin menggunakan sertifikat eMudhra. Lakukan rollout secara bertahap, restart proses Java agar memuat trust store yang baru, lalu pastikan versi yang berjalan sesudahnya.

5. Pantau rilis di luar siklus

Insiden ini menghasilkan dua rilis Java darurat dalam empat hari, dan mungkin akan ada lagi, seperti build PSU dari Azul. Berlanggananlah pemberitahuan keamanan dari vendor Anda, periksa halaman rilis mereka secara langsung alih-alih hanya mengandalkan email, dan rencanakan pembaruan Java di luar jadwal kuartalan.

Pelajarannya

Pengguna Firefox terlindungi dalam hitungan jam karena browser memiliki trust store sendiri dan cara otomatis untuk memperbaruinya. Java di lingkungan enterprise memiliki banyak trust store, tidak ada pemeriksaan pencabutan secara default, dan pembaruannya menunggu seseorang untuk memasangnya. Menutup celah ini membutuhkan inventaris yang akurat, nomor build yang tepat, akses cepat ke build vendor, dan proses yang tidak menunggu patch kuartalan berikutnya. Jika Anda memerlukan bantuan untuk menemukan atau memperbarui runtime Java di lingkungan Anda, hubungi LOGIQ.

Referensi