Teku and Besu Docker releases fix certificate trust, while binary users need to check their separately installed Java runtime.
Teku and Besu, software used to run Ethereum nodes, have shipped Docker security fixes after a certificate-authority compromise at eMudhra. Operators using affected images can update those containers. Binary installations need a separate check of their Java runtime.
Teku 26.10.3, released Oct. 27, and Besu 26.10.2, released Oct. 26, stop their Docker images trusting four certificate roots: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 and AAA Certificate Services.
For Teku, exposure depends on configuration. The team's security notice says default mainnet nodes without HTTPS URLs are unaffected. On an unremediated runtime, an attacker would need to intercept an affected HTTPS connection to impersonate its endpoint. The notice reports no exploitation.
The underlying incident involved recoverable private keys for eight emSign G3 intermediate certificate authorities. eMudhra acknowledged a script error that produced weak keys and said the intermediates were revoked after the Oct. 17 report. Teku's advisory says Java does not check revocation by default, so affected runtimes still need their own remediation.
The new client images address their bundled trust stores, the lists of certificate authorities Java accepts. Teku's notice identifies all its Docker images through 26.10.2, including the -jdk25 and -jdk26 variants, as retaining the implicated emSign ECC root. Updating Java on the host does not change the runtime inside those containers.
Besu explicitly limits its root-removal change to Docker images: its tar/zip users may still have a JDK that trusts the roots.
Source link
