TL;DR
- Tinanggal ng Teku 26.10.3 at Besu 26.10.2 ang tiwala sa mga ugat ng sertipiko na kaugnay ng eMudhra pagkatapos maexpose ang ilang intermediate keys na nagdulot ng panganib ng pagpapakilala sa ilang HTTPS-based na validator configurations.
- Hindi naapektuhan ang mga default na Teku mainnet node, at walang anumang pagpapakita ng pagpapakita na ireport, habang ang panganib ay nakadepende sa mga validator na kumonekta sa mga panlabas na serbisyo sa pamamagitan ng HTTPS.
- Dapat i-update ng mga gumagamit ng Docker ang mga client image, habang ang mga nagtatrabaho nang hiwalay ay kailangang i-patch ang Java nang hiwalay; kailangan ng mga gumagamit ng Java 26 na mag-migrate sa mga suportadong build ng Java 25.
Nilabasan ng Teku at Besu ang mga pag-update sa seguridad matapos maging kompromiso ang mga key ng eMudhra certificate-authority, na nag-iwan ng eksposado ang mga konpigurasyon ng Ethereum node sa forged HTTPS connections. Teku’s release notes ay nagrerekomenda ng bersyon 26.10.3, na nag-alis ng tiwala sa apat na naapektuhang certificate roots mula sa Docker images, habang ang Besu ay naglabas ng bersyon 26.10.2. Ang mga pag-update ay tumutugon sa certificate trust sa antas ng software-distribution kaysa sa isang kahinaan sa mga patakaran ng consensus ng Ethereum. Ang mga default Teku mainnet nodes ay hindi naapektuhan, na nagpapanatili ng pagkakaiba ng insidente mula sa mga vulnerability sa Ethereum protocol.
Nasira ang mga susi ng sertipiko at naglikha ng panganib ng pagmamalupit
Nakita ng mga siyentipiko na maaaring mabawi ang mga pribadong key para sa walong eMudhra intermediate certificate authorities dahil sa kulang na randomness sa pagbuo nito. Bagaman ginawa na ang pag-revoke ng mga sertipiko, hindi check ng Java ang pag-revoke sa default, kaya maaaring tanggapin ng mga runtime ang mga forged na sertipiko. Kaya maaaring mag-impostor ang isang attacker na nasa gitna ng isang node at isang HTTPS service sa ilalim ng mga vulnerable na konfigurasyon. Ang pangyayaring ito ay nagpapatibay kung bakit Ethereum client diversity and operational security ay umaabot pa sa labas ng consensus code.
Ang pinakamataas na panganib na mga skenaryo ay kasangkot ang mga validator na kumukonekta sa mga panlabas na serbisyo sa pamamagitan ng HTTPS. Maaaring manipulahin ng isang pinagmumulan na endpoint ang impormasyon sa pagbuo ng bloke, i-redirect ang mga tagatanggap ng bayad, o makakuha ng mga lagda sa pamamagitan ng isang imitadong panlabas na signer. Sinabi ng Teku na maaaring magdulot ng isang attacker ng isang validator client na gumagamit ng isang remote beacon node upang mag-proposal ng isang bloke na nagbabayad ng bayad sa address ng attacker. Ang panganib ay nakadepende sa posisyon ng network at mga konpigurasyon ng panlabas na serbisyo, hindi lamang sa pagpapatakbo ng Teku o Besu. Walang naitalang pagpapakita.
Tinanggal ng Teku 26.10.3 ang pagkakatiwala sa emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 at AAA Certificate Services sa mga Docker image. Ang pag-update ng Besu ay gumagamit ng parehong pamamaraan. Kailangan ng mga operator na tumatakbo ng mga binary nang direkta na i-update ang Java nang hiwalay dahil ang mga pag-upgrade ng client ay hindi nagpapalit sa certificate store ng host runtime. Kaya kailangan ng iba’t ibang paraan ng pag-aayos ang Docker at standalone deployments. Mahalaga ang pagkakaiba pagkatapos ng Ethereum validator infrastructure incidents na ipinakita kung paano ang mga off-protocol dependencies ay nakakaapekto sa staking operations.
Ang Java 26 ay nagdudulot ng komplikasyon dahil natapos na ang kanyang buhay at hindi na makakatanggap ng kinakailangang patched build, kaya kailangan ng mga nakaapekto na operator na mag-migrate patungo sa Java 25. Ang peer-to-peer Ethereum networking ay hindi ipinakita dahil hindi ito nakadepende sa mga certificate authority na ito. Ang mga pagpapabuti ay nagbabawas sa panganib ng third-party trust-store nang hindi pa pinag-aayos ang live mainnet exploit o pagbabago sa protocol ng Ethereum. Ang episode ay sumusunod sa iba pang security work, kabilang ang Glamsterdam deposit-routing correction, na nagpapakita kung paano ang validator safety ay nakadepende sa protocol code at suportang infrastructure.