Netty CVE-2026-56820

Exploitation requires that the target application uses Netty's OcspClient (netty-handler-ssl-ocsp) to perform OCSP revocation checks, and that the attacker (1) possesses a valid, non-revoked certificate issued by the SAME CA as the certificate being validated and (2) can obtain a legitimately CA-signed GOOD OCSP response for that unrelated certificate. The attacker must also be able to deliver that response to the Netty client during its validation flow, which in practice means occupying a man-in-the-middle or malicious-server position for the target certificate they wish to have wrongly accepted. Limiting factors: the OcspClient feature must be actively in use (it is optional and not enabled by default in most deployments), both certificates must share one issuing CA, and the attack only defeats revocation status - it does not by itself forge signatures or break TLS key exchange, so its payoff depends on the attacker already holding a revoked/compromised certificate they want honored.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, 9.1) rates this critical, but that AC:L likely overstates ease: a successful replay requires the attacker to already possess a valid non-revoked certificate from the same CA AND to be positioned to serve the forged OCSP response to the target (typically a man-in-the-middle or malicious-server role), which is meaningful added complexity - hence my independent assessment lowers complexity to AC:H. SSVC signals (Exploitation: PoC, Automatable: yes, Technical Impact: total) and the confirmed public PoC raise attention, yet EPSS is only 0.30% (22nd percentile) and there is no CISA KEV listing, consistent with a defense-weakening bug rather than a directly wormable RCE. This is a real, prioritize-if-you-use-OCSP issue - it silently defeats revocation checking, a security control - but its practical exploitability is gated by the same-CA-certificate and interception prerequisites, so it is not a mass-exploitation, high-EPSS emergency. Note the conflict to verify: the vendor rates AC:L while the described attack implies a privileged network position and cert-possession requirement.

An attacker who legitimately obtains any non-revoked certificate from CA X (e.g., their own domain cert) queries that CA and captures a signed GOOD OCSP response for it. When a Netty-based client later checks the status of a different, revoked certificate also issued by CA X - such as a stolen or compromised server certificate the attacker is presenting during a man-in-the-middle - the attacker returns the captured GOOD response; Netty validates the signature, ignores the mismatched CertificateID, and accepts the revoked certificate. A working PoC (OcspClientTest.testCertIdBypass) is published in the GHSA advisory.