CVE-2026-56821

Netty's OcspServerCertificateValidator (CWE-299, improper certificate revocation check) detects when a received OCSP response is out of date but does not stop processing it, so an expired 'GOOD' OCSP response is still reported as VALID. An attacker positioned on the network path (man-in-the-middle) can replay a stale 'GOOD' response for a certificate that has since been revoked, and the application accepts the now-revoked certificate because the validation logic treats the replayed response as valid. The attacker gains a bypass of certificate revocation checks — for example, a certificate revoked after key compromise could still be used to impersonate the legitimate service — with high impact on confidentiality and integrity (CVSS 3.1: 7.4, high) and no availability impact. Any application embedding Netty before 4.1.136.Final or 4.2.16.Final and using OcspServerCertificateValidator is affected; deployments that do not use this validator are not exposed to this flaw. No in-the-wild exploitation is reported: the flaw is documented in a public GitHub security advisory, it is not in CISA KEV, and EPSS estimates only a 0.2% chance of exploitation within 30 days.

What to do: Upgrade to Netty 4.1.136.Final (4.1.x line) or 4.2.16.Final (4.2.x line), which correctly reject out-of-date OCSP responses. Audit your TLS client configuration for use of OcspServerCertificateValidator — applications that do not use this validator are not affected. Until you can upgrade, consider disabling OCSP stapling via the validator as an interim mitigation.