Java: Certificate revocation bypass via alternative certificate encoding

Sonatype researchers confirmed that Java's blocked.certs mechanism, used to mitigate the October 2026 eMudhra certificate authority compromise, is susceptible to bypass. Because the blocklist relies on exact SHA-256 byte-level fingerprints, attackers can alter the binary encoding of a compromised certificate without invalidating its signature. If the re-encoded certificate is still accepted by the trust store, it bypasses the blocklist. This was demonstrated using both ECDSA (altering signature representation from s to n-s) and RSA (removing NULL parameters from signature algorithm identifiers) encodings.

Impact

The bypass allows compromised intermediate CA certificates to remain trusted in Java environments even if their original fingerprints are added to blocked.certs. This could facilitate the issuance and acceptance of fraudulent certificates by applications relying on the Java trust store, despite vendor-provided mitigation attempts.

Recommendation

• Audit Java runtime trust stores to identify and remove root certificates associated with the compromised eMudhra infrastructure rather than relying solely on the blocked.certs file.
• Test certificate chain validation for critical services using both original and potential re-encoded variants of compromised intermediates.
• Monitor Java application logs for TLS handshake failures or unusual certificate validation outcomes following updates to trust stores.
• Coordinate with infrastructure and development teams before modifying trust stores to avoid disrupting legitimate TLS connections.