Klien Ethereum Memperbaiki Kelemahan yang Dapat Mengalihkan Hadiah ETH
Pembaruan Teku dan Besu Menyoroti Pentingnya Keamanan Infrastruktur Eksternal
Klien konsensus Ethereum Teku dan klien eksekusi Besu merilis pembaruan keamanan pada akhir Oktober 2026 untuk menutup kerentanan yang terkait dengan kunci otoritas sertifikat yang dikompromikan dari perusahaan India eMudhra. Kelemahan ini dapat memungkinkan penyerang yang menyadap koneksi HTTPS tertentu untuk menyamar sebagai layanan eksternal yang digunakan oleh validator dan mengalihkan hadiah blok atau mendapatkan tanda tangan sensitif. Para peneliti menemukan bahwa delapan otoritas sertifikat menengah eMudhra memiliki kunci pribadi yang dihasilkan dengan randomisasi tidak memadai, sehingga kunci-kunci tersebut dapat dipulihkan dari sertifikat publik itu sendiri. Karena runtime Java yang digunakan oleh kedua klien tidak memeriksa pencabutan sertifikat secara default, beberapa gambar Docker dan instalasi tetap mempercayai rantai yang terdampak bahkan setelah browser dan sistem operasi utama memblokirnya. Konfigurasi mainnet Teku default yang menghindari endpoint HTTPS tidak terpengaruh, dan pengembang melaporkan tidak ada eksploitasi yang terkonfirmasi.
Patch tersebut menghapus kepercayaan terhadap akar yang terlibat dari gambar Docker yang diperbarui, sementara operator yang menjalankan biner mandiri harus menangani toko kepercayaan Java lokal mereka secara terpisah. Insiden ini menekankan bagaimana ketergantungan pada infrastruktur eksternal dapat menciptakan risiko sempit namun berdampak tinggi bagi operasi staking, bahkan ketika protokol inti tetap aman. Respons cepat dari Teku dan Besu menunjukkan bahwa keragaman klien Ethereum dan praktik keamanan proaktif dapat menahan ancaman terkait sertifikat sebelum memengaruhi imbalan validator secara besar-besaran, asalkan operator menerapkan pembaruan yang tersedia dan meninjau konfigurasi koneksi eksternal mereka.
Kerentanan Randomitas Lemah pada Kunci Menengah eMudhra Menciptakan Materi Privat yang Dapat Dipulihkan
Para peneliti mengidentifikasi masalah tersebut pada 17 Oktober 2026, ketika mereka menentukan bahwa kunci pribadi di balik delapan otoritas sertifikat menengah eMudhra telah dihasilkan dengan entropi yang jauh terlalu rendah. Kunci-kunci tersebut secara efektif dapat dipulihkan dari sertifikat publik, suatu kondisi yang telah ada sejak penciptaannya dalam upacara pembuatan kunci pada April 2025. Enam dari sertifikat menengah tersebut mendukung koneksi TLS, sementara dua lainnya terkait dengan penandatanganan kode. Setelah materi pribadi diketahui, penyerang dapat mengeluarkan sertifikat palsu yang akan diterima sebagai valid oleh perangkat lunak yang masih mempercayai otoritas yang terdampak. eMudhra mencabut sertifikat menengah tersebut pada 18 Oktober. Platform utama merespons dengan cepat: browser dan sistem operasi mulai memblokir sertifikat-sertifikat tersebut antara 17 dan 20 Oktober, dan Microsoft mengeluarkan pembaruan Windows dan Edge lebih lanjut pada 26–27 Oktober yang menghapus akar terkait dari daftar kepercayaannya. Kegagalan kriptografis itu sendiri bukanlah masalah protokol ethereum, namun penting karena Teku dan Besu bergantung pada validasi sertifikat Java untuk semua koneksi HTTPS yang dilakukan node-node mereka. Perilaku default Java yang melewati pemeriksaan pencabutan membuat beberapa instalasi tetap rentan lebih lama daripada lingkungan browser. Kejadian ini oleh karena itu menggambarkan bagaimana kesalahan operasional satu otoritas sertifikat dapat menyebar ke infrastruktur khusus yang bergantung pada toko kepercayaan TLS standar.
Pemulihan kunci tidak memerlukan kriptanalisis yang rumit; ketidakcukupan randomisasi membuat derivasi menjadi mudah setelah sertifikat publik diperiksa. Peringatan Microsoft pada 26 Oktober mengonfirmasi bahwa kunci-kunci tersebut dapat digunakan untuk membuat sertifikat yang tampak berasal dari otoritas terpercaya, berpotensi memungkinkan penyamaran situs web atau layanan. Bagi operator Ethereum, konsekuensi praktisnya adalah bahwa setiap konfigurasi validator yang mengandalkan endpoint HTTPS, node beacon jarak jauh, penandatangan eksternal, pembangun blok, atau relay dapat menerima sertifikat palsu jika runtime Java yang mendasarinya masih mempercayai rantai yang terkompromi. Jaringan peer-to-peer yang digunakan oleh klien Ethereum tetap tidak terpengaruh karena tidak bergantung pada otoritas sertifikat ini. Kombinasi kunci yang dapat dipulihkan dan validasi Java yang tidak mencabut menciptakan jendela di mana penyerang man-in-the-middle yang berada di jalur jaringan dapat menyajikan identitas yang masuk akal kepada perangkat lunak klien. Tim klien merespons dengan menghapus akar yang relevan dari gambar Docker mereka daripada hanya menunggu pembaruan Java dasar, memastikan operator yang mengambil gambar segar menerima toko kepercayaan yang diperkuat. Respons berlapis ini, pencabutan di CA, blokir platform, dan pembaruan gambar khusus klien, membatasi permukaan serangan praktis untuk sebagian besar pengaturan staking.
Bagaimana Sertifikat Palsu Dapat Mengubah Perilaku Usulan Blok dan Penerima Biaya
Peringatan keamanan Teku menguraikan jalur serangan konkret yang menjadi mungkin setelah penyerang dapat menyajikan sertifikat palsu yang diterima oleh klien. Salah satu skenario melibatkan penyamaran node beacon jarak jauh yang digunakan validator untuk koordinasi. Jika koneksi disadap dan sertifikat palsu diterima, validator dapat menerima informasi yang dimanipulasi mengenai blok yang sedang disiapkan untuk diajukan. Dalam kasus tersebut, klien mungkin membuat dan menandatangani blok yang alamat penerima biaya transaksinya mengarah ke akun yang dikendalikan penyerang, bukan alamat yang ditentukan operator. Biaya transaksi dan semua tip prioritas yang termasuk dalam blok kemudian akan mengalir ke penyerang. Peringatan tersebut juga menunjukkan layanan penandatangan eksternal, yang menyimpan kunci validator secara terpisah dan mengembalikan tanda tangan atas permintaan. Penyerang yang mampu menyamar sebagai penandatangan semacam itu dapat memperoleh tanda tangan yang digunakan untuk operasi sensitif, termasuk perubahan yang memengaruhi ke mana hadiah dialihkan. Teku mengklasifikasikan kasus penandatangan eksternal di antara konfigurasi yang lebih serius, meskipun otentikasi TLS timbal balik dalam beberapa pengaturan akan membatasi dampaknya menjadi penolakan layanan daripada kompromi tanda tangan.
Jenis koneksi yang terbuka tambahan meliputi execution clients, block builders, relays, dan layanan yang menyediakan data konfigurasi validator. Dalam setiap kasus, risiko intinya sama: perangkat lunak klien memperlakukan sertifikat yang dipalsukan sebagai sah dan karena itu menerima data atau instruksi yang mengubah konten blok yang diusulkan atau penanganan kunci. Kerentanan ini tidak memberikan akses langsung ke kunci penandatanganan validator dalam operasi normal; sebaliknya, ia merusak integritas layanan eksternal yang dikonsultasikan oleh validator. Karena hadiah dan biaya blok Ethereum dibayarkan sesuai dengan alamat yang tertanam dalam blok yang diusulkan, manipulasi yang berhasil pada saat pengusulan dapat mengalihkan nilai tanpa perlu memindahkan dana yang sudah diperoleh. Tidak ada laporan eksploitasi terhadap jalur-jalur ini, dan instalasi Teku mainnet default yang tidak mengandung URL HTTPS dalam konfigurasinya tetap berada di luar kelompok yang terdampak. Skenario-skenario rinci tetap menjelaskan mengapa tim klien memperlakukan masalah ini sebagai memerlukan pembaruan gambar Docker segera, meskipun protokol dasar dan lapisan peer-to-peer tidak tersentuh.
Teku 26.10.3 Menghapus Akar yang Dikompromikan dari Toko Kepercayaan Docker
Teku merilis versi 26.10.3 pada 27 Oktober 2026, khusus untuk menangani eksposur terkait eMudhra. Catatan rilis menyatakan bahwa gambar Docker tidak lagi mempercayai emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2, atau akar AAA Certificate Services. Akar-akar tersebut telah dihapus oleh OpenJDK setelah otoritas perantara dikompromikan; gambar dasar Eclipse Temurin yang digunakan oleh Teku belum mengintegrasikan perbaikan terkait pada saat rilis klien. Dengan menyediakan gambar yang diperbarui, tim Teku memastikan bahwa operator yang mengambil tag baru menerima runtime Java yang daftar kepercayaannya tidak mencakup materi yang dikompromikan. Peringatan yang menyertai rilis menekankan bahwa node mainnet default tanpa URL HTTPS yang dikonfigurasi tidak memerlukan tindakan apa pun. Eksposur terbatas pada konfigurasi yang secara sengaja terhubung ke endpoint HTTPS jarak jauh untuk koordinasi beacon, penandatanganan eksternal, builder, atau layanan serupa.
Operator yang menjalankan gambar Docker versi lama, termasuk yang ditandai hingga 26.10.2, terus menyediakan runtime yang mempercayai akar yang terdampak. Memperbarui instalasi Java pada host tidak secara otomatis memperbarui runtime di dalam kontainer yang sudah ada, sehingga diperlukan pengunduhan gambar baru. Teku juga mencatat bahwa Java 26 telah mencapai akhir masa dukungan dan tidak akan menerima build yang diperbaiki; operator yang masih menggunakan versi tersebut disarankan untuk bermigrasi ke rilis dukungan jangka panjang saat ini, Java 25, dan menggunakan tag gambar -jdk25 yang sesuai. Rilis ini menggabungkan penghapusan akar sertifikat dengan panduan manajemen versi runtime. Karena perubahan ini terbatas pada trust store gambar Docker, perilaku konsensus dan penanganan kunci validator tetap tidak berubah. Pembaruan ini disajikan sebagai langkah keamanan yang disarankan, bukan sebagai peningkatan konsensus darurat, mencerminkan cakupan sempit dari konfigurasi yang terdampak.
Besu 26.10.2 Menerapkan Penyesuaian Kepercayaan Sertifikat Paralel
Besu, klien lapisan eksekusi yang dipelihara oleh ekosistem yang lebih luas yang sama, merilis versi 26.10.2 pada 26 Oktober 2026, menerapkan penghapusan akar yang sama di gambar Docker-nya. Waktu paralel dan target sertifikat yang identik menunjukkan kesadaran terkoordinasi terhadap insiden eMudhra di seluruh tumpukan klien Ethereum berbasis Java. Klien eksekusi berinteraksi dengan klien konsensus dan layanan eksternal untuk konstruksi payload dan inklusi transaksi; setiap jalur komunikasi HTTPS yang mereka pertahankan tunduk pada aturan validasi sertifikat yang sama yang memengaruhi Teku. Dengan menghapus kepercayaan terhadap otoritas yang dikompromikan dari gambar-gambar tersebut, Besu menutup permukaan serangan yang sesuai bagi operator yang mengandalkan distribusi Docker-nya.
Seperti halnya Teku, pembaruan Besu tidak secara otomatis memperbaiki instalasi biner mandiri yang menggunakan runtime Java yang dikelola secara terpisah. Operator dalam kategori ini harus memeriksa dan memperbarui trust store lokal atau versi Java mereka secara independen. Rilis klien ganda menunjukkan bahwa kedua sisi konsensus dan eksekusi dari stack perangkat lunak node Ethereum mengakui ketergantungan bersama pada penanganan sertifikat Java. Karena banyak validator produksi menjalankan baik klien konsensus seperti Teku maupun klien eksekusi seperti Besu, pembaruan simultan mengurangi kemungkinan bahwa kepercayaan sisa terhadap akar yang dikompromikan tetap ada di salah satu sisi pasangan node. Tidak adanya laporan eksploitasi sebelum rilis menunjukkan bahwa jendela praktisnya terbatas, namun patch terkoordinasi tetap merupakan upaya bijaksana untuk memperkuat sistem terhadap kegagalan kriptografi yang diketahui di luar protokol Ethereum itu sendiri.
Kurangnya Pemeriksaan Revokasi Bawaan Java Memperpanjang Paparan
Detail teknis utama adalah bahwa validasi sertifikat Java tidak memeriksa status pencabutan secara default. Bahkan setelah eMudhra mencabut sertifikat menengah dan setelah platform utama memblokirnya, setiap runtime Java yang masih menyimpan akar atau menengah yang sesuai di trust store-nya akan terus menerima sertifikat yang menghubungkan ke otoritas tersebut. OpenJDK merilis perbaikan yang pertama kali memblokir sertifikat menengah yang terkompromi dan kemudian menghapus empat akar terkait. Namun, gambar Docker yang menyertakan build Temurin atau OpenJDK versi lama tidak secara otomatis menerima perbaikan tersebut. Kesenjangan antara pencabutan tingkat platform dan perilaku runtime Java yang tertanam inilah yang menuntut pembaruan gambar khusus klien.
Untuk operator Ethereum, implikasinya bersifat operasional, bukan teoretis. Sebuah validator yang konfigurasinya mencakup endpoint HTTPS untuk layanan jarak jauh mewarisi keputusan kepercayaan dari runtime Java yang digunakannya. Jika runtime tersebut belum diperbarui atau diganti dengan gambar yang telah diperbaiki, klien tetap bersedia menerima sertifikat palsu. TLS timbal balik atau sertifikat yang dipin dapat mengurangi risiko dalam pengaturan yang dirancang dengan cermat, namun banyak konfigurasi produksi bergantung pada validasi store kepercayaan standar. Rilis Teku dan Besu karenanya menjadi pengingat praktis bahwa perangkat lunak node terkontainerisasi memiliki store sertifikatnya sendiri yang terpisah dari sistem host. Operator yang memperlakukan gambar Docker sebagai kotak hitam yang tidak transparan mungkin mengabaikan detail ini hingga insiden eksternal memaksa pembaruan. Kejadian ini juga menyoroti pentingnya memantau peringatan keamanan Java dari sumber utama saat menjalankan klien Ethereum berbasis Java.
Konfigurasi Mainnet Default Menghindari Permukaan Serangan Utama
Saran Teku secara eksplisit menyatakan bahwa node mainnet default yang tidak mengandung URL HTTPS dalam konfigurasinya tidak terpengaruh dan tidak memerlukan tindakan apa pun. Sebagian besar validator yang menjalankan klien konsensus dan eksekusi yang terlokalisasi secara lokal, tanpa penandatanganan jarak jauh atau endpoint beacon jarak jauh, termasuk dalam kategori ini. Protokol penemuan peer-to-peer dan gossip yang digunakan oleh Ethereum tidak bergantung pada otoritas sertifikat eMudhra, sehingga semakin melindungi pengaturan standar. Risiko terkonsentrasi pada operator yang sengaja memperkenalkan ketergantungan HTTPS eksternal demi kenyamanan operasional, distribusi geografis kunci penandatanganan, atau integrasi dengan layanan pembangunan blok pihak ketiga. Perbedaan ini penting untuk menilai dampak keseluruhan terhadap jaringan. Karena sebagian besar validator mainnet beroperasi di bawah konfigurasi yang tidak pernah menghubungi rantai sertifikat yang rentan, permukaan serangan teoretis tetap terbatas bahkan sebelum patch diterapkan.
Keputusan tim klien untuk tetap merilis gambar yang diperbarui melindungi sekelompok operator yang menggunakan layanan jarak jauh dan memastikan bahwa pengunduhan gambar di masa depan dimulai dari dasar yang telah diperkuat. Konfigurasi testnet yang mengunduh keadaan awal melalui HTTPS ditandai sebagai berpotensi terpapar, menunjukkan bahwa logika sertifikat yang sama berlaku di luar mainnet. Operator dari jaringan mana pun yang mengandalkan bootstrap HTTPS atau endpoint jarak jauh harus memperlakukan rilis Oktober 2026 sebagai wajib untuk lingkungan mereka. Pemisahan yang jelas antara konfigurasi default dan non-default memungkinkan peringatan menjadi tepat dan meyakinkan bagi sebagian besar set validator.
External Signers dan Remote Beacon Nodes Mewakili Jalur Berisiko Tertinggi
Di antara skenario-skenario yang disebutkan Teku, layanan penandatanganan eksternal membawa tingkat keparahan yang lebih tinggi. Layanan-layanan ini menyimpan kunci pribadi validator secara offline atau di perangkat keras khusus dan merespons permintaan tanda tangan melalui koneksi jaringan. Jika penyerang dapat menyamar sebagai penandatangan dengan menyajikan sertifikat palsu, klien validator dapat menerima tanda tangan yang mengotorisasi operasi yang tidak pernah dimaksudkan oleh operator, termasuk yang mengubah pengaturan penerima biaya atau memulai keluar. Konfigurasi yang mewajibkan otentikasi TLS timbal balik mengurangi dampaknya menjadi penolakan layanan, karena penyerang tidak dapat menyelesaikan handshake yang terautentikasi. Di mana otentikasi timbal balik tidak ada, risiko mendapatkan tanda tangan yang dapat digunakan lebih tinggi. Node beacon jarak jauh menyajikan perhatian terkait tetapi berbeda.
Sebuah validator yang mendelegasikan tugas koordinasi tertentu ke endpoint beacon jarak jauh mempercayai endpoint tersebut untuk informasi tentang tugas, konten blok, dan status jaringan. Peniruan yang berhasil dapat memengaruhi blok yang pada akhirnya diajukan oleh validator, termasuk alamat penerima biaya yang tertanam dalam blok tersebut. Pembangun blok dan relay memperkenalkan permukaan HTTPS lainnya yang memungkinkan penyisipan payload yang dimanipulasi. Dalam setiap kasus, penyerang harus terlebih dahulu mencapai posisi jaringan yang memungkinkan intersepsi dan kemudian menyajikan sertifikat yang diterima oleh runtime Java yang belum diperbaiki. Kombinasi persyaratan ini mempersempit kumpulan lawan yang realistis, namun potensi keuntungan, yaitu biaya yang dialihkan dari proposal yang berhasil, membenarkan penerapan patch pertahanan. Operator yang mempertahankan signer eksternal atau infrastruktur jarak jauh harus memprioritaskan pembaruan klien serta tinjauan mekanisme otentikasi pada tautan-tautan tersebut.
Operator yang menjalankan biner mandiri menghadapi kewajiban pembaruan Java yang terpisah
Pengguna Docker dapat memperbaiki dengan mengambil gambar Teku 26.10.3 atau Besu 26.10.2 yang baru. Operator yang menginstal klien sebagai biner atau paket mandiri bergantung pada runtime Java yang ada pada sistem host. Untuk instalasi tersebut, rilis klien itu sendiri tidak mengubah trust store host. Oleh karena itu, operator harus memverifikasi bahwa versi Java yang terinstal mencakup perbaikan OpenJDK yang menghapus akar yang dikompromikan, atau mereka harus menyesuaikan penyimpanan sertifikat secara manual. Teku secara khusus memperingatkan bahwa Java 26 telah berakhir masa dukungannya dan tidak akan menerima build yang diperbaiki; migrasi ke Java 25 diperlukan untuk dukungan dan pembaruan keamanan berkelanjutan. Perbedaan antara deploy terkontainerisasi dan bare-metal ini umum dalam infrastruktur ethereum dan menciptakan item daftar periksa praktis bagi operator node.
Inventarisasi versi Java, konfirmasi konten trust-store, dan validasi bahwa tidak ada endpoint HTTPS yang masih menunjuk ke layanan tidak terpercaya membentuk kebersihan minimum pasca-patch. Karena kegagalan kriptografi mendasar terjadi di luar Ethereum, kewajiban pembaruan Java yang sama berlaku untuk alat berbasis Java lainnya yang mungkin dijalankan oleh operator. Oleh karena itu, saran klien berfungsi sebagai perbaikan spesifik untuk Teku dan Besu sekaligus dorongan lebih luas untuk mengaudit penanganan sertifikat di seluruh tumpukan operator. Kegagalan untuk menangani lingkungan Java host membuat jalur serangan teoretis tetap terbuka bahkan setelah perangkat lunak klien itu sendiri diperbarui.
Tidak ada eksploitasi yang dikonfirmasi terjadi sebelum patch diterapkan
Laporan teknis Teku dan pelaporan simultan menyatakan bahwa tidak ada eksploitasi terhadap kerentanan tersebut yang diamati. Ketidakteramatan insiden apa pun konsisten dengan rangkaian kondisi sempit yang diperlukan untuk serangan yang berhasil: runtime Java yang tidak diperbarui, koneksi HTTPS ke layanan eksternal, dan penyerang yang mampu menyadap koneksi spesifik tersebut sambil menyajikan sertifikat palsu. Sebagian besar validator tidak pernah memenuhi dua kondisi pertama secara bersamaan. Interval singkat antara pengungkapan publik kunci yang dapat dipulihkan pada 17 Oktober dan rilis gambar klien semakin memperkecil jendela praktis.
Kurangnya serangan yang teramati tidak mengurangi nilai dari patch tersebut. Kerentanan terkait sertifikat dapat tetap dorman hingga muncul lawan yang memanfaatkan kesempatan. Dengan menghapus akar yang dikompromikan dari toko kepercayaan Docker, tim klien menghilangkan penerimaan sertifikat palsu untuk operator yang melakukan pembaruan. Insiden ini juga memberikan demonstrasi langsung tentang bagaimana kegagalan kriptografi eksternal dapat berinteraksi dengan infrastruktur staking Ethereum, mendorong operator untuk memeriksa grafik dependensi mereka sendiri. Insiden mendatang yang melibatkan otoritas sertifikat atau runtime bahasa kemungkinan akan direspons dengan pendekatan serupa di tingkat klien, memperkuat pola mitigasi cepat dan terfokus.
Bagaimana Risiko Keamanan Sertifikat Meluas di Jaringan Blockchain
Insiden eMudhra tidak unik pada ethereum; setiap perangkat lunak yang bergantung pada toko kepercayaan TLS standar mewarisi postur keamanan otoritas sertifikat yang dipercayainya. Klien blockchain yang menyematkan runtime bahasa seperti Java, Go, atau lainnya harus melacak pembaruan sertifikat hulu dengan ketelitian yang sama seperti yang mereka terapkan pada perubahan konsensus. Fakta bahwa konfigurasi default Java menghilangkan pemeriksaan pencabutan memperbesar dampak dan memaksa tim klien untuk mengirimkan modifikasi toko kepercayaan mereka sendiri. Ekosistem lain yang mengemas runtime jangka panjang di dalam kontainer menghadapi risiko yang serupa.
Untuk komunitas Ethereum staking, pelajaran praktisnya adalah keamanan operasional melampaui manajemen kunci dan versi klien, serta mencakup perilaku validasi sertifikat dari setiap komponen yang terhubung jaringan. Operator yang mengadopsi remote signing, beacon node terdistribusi, atau relay pihak ketiga memperkenalkan batasan kepercayaan tambahan yang harus dipantau. Penahanan sukses terhadap kelemahan khusus ini, melalui pencabutan CA, pemblokiran platform, dan pembaruan gambar klien, menunjukkan bahwa pertahanan berlapis dapat berfungsi ketika setiap lapisan merespons dengan cepat. Keragaman klien yang berkelanjutan tetap bernilai karena implementasi yang berbeda mungkin mengungkap atau mengurangi ketergantungan eksternal dengan kecepatan yang berbeda, mengurangi kemungkinan bahwa kegagalan sertifikat tunggal memengaruhi seluruh set validator secara bersamaan.
Kekhawatiran Paralel Terbaru dalam Infrastruktur Validator Menyoroti Pentingnya Kewaspadaan Berkelanjutan
Sertifikat Oktober 2026 tiba dalam latar belakang perhatian keamanan terkait validator lainnya. Pengungkapan sebelumnya yang melibatkan infrastruktur layanan staking dan penanganan penerima biaya sudah memicu keluar sukarela skala besar dan peningkatan pemantauan terhadap aliran hadiah. Secara terpisah, pengembang menangani masalah routing setoran dalam draf aturan untuk peningkatan Glamsterdam mendatang yang dapat menyebabkan penugasan setoran staking salah di bawah kolisi kunci publik tertentu; perbaikan tersebut telah digabungkan ke dalam spesifikasi konsensus setelah tinjauan tambahan. Peristiwa-peristiwa bersamaan ini menunjukkan bahwa ekonomi validator dan keamanan operasional tetap menjadi area pengawasan aktif meskipun protokol inti terus berkembang.
Keburukan sertifikat tersebut berbeda asalnya; berasal dari CA eksternal daripada kesalahan spesifikasi Ethereum atau konsensus klien, namun menyentuh permukaan ekonomi yang sama: tujuan biaya dan hadiah yang diperoleh oleh proposer. Respons klien yang cepat因此 sesuai dengan pola luas yang memperlakukan setiap jalur realistis terhadap penyimpangan hadiah sebagai prioritas tinggi. Operator yang mempertahankan pengaturan klien yang diversifikasi, memantau alamat penerima biaya secara on-chain, dan menjaga perangkat lunak konsensus serta eksekusi tetap mutakhir berada dalam posisi yang lebih baik untuk menyerap guncangan eksternal semacam ini. Tidak adanya kerugian dalam kasus eMudhra memperkuat bahwa pembaruan tepat waktu dan disiplin konfigurasi tetap menjadi pertahanan yang efektif.
Apa yang Perlu Dilakukan Operator Node Ethereum Setelah Rilis Oktober
Validator dan operator node harus memastikan mereka menjalankan Teku 26.10.3 atau lebih baru dan Besu 26.10.2 atau lebih baru saat menggunakan Docker, atau runtime Java yang telah diperbaiki yang setara saat menggunakan biner. Konfigurasi harus ditinjau untuk setiap endpoint HTTPS; di mana endpoint semacam itu diperlukan, mutual TLS atau certificate pinning memberikan perlindungan tambahan. Operator yang masih menggunakan Java 26 harus bermigrasi ke rilis yang didukung. Pemantauan blok yang diusulkan untuk alamat penerima biaya yang tidak terduga tetap menjadi metode deteksi berbiaya rendah bahkan setelah pembaruan trust-store. Karena kunci dasar dapat dipulihkan selama periode yang panjang sebelum ditemukan, audit satu kali terhadap log koneksi historis dan penerimaan sertifikat dapat memberikan jaminan tambahan, meskipun tidak ada eksploitasi yang dilaporkan.
Langkah-langkah ini bersifat inkremental daripada transformasional bagi sebagian besar operator. Sebagian besar validator mainnet tidak pernah menghubungi rantai sertifikat yang rentan dan karena itu mengalami insiden ini hanya sebagai pengingat untuk tetap memperbarui gambar kontainer dan runtime Java. Bagi mereka yang bergantung pada layanan eksternal, patch ini menutup jalur spesifik yang sebelumnya kurang diapresiasi. Mempertahankan kesadaran terhadap peringatan sertifikat dan runtime dari sumber atas akan mengurangi kemungkinan kegagalan eksternal serupa menciptakan jendela serupa di masa depan. Tindakan terkoordinasi oleh tim Teku dan Besu menyediakan solusi segera sekaligus model untuk menangani insiden kriptografi eksternal berikutnya yang bersinggungan dengan perangkat lunak klien Ethereum.
Pertanyaan yang Sering Diajukan
Apa sebenarnya yang salah dengan sertifikat eMudhra?
Delapan otoritas sertifikat menengah yang dioperasikan oleh eMudhra memiliki kunci pribadi yang dihasilkan dengan keacakan yang tidak memadai selama upacara kunci tahun 2025. Kunci-kunci tersebut dapat dipulihkan dari sertifikat publik, memungkinkan siapa pun yang memperolehnya untuk menerbitkan sertifikat palsu yang tetap dipercaya oleh perangkat lunak sebagai sah oleh otoritas tersebut. Enam dari sertifikat menengah tersebut digunakan untuk TLS dan dua untuk penandatanganan kode. eMudhra mencabutnya setelah ditemukan pada 17 Oktober 2026, dan platform utama selanjutnya memblokir materi terkait.
Apakah ada validator yang benar-benar kehilangan imbalan ETH karena kelemahan ini?
Tidak ada eksploitasi terkonfirmasi atau kehilangan reward yang dilaporkan. Saran klien dan liputan simultan menyatakan bahwa tidak ada serangan yang diamati. Kombinasi kondisi yang diperlukan, runtime Java yang belum diperbaiki ditambah koneksi HTTPS aktif ke layanan eksternal yang rentan, membatasi permukaan serangan yang realistis, dan penerbitan cepat gambar Docker yang telah diperbaiki semakin mengurangi paparan.
Apakah node mainnet Ethereum default terpengaruh?
Konfigurasi mainnet Teku default yang tidak mengandung URL HTTPS tidak terpengaruh dan tidak memerlukan tindakan apa pun. Prinsip yang sama berlaku untuk pengaturan Besu yang sebanding. Paparan terbatas pada operator yang secara sengaja mengonfigurasi endpoint HTTPS jarak jauh untuk beacon node, external signer, builder, atau layanan serupa.
Mengapa runtime Java tetap rentan setelah sertifikat dicabut?
Java tidak memeriksa status pencabutan sertifikat secara default. Bahkan setelah sertifikat perantara dicabut dan diblokir oleh browser dan sistem operasi, setiap instalasi Java yang masih menyimpan akar yang sesuai di trust store-nya tetap menerima sertifikat yang menghubungkan ke sana. Gambar Docker klien yang menyertakan runtime lama karena itu memerlukan penghapusan akar secara eksplisit.
Apa yang harus dilakukan operator yang menggunakan gambar Docker?
Ambil dan jalankan versi Teku 26.10.3 atau lebih baru dan versi Besu 26.10.2 atau lebih baru. Gambar-gambar ini tidak lagi mempercayai akar yang dikompromikan. Memperbarui sistem host saja tidak memperbarui runtime di dalam kontainer yang sudah ada; diperlukan gambar baru.
Bagaimana dengan operator yang menjalankan klien sebagai biner mandiri?
Operator tersebut harus memperbarui atau mengonfigurasi ulang instalasi Java host agar mencakup perbaikan OpenJDK, menghapus akar yang terdampak. Java 26 telah berakhir masa dukungannya dan tidak akan menerima build yang diperbaiki; disarankan untuk bermigrasi ke Java 25. Pembaruan perangkat lunak klien sendiri tidak mengubah trust store host.
Penafian: Informasi pasar umum ini, yang mungkin berasal dari sumber pihak ketiga, komersial, atau bersponsor, diberikan hanya untuk referensi dan tujuan pendidikan, dan tidak merupakan saran keuangan atau investasi, penawaran, ajakan, atau jaminan. Kami menyangkal tanggung jawab atas keakuratannya, kelengkapan, keandalannya, dan setiap kerugian yang timbul. Investasi/perdagangan berisiko; kinerja masa lalu tidak menjamin hasil masa depan. Pengguna harus melakukan penelitian, menilai dengan bijak, dan mengambil tanggung jawab penuh. Untuk detail lebih lanjut, silakan konsultasikan Ketentuan Penggunaan dan Pengungkapan Risiko KuCoin.
Penafian: Halaman ini diterjemahkan menggunakan teknologi AI untuk kenyamanan Anda. Untuk informasi yang paling akurat, lihat versi bahasa Inggris aslinya.