CVE-2026-93578: Io.netty/netty-handler-ssl-ocsp: netty: missing extended key usage (eku) check in ocsp client allows certificate revocation bypass

Missing Extended Key Usage (EKU) check in OCSP Client allows certificate revocation bypass

A public GitHub Security Advisory (GHSA-jhjp-5q4f-8wr2) describes the following issue:

Summary Netty's OcspClient does not verify that an OCSP responder certificate contains the id-kp-OCSPSigning Extended Key Usage (EKU). A bad actor with any valid certificate issued by the same CA can forge "GOOD" OCSP responses for revoked certificates, bypassing revocation checks.

Details In io.netty.handler.ssl.ocsp.OcspClient, validateSignature uses CertPathBuilder to validate the responder's certificate chain to the trust anchor. However, it fails to verify if the responder is authorized to sign OCSP responses. Per RFC 6960, delegated OCSP responders must explicitly hold the id-kp-OCSPSigning EKU. Because OcspClient omits this check, any CA-issued certificate can successfully sign forged OCSP responses.

https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2

Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing the use of the id-kp-OCSPSigning value as described above. ... They MUST reject the response if the certificate required to validate the signature on the response does not meet at least one of the following criteria:

1. Matches a local configuration of OCSP signing authority for the certificate in question, or

2. Is the certificate of the CA that issued the certificate in question, or

3. Includes a value of id-kp-OCSPSigning in an extended key usage extension and is issued by the CA that issued the certificate in question as stated above.

PoC The following test in io.netty.handler.ssl.ocsp.OcspClientTest demonstrates the vulnerability. A bad actor creates a forged OCSP response signed by a standard, non-OCSP-signing certificate. Netty validates the signature without throwing an exception.

java @Test void validateSignatureWithoutEkuSucceedsBypass() throws Exception { X509Bundle caRoot = new CertificateBuilder() .algorithm(CertificateBuilder.Algorithm.rsa2048) .subject("CN=TrustedRootCA") .setIsCertificateAuthority(true) .buildSelfSigned();

X509Bundle badActorCert = new CertificateBuilder() .algorithm(CertificateBuilder.Algorithm.rsa2048) .subject("CN=BadActorServer") .buildIssuedBy(caRoot);

X509CertificateHolder badActorHolder = new JcaX509CertificateHolder(badActorCert.getCertificate());

BasicOCSPResp forgedResponse = createBasicOcspResponse( badActorCert, new X509CertificateHolder[]{badActorHolder} );

assertDoesNotThrow(() -> OcspClient.validateSignature(forgedResponse, caRoot.getCertificate()), "Validation should have thrown an exception due to missing EKU."); }

Impact Authorization Bypass. Applications using Netty's OcspClient will accept revoked certificates if a network-positioned bad actor possesses any other certificate from the same CA.

Affected: - maven:io.netty:netty-handler-ssl-ocsp affected >=4.2.0.Final, <=4.2.17.Final; fixed unknown - maven:io.netty:netty-handler-ssl-ocsp affected >= 4.1.0.Final, <=4.1.137.Final; fixed unknown

Fixed versions: see advisory

Advisory: https://github.com/netty/netty/security/advisories/GHSA-jhjp-5q4f-8wr2

— Red Hat