CVE-2026-56820: Netty Auth Bypass Vulnerability

CVE-2026-56820 Overview

CVE-2026-56820 is an improper certificate validation vulnerability [CWE-295] in Netty, a widely deployed network application framework for building protocol servers and clients in Java. The OcspClient.validateResponse method fails to verify that the CertificateID returned in an Online Certificate Status Protocol (OCSP) response matches the CertificateID originally requested. As a result, a legitimately signed GOOD status response for one certificate can be replayed to bypass revocation checks for a different certificate issued by the same Certificate Authority (CA). The flaw affects Netty versions 4.2.0.Final through 4.2.15.Final and all releases prior to 4.1.135.Final.

Critical Impact
Attackers who possess a valid OCSP GOOD response for any certificate from the same CA can replay it to make Netty accept a revoked certificate, undermining TLS trust guarantees.

Affected Products

Netty 4.2.0.Final through 4.2.15.Final
Netty versions prior to 4.1.135.Final
Applications embedding Netty's OcspClient for TLS certificate revocation checking

Discovery Timeline

2026-07-21 - CVE-2026-56820 published to NVD
2026-07-22 - Last updated in NVD database

Technical Details for CVE-2026-56820

Vulnerability Analysis

The vulnerability resides in Netty's OcspClient implementation, which is used by TLS clients to verify whether a peer's X.509 certificate has been revoked. When an OCSP responder returns a signed response, OcspClient.validateResponse verifies the signature and the GOOD status flag but omits a critical binding check: it does not compare the CertificateID inside the response against the CertificateID submitted in the request.

Because OCSP responses are typically signed by the issuing CA (or a delegated responder), any legitimately issued GOOD response for a certificate from that CA carries a valid signature chain. Netty accepts these responses as authoritative for whichever certificate is currently being validated, enabling a cross-certificate replay attack.

An attacker holding a revoked certificate can pair it with a stapled or intercepted OCSP GOOD response for a different, unrelated certificate signed by the same CA. The revocation check silently succeeds, and Netty proceeds with the TLS handshake as if the presented certificate were valid.

Root Cause

The root cause is missing validation logic in OcspClient.validateResponse. The method does not enforce that response fields such as issuerNameHash, issuerKeyHash, and serialNumber (which together form the CertificateID) match the values from the outbound OCSP request. RFC 6960 explicitly requires this binding to prevent response substitution.

Attack Vector

Exploitation requires an attacker to obtain a revoked or attacker-controlled certificate signed by a CA that has previously issued at least one other certificate for which a valid GOOD OCSP response can be captured. The attacker then presents the revoked certificate during a TLS handshake while supplying the unrelated GOOD response via OCSP stapling or by controlling the responder path. Because the response is signature-valid, Netty's revocation check passes.

No authentication is required, the attack is network-reachable, and both confidentiality and integrity of subsequent TLS-protected traffic are at risk. The high attack complexity reflects the requirement to obtain a matching signed OCSP response.

See the GitHub Security Advisory GHSA-272m-gcwp-mpwg and the upstream fix commits (5b68c61 and bb2ff68) for the corrective changes shipped alongside this advisory.

Detection Methods for CVE-2026-56820

Indicators of Compromise

TLS sessions where a Netty-based client accepts a peer certificate whose serial number appears on the issuing CA's Certificate Revocation List (CRL).
OCSP responses observed on the wire whose CertificateID (issuer name hash, issuer key hash, serial number) does not match the CertificateID in the preceding OCSP request.
Repeated reuse of an identical stapled OCSP response across TLS handshakes involving different end-entity certificates from the same CA.

Detection Strategies

Inventory Java applications and libraries that depend on Netty and identify versions in the vulnerable ranges (4.2.0.Final–4.2.15.Final and any release prior to 4.1.135.Final).
Use software composition analysis (SCA) tooling to flag transitive dependencies on vulnerable Netty artifacts in Maven and Gradle builds.
Instrument TLS clients to log OCSP request/response CertificateID pairs and alert on mismatches.

Monitoring Recommendations

Enable verbose TLS handshake logging on Netty-based services and forward the events to a centralized analytics platform for correlation.
Monitor certificate revocation events from managed public key infrastructure (PKI) and correlate against services still accepting the revoked serials.
Track outbound OCSP traffic patterns and alert on responses that lack a matching outstanding request.

How to Mitigate CVE-2026-56820

Immediate Actions Required

Upgrade Netty to 4.1.136.Final or 4.2.16.Final, which add the missing CertificateID comparison in OcspClient.validateResponse.
Rebuild and redeploy all downstream applications and container images that bundle vulnerable Netty versions.
Rotate and reissue any certificates whose revocation status may have been bypassed while vulnerable versions were in production.

Patch Information

The issue is resolved in Netty 4.1.136.Final and 4.2.16.Final. The corrective code is delivered in commits 5b68c61 and bb2ff68. Users should update the io.netty:netty-all or individual Netty module dependencies in their build manifests and verify the resolved version at runtime.

Workarounds

Disable use of Netty's built-in OcspClient and delegate OCSP verification to a hardened library that enforces CertificateID matching until patches can be applied.
Enforce short-lived certificates and CRL-based revocation checking as a compensating control where OCSP stapling cannot be trusted.
Restrict trusted CAs to a minimal set to reduce the pool of certificates that could be used to source a replay-capable GOOD response.

bash

# Configuration example: update Netty dependency to a patched release
# Maven (pom.xml)
# <dependency>
#   <groupId>io.netty</groupId>
#   <artifactId>netty-all</artifactId>
#   <version>4.1.136.Final</version>
# </dependency>

# Gradle (build.gradle)
# implementation 'io.netty:netty-all:4.2.16.Final'

# Verify the resolved version on the classpath
mvn dependency:tree | grep netty
./gradlew dependencies | grep netty