<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:webfeeds="http://webfeeds.org/rss/1.0"><channel><title>Certificate-Bypass - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/certificate-bypass/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 22 Oct 2026 03:36:55 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/certificate-bypass/feed.xml" rel="self" type="application/rss+xml"/><image><url>https://feed.craftedsignal.io/favicon-32x32.png</url><title>CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/</link><width>32</width><height>32</height></image><webfeeds:icon>https://feed.craftedsignal.io/favicon.svg</webfeeds:icon><item><title>Java: Certificate revocation bypass via alternative certificate encoding</title><link>https://feed.craftedsignal.io/briefs/2026-10-java-certificate-bypass/</link><pubDate>Thu, 22 Oct 2026 03:36:55 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-10-java-certificate-bypass/</guid><description>Researchers identified that Java’s certificate blocklist (blocked.certs) can be bypassed for compromised certificates by re-encoding them to produce different SHA-256 fingerprints while maintaining signature validity.</description><content:encoded><![CDATA[<p>Sonatype researchers confirmed that Java's <code>blocked.certs</code> 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 <em>s</em> to <em>n-s</em>) and RSA (removing NULL parameters from signature algorithm identifiers) encodings.</p>
<h2 id="impact">Impact</h2>
<p>The bypass allows compromised intermediate CA certificates to remain trusted in Java environments even if their original fingerprints are added to <code>blocked.certs</code>. This could facilitate the issuance and acceptance of fraudulent certificates by applications relying on the Java trust store, despite vendor-provided mitigation attempts.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Audit Java runtime trust stores to identify and remove root certificates associated with the compromised eMudhra infrastructure rather than relying solely on the <code>blocked.certs</code> file.</li>
<li>Test certificate chain validation for critical services using both original and potential re-encoded variants of compromised intermediates.</li>
<li>Monitor Java application logs for TLS handshake failures or unusual certificate validation outcomes following updates to trust stores.</li>
<li>Coordinate with infrastructure and development teams before modifying trust stores to avoid disrupting legitimate TLS connections.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>certificate-bypass</category><category>defense-evasion</category><category>java</category><category>supply-chain</category></item></channel></rss>