Ipinapag-ayos ng mga Ethereum Client ang isang kakulangan na maaaring magdirekta sa mga pagsasaulo ng ETH
Ang mga update sa Teku at Besu ay nagpapakita ng kahalagahan ng seguridad ng panlabas na imprastruktura
Ang Ethereum consensus client na Teku at execution client na Besu ay naglabas ng mga security release noong huling bahagi ng Oktubre 2026 upang i-close ang isang vulnerability na may kinalaman sa mga compromised certificate authority keys mula sa Indian firm na eMudhra. Ang kamalian ay maaaring magbigay-daan sa mga attacker na nakakaintervena sa ilang HTTPS connections upang mag-imposto bilang mga external service na ginagamit ng mga validator at i-redirect ang block rewards o makakuha ng sensitibong signatures. Nakuha ng mga researcher na walong intermediate eMudhra certificate authorities ay may private keys na ginawa gamit ang hindi sapat na randomness, kaya ang mga keys na iyon ay maaaring mabawi mula sa mga public certificate mismo. Dahil ang Java runtimes na ginagamit ng dalawang client ay hindi kumokontrol ng certificate revocation sa default, ang ilang Docker images at installations ay patuloy na naniniwala sa mga apektadong chains kahit na naka-block na sila ng mga browser at pangunahing operating systems. Ang default mainnet Teku configurations na nag-iwas sa HTTPS endpoints ay hindi apektado, at hindi nareport ng mga developer ang anumang napatunayang pagpapakita.
Ang mga patch ay nagtatanggal ng pagkakatiwala sa mga nasasakop na ugat mula sa mga updated na Docker images, habang ang mga operator na gumagamit ng standalone binaries ay dapat sagutin ang kanilang lokal na Java trust stores nang hiwalay. Ipinapakita ng episode na ito kung paano ang mga panlabas na infrastructure dependencies ay maaaring lumikha ng maliit ngunit malaking epekto sa mga panganib para sa staking operations kahit na ang core protocol ay nananatiling ligtas. Ang mabilis na tugon ng Teku at Besu ay nagpapakita na ang pagkakaiba-iba ng Ethereum client at ang proaktibong security practices ay maaaring pigilan ang mga banta na may kinalaman sa sertipiko bago ito makaaapekto sa validator rewards sa malawakang saklaw, habang ang mga operator ay naglalapat ng mga available na update at sinusuri ang kanilang mga panlabas na koneksyon configuration.
Mahinang random na pagkakakilanlan sa mga intermediate key ng eMudhra ay naglikha ng maaaring muling makuha na pribadong materyales
Nakakita ang mga siyentipiko ang problema noong Oktubre 17, 2026, nang masukat nila na ang mga pribadong key sa likod ng walong intermediate certificate authorities ni eMudhra ay ginawa gamit ang sobrang kaunting entropy. Ang mga key ay maaaring muling makuha mula sa mga pampublikong sertipiko, isang kondisyon na umiiral mula pa noong kanilang paggawa noong isang key-generation ceremony noong Abril 2025. Ang anim sa mga intermediate ay sumusuporta sa TLS connections, habang ang dalawa ay may kinalaman sa code signing. Nang maging kilala ang pribadong materyal, maaaring maglabas ng fraudulent certificates ang isang attacker na tatanggapin ng software na nananatiling naniniwala sa mga apektadong authority. Ibinawi ni eMudhra ang mga intermediate noong Oktubre 18. Mabilis na tumugon ang mga pangunahing platform: ang mga browser at operating systems ay nagsimulang blockin ang mga sertipiko noong Oktubre 17 hanggang 20, at naglabas ng karagdagang Windows at Edge updates si Microsoft noong Oktubre 26–27 na tinanggal ang kaugnay na roots mula sa kanilang trust lists. Ang cryptographic failure ay hindi isang issue sa Ethereum protocol, ngunit mahalaga ito dahil ang Teku at Besu ay nakasalalay sa Java certificate validation para sa anumang HTTPS connections na ginagawa ng kanilang mga node. Ang default na pag-uugali ng Java na i-skip ang revocation checks ay nananatiling nag-iwan ng ilang installations na eksposed nang higit pa kaysa sa browser environments. Kaya ipinapakita ng insidente na kung paano ang isang operational error ng isang certificate authority ay maaaring magpropaganda sa espesyalisadong infrastructure na nakasalalay sa standard TLS trust stores.
Hindi kailangan ng masusing kriptanalisis ang pagbabalik ng mga susi; ang sapat na random na pagkakakilanlan ay nagagawang madali ang pagdedebelop kapag tinignan ang mga pampublikong sertipiko. Ipinatotohan ng abiso ng Microsoft noong Oktubre 26 na maaaring gamitin ang mga susi upang lumikha ng mga sertipiko na tila nagmumula sa isang tiwalaang awtoridad, na maaaring magbigay-daan sa pagpapakilala bilang mga website o serbisyo. Para sa mga operator ng Ethereum, ang praktikal na epekto ay ang anumang konpigurasyon ng validator na nakabatay sa HTTPS endpoints, remote beacon nodes, external signers, block builders, o relays ay maaaring tanggapin ang isang forged na sertipiko kung ang ilalim na Java runtime ay patuloy na naniniwala sa kompromitong chain. Ang peer-to-peer networking na ginagamit ng Ethereum clients ay hindi naapektuhan dahil hindi ito nakabatay sa mga sertipikasyong awtoridad. Ang kombinasyon ng mababawi at hindi binabalewala ang Java validation ay gumawa ng isang window kung saan ang isang man-in-the-middle attacker na nasa network path ay maaaring ipakita ang isang makatotohanang identity sa client software. Sumagot ang mga koponan ng client sa pamamagitan ng pag-alis ng mga relevant na roots mula sa kanilang Docker images kaysa maghintay lamang ng base Java updates, upang siguraduhing tumatanggap ang mga operator na kumuha ng mga bago na images ng isang hardened trust store. Ang layered response, revocation sa CA, platform blocks, at client-specific image updates, ay limitado ang praktikal na attack surface para sa karamihan sa mga staking setups.
Paano Maaaring Magbago ang Pagpropose ng Block at Pagtatanggap ng Bayad Dahil sa Mga Naka-forged na Sertipiko
Nilikha ng security advisory ni Teku ang mga konkretong landas ng pag-atake na maaaring maging posible kung ang isang attacker ay makapagpapakita ng forged certificate na tinatanggap ng client. Isang skenaryo ay ang pagpapakilala bilang isang remote beacon node na ginagamit ng validator para sa koordinasyon. Kung ang koneksyon ay interseptado at tinanggap ang forged certificate, maaaring makatanggap ang validator ng manipuladong impormasyon tungkol sa block na handa niyang ipropose. Sa kasong iyon, maaaring magbuo at mag-sign ang client ng block kung saan ang fee-recipient address ay nagtuturo sa isang account na kontrolado ng attacker kaysa sa tinitiyak na address ng operator. Ang mga transaction fees at anumang priority tips na kasama sa block ay magkakaroon ng pagdaloy patungo sa attacker. Ipakita rin ng advisory ang mga external signing services, na nagtatago ng validator keys nang hiwalay at bumabalik ng mga signature ayon sa hiling. Isang attacker na makapagpapakilala bilang ganitong signer ay maaaring makakuha ng mga signature na ginagamit para sa sensitibong operasyon, kabilang ang pagbabago na nakakaapekto kung saan direkta ang mga reward. Itinampok ng Teku ang external-signer case bilang isa sa mga mas seryosong konfigurasyon, bagaman ang mutual TLS authentication sa ilang setup ay magiging limitado sa denial of service kaysa sa pagkakasira ng signature.
Ang karagdagang mga eksposed na uri ng koneksyon ay kasama ang execution clients, block builders, relays, at mga serbisyo na nag-aalok ng validator configuration data. Sa bawat kaso, ang pangunahing panganib ay pareho: ang client software ay tinuturing ang forged certificate bilang legal at kaya ay tinatanggap ang data o mga utos na nagbabago sa laman ng isang proposed block o ang paghawak ng mga key. Ang vulnerability ay hindi nagbibigay ng direkta access sa signing key ng validator sa normal na operasyon; sa halip, ito ay nagpapabagsak sa integridad ng mga panlabas na serbisyo na kinukunsulta ng validator. Dahil sa Ethereum block rewards at fees ay binabayad ayon sa mga address na nakapaloob sa proposed block, ang isang matagumpay na manipulasyon sa panahon ng proposal ay maaaring magdulot ng pagbabahagi ng halaga nang hindi kailangang ilipat ang nakuha nang pondo. Walang nareportang pagpapakita ng mga path na ito, at ang default mainnet Teku installations na walang HTTPS URLs sa kanilang configuration ay nananatiling labas sa affected set. Ang detalyadong mga skenaryo ay nagpapaliwanag naman kung bakit tinuturing ng client teams ang isyu bilang nangangailangan ng agad na Docker-image updates kahit na ang pinalabas na protocol at peer-to-peer layers ay hindi naapektuhan.
Inalis ng Teku 26.10.3 ang mga napapalitan na ugat mula sa Docker Trust Stores
Nilabas ng Teku ang bersyon 26.10.3 noong Oktubre 27, 2026, partikular upang harapin ang eksposur na kaugnay ng eMudhra. Ang mga tala sa paglalabas ay nagsasabi na ang mga Docker image ay hindi na umaasa sa emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2, o mga root ng AAA Certificate Services. Tinanggal na ng OpenJDK ang mga root na ito pagkatapos ma-compromise ang mga intermediate authority; ang Eclipse Temurin base images na ginagamit ng Teku ay hindi pa nakakakuha ng kaukulang pagpapabuti sa panahon ng paglalabas ng client. Sa pamamagitan ng paglalabas ng mga updated na images, siguraduhin ng koponan ng Teku na ang mga operator na kumuha ng mga bagong tag ay makakatanggap ng Java runtime na ang trust store ay naglalayos sa compromised na materyales. Ang abiso na kasama ang paglalabas ay nagteklar na ang isang default mainnet node na walang HTTPS URLs na nakakonfigura ay hindi nangangailangan ng anumang aksyon. Ang eksposur ay limitado lamang sa mga konfigurasyon na deliberately nagkonekta sa remote HTTPS endpoints para sa beacon coordination, external signing, builders, o katulad na serbisyo.
Ang mga operator na gumagamit ng mas lumang Docker images, kabilang ang mga may tag na hanggang 26.10.2, ay patuloy na nagpapadala ng runtime na naniniwala sa mga naaapektuhan na roots. Ang pag-update ng host Java installation ay hindi awtomatikong mag-uupda ng runtime sa loob ng isang umiiral na container, kaya kailangan ng bagong image pull. Dagdag pa ni Teku, ang Java 26 ay naging end of life at hindi magkakaroon ng patched build; ang mga operator na patuloy pa sa bersyon na iyon ay inirerekomenda na lumipat sa kasalukuyang long-term support release, Java 25, at gamitin ang kaugnay na -jdk25 image tags. Ang release ay naglalaman ng pag-alis ng certificate-root kasama ang gabay sa pagpapamahala ng runtime version. Dahil ang pagbabago ay limitado lamang sa trust stores ng Docker images, ang consensus behavior at validator key handling ay nananatiling hindi nagbago. Ang update ay ipinapakita bilang isang inirerekomenda na pagsisiguro sa kaligtasan kaysa isang emergency consensus upgrade, na nagpapakita ng maliit na sakop ng mga naaapektuhan na konfigurasyon.
Ang Besu 26.10.2 ay naglalapat ng mga pagpapalit sa pagtitiwala sa sertipiko na paralelo
Ang Besu, ang execution-layer client na pinapanatili ng mas malawak na ecosystem, ay naglabas ng bersyon 26.10.2 noong Oktubre 26, 2026, na naglalapat ng parehong pag-alis ng root sa mga Docker image nito. Ang parehong oras at mga identikal na layunin sa sertipiko ay nagpapakita ng pinagsamang kamalayan sa insidente ng eMudhra sa buong Java-based Ethereum client stack. Ang execution clients ay nakikipag-ugnayan sa consensus clients at mga panlabas na serbisyo para sa pagbuo ng payload at paglalakip ng transaksyon; anumang mga path ng HTTPS na pinapanatili nila ay pumapailalim sa parehong mga patakaran sa pagpapatotoo ng sertipiko na nakakaapekto sa Teku. Sa pag-alis ng tiwala sa mga napapahamak na awtoridad mula sa mga imahe nito, isinara ng Besu ang kaugnay na attack surface para sa mga operator na nakikibase sa mga Docker distribution nito.
Tulad ng Teku, ang pag-update ng Besu ay hindi awtomatikong nag-aayos ng mga standalone binary installation na gumagamit ng hiwalay na pinamamahalaang Java runtime. Dapat suriin at i-update ng mga operator sa kategoryang ito ang kanilang lokal na trust stores o bersyon ng Java nang hiwalay. Ang parehong paglabas ng client ay nagpapakita na parehong ang consensus at execution na bahagi ng Ethereum node software stack ay nakikilala ang karaniwang pagkakasalalay sa Java certificate handling. Dahil maraming production validators ang nagpapatakbo ng parehong consensus client tulad ng Teku at execution client tulad ng Besu, ang parehong pag-update ay nagpapababa ng posibilidad na manatili ang residual na tiwala sa mga compromised roots sa anumang bahagi ng node pair. Ang kakulangan ng mga nareportang pagpapabaya bago ang paglabas ay nagmumungkahi na ang praktikal na window ay limitado, ngunit ang pinagsamang patch ay patuloy na nagpapakita ng matalinong pagpapalakas laban sa kilalang cryptographic failure na nasa labas ng Ethereum protocol mismo.
Kawalan ng pag-check ng pagpapalit ng default sa Java ay nagpahaba sa pagkakaroon ng panganib
Isang sentral na teknikal na detalye ay ang pagiging hindi kumokontrol ng status ng pagrevoca ng Java certificate sa default. Kahit na sinira na ng eMudhra ang mga intermediate certificate at sinira na sila ng mga pangunahing platform, patuloy pa ring tatanggapin ng anumang Java runtime na mayroon pa sa kanyang trust store ang mga kaugnay na roots o intermediates ang mga sertipiko na nag-uugnay sa mga awtoridad na iyon. Ipinakalabas ng OpenJDK ang mga pagpapabuti na una ay sinira ang mga compromised intermediates at pagkatapos ay tinanggal ang apat na kaugnay na roots. Gayunpaman, ang mga Docker images na nagdadala ng mas lumang Temurin o OpenJDK builds ay hindi awtomatikong natanggap ang mga pagpapabuti na iyon. Ang pagkakaiba sa pagitan ng pagrevoca sa antas ng platform at ang pag-uugnay ng embedded Java runtimes ang naging dahilan kung bakit kinakailangan ang mga update sa client-specific na image.
Para sa mga operator ng Ethereum, ang epekto ay operasyonal kaysa teoretikal. Ang isang validator na ang konfigurasyon ay naglalaman ng HTTPS endpoints para sa remote services ay sumasang-ayon sa mga desisyon sa pagkakatiwala ng Java runtime na ginagamit nito. Kung ang runtime na ito ay hindi na-update o nalitan ng patched image, nananatiling handa ang client na tanggapin ang forged certificate. Ang Mutual TLS o pinned certificates ay maaaring mapabawasan ang panganib sa maingat na inenjinier na mga setup, ngunit maraming production configurations ay nakasalalay sa standard trust-store validation. Kaya ang mga release ng Teku at Besu ay isang praktikal na paalala na ang containerized node software ay may sariling certificate store na hiwalay sa host system. Ang mga operator na itinuturing ang Docker images bilang opaque black boxes ay maaaring makalimutan sa detalyeng ito hanggang sa isang panlabas na insidente ang magpapakailanlang i-update. Ang episode ay nagpapakita rin ng halaga ng pagmamasid sa mga upstream Java security advisories kapag ginagamit ang Java-based Ethereum clients.
Ipinag-iwas ng mga default na konpigurasyon ng mainnet ang pangunahing surface ng pag-atake
Ang payo ng Teku ay malinaw na nagpapahiwatig na ang default mainnet node na walang HTTPS URLs sa kanyang konfigurasyon ay hindi naapektuhan at hindi nangangailangan ng anumang aksyon. Ang karamihan sa mga validator na nagpapatakbo ng lokal na colocated consensus at execution clients, nang walang remote signing o remote beacon endpoints, ay nasa kategoryang ito. Ang peer-to-peer discovery at gossip protocols na ginagamit ng Ethereum ay hindi nakasalalay sa eMudhra certificate authorities, na nagpapalakas pa sa mga standard na setup. Ang panganib ay nakatuon sa mga operator na may malinaw na idinagdag ang external HTTPS dependencies para sa operasyonal na kahingian, geographic distribution ng signing keys, o integrasyon sa third-party block-building services. Mahalaga ang pagkakaiba na ito para sa pagtataya ng pangkabuuang epekto sa network. Dahil ang karamihan sa mga mainnet validator ay nagpapatakbo sa ilalim ng mga konfigurasyon na hindi nag-contact kailanman sa vulnerable certificate chains, ang teoretikal na attack surface ay nanatiling limitado kahit bago pa ang mga patch.
Ang desisyon ng mga koponan ng kliyente na ipaglaban ang mga napapag-updated na imahe ay nagpapanatili sa subset ng mga operator na gumagamit ng remote services at nagpapakatotoo na ang mga susunod na pagkuha ng imahe ay magsisimula mula sa isang pinagbagoang baseline. Ang mga konpigurasyon ng testnet na nagdadownload ng initial state sa pamamagitan ng HTTPS ay itinuturing na posibleng eksposed, na nagpapakita na ang parehong lohika ng sertipiko ay nakakatugon sa labas ng mainnet. Ang mga operator ng anumang network na nakasalalay sa HTTPS bootstrap o remote endpoints ay dapat ituring ang mga release noong Oktubre 2026 bilang obligatori para sa kanilang mga kaligiran. Ang malinaw na pagkakahiwalay sa pagitan ng default at non-default na mga konpigurasyon ay nagbigay-daan para sa abiso na maging maliwanag at mapagpahinga para sa karamihan ng validator set.
Ang External Signers at Remote Beacon Nodes ay nagpapakita ng pinakamataas na panganib na daan
Sa mga skenaryo na isinampa ni Teku, ang mga externa signing service ay may mas mataas na kalalabasan. Ang mga serbisyo na ito ay nagtatago ng private keys ng validator nang offline o sa espesyalisadong hardware at sumasagot sa mga kahilingan ng signature sa pamamagitan ng network connection. Kung makapag-impostor ang isang attacker sa signer sa pamamagitan ng pagpapakita ng forged certificate, maaaring tanggapin ng validator client ang mga signature na nagpapahintulot sa mga operasyon na hindi inaasahan ng operator, kabilang ang pagbabago sa fee-recipient settings o pagpapagsimula ng exits. Ang mga konfigurasyon na nagpapakilala ng mutual TLS authentication ay nagbabawas sa epekto sa denial of service, dahil hindi makakumpleto ng authenticated handshake ang attacker. Kung wala ang mutual authentication, mas mataas ang panganib na makakuha ng usable na signatures. Ang remote beacon nodes ay nagtatampok ng isang kaugnay ngunit iba’t ibang problema.
Ang isang validator na nagdelegeta ng ilang mga gawain sa pagkoordinasyon sa isang remote beacon endpoint ay nagtatagpo sa endpoint para sa impormasyon tungkol sa mga gawain, nilalaman ng block, at estado ng network. Ang isang matagumpay na pagpapakilala ay maaaring makaapekto sa block na huling ipinapropose ng validator, kabilang ang fee-recipient address na nakapaloob sa block. Ang mga block builder at relay ay nagdadagdag pa ng iba pang HTTPS surfaces kung saan maaaring i-inject ang manipulated payloads. Sa bawat kaso, kailangan muna ng attacker na makamit ang isang network position na nagpapahintulot sa pag-intercept at kailangan pang ipakita ang isang sertipiko na tatanggapin ng unpatched Java runtime. Ang kombinasyon ng mga kinakailangan ay nagpapaliit sa hanay ng mga realistiko na kalaban, ngunit ang potensyal na kapalit, ang redirected fees mula sa isang matagumpay na propuesta, ay nagpapaliwanag kung bakit kailangan ang mga defensive patches. Ang mga operator na may panatilihang external signers o remote infrastructure ay dapat magbigay-pansin sa parehong client updates at pagsusuri sa mga mekanismo ng authentication sa mga link na iyon.
Ang mga operator na nagpapatakbo ng mga mandirigma na nag-iisa ay may magkakahiwalay na obligasyon sa pag-update ng Java
Maaaring ayusin ng mga gumagamit ng Docker sa pamamagitan ng pagkuha ng mga bagong imaheng Teku 26.10.3 o Besu 26.10.2. Ang mga operator na nag-iinstall ng mga client bilang standalone na binaries o packages ay nakasalalay sa Java runtime na nasa host system. Para sa mga installasyong ito, ang sariling client releases ay hindi nagbabago sa host trust store. Kaya kailangan ng mga operator na suriin kung ang kanilang installed Java version ay naglalaman ng mga OpenJDK fixes na alisang mga compromised roots, o kaya ay manu-manong i-adjust ang certificate store. Binaril ng Teku na ang Java 26 ay end-of-life at hindi magtatanggap ng patched build; kailangan ang migration patungo sa Java 25 para sa patuloy na suporta at security updates. Ang pagkakahati-hati sa pagitan ng containerized at bare-metal deployments ay karaniwan sa Ethereum infrastructure at naglilikha ng isang praktikal na checklist item para sa mga node operator.
Ang pag-aayos ng mga bersyon ng Java, ang pagkumpirma ng laman ng trust-store, at ang pagpapatotoo na walang HTTPS endpoints ay patuloy na nakadirekta sa mga hindi pinagkakatiwalaang serbisyo ay ang minimum na pag-aayos pagkatapos ng patch. Dahil sa ang pangunahing pagkabigo sa kriptograpiya ay nangyari sa labas ng Ethereum, ang parehong obligasyon sa pag-update ng Java ay umiiral sa anumang iba pang Java-based na kasangkapan na maaaring pana panahon na ipagpapatuloy ng isang operator. Kaya ang mga abiso ng client ay naglilingkod bilang isang partikular na solusyon para sa Teku at Besu at isang mas malawak na paalala upang suriin ang paghawak ng sertipiko sa buong stack ng operator. Ang pagkakamali sa pag-aayos ng host Java environment ay nananatiling bukas ang teoretikal na mga daanan ng pag-atake kahit na ang sariling software ng client ay na-update na.
Wala nang nasumpungan na pagpapakita bago ang mga patch ay maipadala
Ang Teku advisory at ang parehong pag-uulat ay nagpapahiwatig na walang obserbado na pagsasamantala sa vulnerability. Ang kakulangan ng kilalang insidente ay tugma sa maliit na hanay ng mga kondisyon na kailangan para sa isang matagumpay na pag-atake: isang unpatched Java runtime, isang HTTPS connection sa isang external service, at isang attacker na kaya mag-intercept ng partikular na connection habang ipinapakita ang forged certificate. Ang karamihan sa mga validator ay hindi nag-satisfy sa unang dalawang kondisyon nang sabay-sabay. Ang maikling panahon sa pagitan ng pampublikong pagpapahayag ng mga recoverable keys noong October 17 at ang paglabas ng client image ay dagdag pa sa pagpapaliit ng praktikal na window.
Ang kakulangan ng nakita mong mga serangan ay hindi nagbabawas sa halaga ng mga patch. Ang mga vulnerability na may kinalaman sa sertipiko ay maaaring manatiling nakatago hanggang sa lumabas ang isang adversary na nagpapasya mag-act. Sa pamamagitan ng pag-alis ng mga nasiraang roots mula sa Docker trust stores, tinanggal ng mga koponang client ang pagtanggap sa mga forged na sertipiko para sa mga operator na nag-update. Ang episode ay nagbigay din ng live na demonstrasyon kung paano makakatugma ang mga labas na cryptographic na pagkabigo sa Ethereum staking infrastructure, na nagpukaw sa mga operator na suriin ang kanilang sariling mga dependency graphs. Ang mga susunod pang insidente na may kinalaman sa mga certificate authority o language runtimes ay malulutas ng magkakatulad na mga tugon sa antas ng client, na pagsisikapang pagsuportahan ang pattern ng mabilis at targeted na pagpapabuti.
Paano ang mga panganib sa seguridad ng sertipiko ay umiikot sa mga blockchain network
Hindi eksklusibo sa Ethereum ang insidente ng eMudhra; anumang software na nakasalalay sa standard TLS trust stores ay nagdudulot ng seguridad na katumbas ng mga certificate authority na itinitiyak nito. Ang mga blockchain client na naglalaman ng language runtimes tulad ng Java, Go, o iba pa ay dapat sundin ang mga pag-update ng certificate mula sa upstream nang may parehong pagiging masigasig na ginagawa nila sa pagbabago ng consensus. Ang katotohanan na ang default configuration ng Java ay nagtatanggal ng pag-check ng revocation ay nagpapalakas ng epekto at nagpakailangan sa mga koponan ng client na maglabas ng kanilang sariling pagbabago sa trust-store. Ang iba pang ecosystem na nagpapakita ng matagal na buhay na runtimes sa loob ng mga container ay nakakaranas ng katulad na panganib.
Para sa komunidad ng Ethereum staking, ang praktikal na aral ay ang operasyonal na seguridad ay lumalawak pa sa pamamagitan ng pagpapamahala ng mga key at client versioning upang kasama ang pagpapatotoo ng sertipiko ng bawat networked na komponente. Ang mga operator na gumagamit ng remote signing, distributed beacon nodes, o third-party relays ay nagdadala ng karagdagang mga hangganan ng pagkakatiwala na dapat mababantayan. Ang matagumpay na pagtatapos sa partikular na kahinaan, sa pamamagitan ng CA revocation, platform blocks, at client image updates, ay nagpapakita na ang layered defenses ay maaaring magtrabaho kapag bawat layer ay tumutugon nang mabilis. Ang patuloy na client diversity ay nananatiling may halaga dahil ang iba’t ibang implementation ay maaaring makakita o mapabawasan ang mga eksternal na dependency sa iba’t ibang bilis, na nagpapababa ng posibilidad na ang isang pagkabigo sa sertipiko ay magdudulot ng epekto sa buong validator set nang sabay-sabay.
Kahit na ang mga bagong pag-aalala sa validator infrastructure ay nagpapakita ng patuloy na pagiging alerto
Kumita ang sertipikasyon noong Oktubre 2026 sa ilalim ng iba pang pagmamasid sa seguridad na may kinalaman sa validator. Nangyari na ang mga nakaraang paglalathala tungkol sa infrastruktura ng staking service at pag-handle ng fee-recipient na nag-udyok sa malawakang pagsisikap na lumabas nang voluntary at pagpapalakas ng pagmamasid sa mga pagbabayad ng reward. Hiwalay dito, tinugon ng mga developer ang isang isyu sa pagrute ng deposito sa draft na mga patakaran para sa darating na Glamsterdam upgrade na maaaring magdulot ng maling pag-assign ng staking deposits sa ilalim ng ilang public-key collisions; ang pag-aayos ay pinagsama sa consensus specifications pagkatapos ng karagdagang pagsusuri. Ang mga kakaibang pangyayaring ito ay nagpapakita na ang ekonomiks at operasyonal na seguridad ng validator ay patuloy na mga larangan ng pagmamasid kahit na patuloy na umuunlad ang core protocol.
Nagkakaiba ang pinagmulan ng kakaibang sertipiko; ito ay nagmula sa isang panlabas na CA kaysa sa isang bug sa ethereum specification o client consensus, ngunit tinamaan ang parehong ekonomikong surface: ang destinasyon ng mga bayad at reward na nakikita ng mga proposer. Kaya, ang mabilis na reaksyon ng client ay sumasalamin sa mas malawak na pattern ng pagtrato sa anumang makatotohanang daan patungo sa pagbabago ng reward bilang mataas na prioridad. Ang mga operator na nagpapanatili ng diversified na client setup, nagmomonito sa fee-recipient addresses sa blockchain, at nagpapanatili ng parehong consensus at execution software na updated ay mas maayos na posisyon upang makatanggap ng ganitong panlabas na shock. Ang kakulangan ng mga pagkawala sa kaso ng eMudhra ay nagpapatibay na ang maagap na patching at disiplinang configuration ay patuloy na epektibong depensa.
Ano ang dapat gawin ng mga operator ng ethereum node pagkatapos ng mga release noong Oktubre
Dapat patunayan ng mga validator at node operator na gumagana sila ng Teku 26.10.3 o higit pa at Besu 26.10.2 o higit pa kapag ginagamit ang Docker, o ang katumbas na pinagpaayos na Java runtime kapag ginagamit ang mga binary. Dapat suriin ang mga konfigurasyon para sa anumang HTTPS endpoints; kung kinakailangan ang mga ganitong endpoint, ang mutual TLS o certificate pinning ay nagbibigay ng karagdagang proteksyon. Dapat lumipat ang mga operator na nasa Java 26 sa isang suportadong bersyon. Ang pagmamasid sa mga propong bloke para sa hindi inaasahang fee-recipient addresses ay nananatiling isang mura paraan ng pagkakakilanlan kahit pagkatapos ng pag-update ng trust-store. Dahil ang mga pondo sa ilalim ay maaaring mabawi sa isang mahabang panahon bago ito matuklasan, ang isang isang-time na audit ng mga nakaraang koneksyon at mga log ng pagtanggap ng sertipiko ay maaaring magbigay ng karagdagang pagkakatiyak, bagaman walang naitalang pagpapabaya.
Ang mga hakbang na ito ay incremental kaysa transformative para sa karamihan sa mga operator. Ang karamihan sa mga mainnet validator ay hindi nagkontak sa mga vulnerable na certificate chains, kaya sila ay nakaranas ng insidente bilang paalala lamang na panatilihin ang mga container images at Java runtimes na updated. Para sa mga nag-iisa na nakasalalay sa mga panlabas na serbisyo, ang mga patch ay isinara ang isang tiyak at dating hindi sapat na pinahalagahan na daan. Ang pagpapanatili ng kamalayan sa mga abiso tungkol sa certificate at runtime mula sa mga nasa itaas ay magbabawas sa posibilidad na magkakaroon ng katulad na mga window sa hinaharap dahil sa mga katulad na panlabas na pagkabigo. Ang pinagsamang aksyon ng mga koponan ng Teku at Besu ay nagbibigay ng agad na solusyon at isang modelo para sa paghahandle sa susunod na panlabas na kriptograpikong insidente na tumutugma sa Ethereum client software.
Madaling Tanong
Ano ang eksaktong mali sa mga sertipiko ng eMudhra?
Walong intermediate certificate authorities na pinapatakbo ni eMudhra ay may mga private key na ginawa gamit ang sapat na randomness sa isang key ceremony noong 2025. Ang mga key ay maaaring makuha mula sa mga public certificate, na nagpapahintulot sa sinumang makakuha nito na maglabas ng fraudulent na certificate na tuturuan pa rin ng tiwala ng software ang mga authority na ito. Anim sa mga intermediate ay ginamit para sa TLS at dalawa para sa code signing. Ibinawi ni eMudhra ang mga ito pagkatapos makita ito noong Oktubre 17, 2026, at sinira ng mga pangunahing platform ang kaugnay na materyales.
Nawala ba ang anumang ETH rewards ng mga validator dahil sa pagkakamali na ito?
Walang nalapit na pagpapakita o pagkawala ng mga reward. Ang mga abiso sa kliyente at ang parehong balita ay nagsasabi na walang mga pag-atake ang napansin. Ang kombinasyon ng mga kinakailangang kondisyon, isang hindi i-patch na Java runtime kasama ang aktibong HTTPS connection sa isang vulnerable na panlabas na serbisyo, ay limitado ang realistiko na attack surface, at ang mabilis na paglabas ng patched Docker images ay dagdag pa nang bawas sa exposure.
Nakakaapekto ba ang default na ethereum mainnet nodes?
Hindi naaapektuhan ang mga default na mainnet Teku configurations na walang HTTPS URLs at hindi kailangan ng anumang aksyon. Parehong prinsipyo ang umiiral sa mga katulad na Besu setups. Ang panganib ay limitado sa mga operator na deliberadong nag-configure ng remote HTTPS endpoints para sa beacon nodes, external signers, builders, o mga katulad na serbisyo.
Bakit nanatiling vulnerable ang Java runtimes matapos ma-revoke ang mga sertipiko?
Hindi nag-e-verify ang Java ang status ng pag-revoke ng sertipiko sa default. Kahit na ang mga intermediate ay na-revoke at na-block ng mga browser at operating systems, patuloy pa ring tinatanggap ng anumang Java installation na mayroon pa sa kanyang trust store ang mga kaugnay na roots ang mga sertipiko na nag-uugnay sa kanila. Kaya kailangan ng mga client Docker images na may mas lumang runtime ang eksplisitong pag-alis ng mga root.
Ano ang dapat gawin ng mga operator na gumagamit ng Docker images?
I-download at i-run ang Teku version 26.10.3 o higit pa at Besu version 26.10.2 o higit pa. Ang mga imahe na ito ay hindi na naniniwala sa mga kompromitadong ugat. Ang pag-update ng host system ay hindi nag-a-update ng runtime sa loob ng umiiral na container; kailangan ng bagong imahe.
Ano naman ang mga operator na nagpapatakbo ng mga client bilang mga standalone na binary?
Dapat i-update o i-reconfigure ng mga operator ang host Java installation upang isama ang mga pagpapabuti ng OpenJDK, tanggalin ang mga naaapektuhang ugat. Ang Java 26 ay end-of-life at hindi magtatanggap ng patched build; inirerekomenda ang pag-migrate sa Java 25. Ang sariling mga update ng client software ay hindi nagbabago sa host trust store.
Paalala: Ang pangkalahatang impormasyon sa merkado na ito, maaaring mula sa mga third-party, komersyal, o sinponsor na pinagkukunan, ay ibinibigay lamang para sa refrensya at edukasyonal na layunin at hindi nagtataglay ng abiso sa pondo o pag-invest, alok, paghingi, o jamin. Kami ay nagtatanggi sa anumang pananagutan para sa kawastuhan, kakahusayan, reliability, at anumang naging pagkawala. Ang pag-invest/trade ay may panganib; ang nakaraang performance ay hindi nagjanin ng mga resulta sa hinaharap. Dapat mag-imbento, magpasya nang may pag-iingat, at tanggapin ang buong pananagutan ang mga gumagamit. Para sa karagdagang detalye, mangyaring bisitahin ang Mga Tuntunin ng Paggamit at Pagpapahayag ng Panganib ng KuCoin.
Disclaimer: AI technology ang ginamit sa pag-translate ng page na ito para sa convenience mo. Para sa pinaka-accurate na impormasyon, mag-refer sa original na English version.