CVE-2026-56821: Netty Auth Bypass Vulnerability

CVE-2026-56821 Overview

CVE-2026-56821 affects Netty, an asynchronous event-driven network application framework used widely across Java-based network services. The OcspServerCertificateValidator component flags an out-of-date Online Certificate Status Protocol (OCSP) response but continues processing it. An expired GOOD response is still reported as VALID. This behavior allows an on-path attacker to replay a stale GOOD response and bypass revocation of a certificate that has since been revoked. Any application relying on OcspServerCertificateValidator can accept a revoked certificate. The issue is fixed in Netty versions 4.1.136.Final and 4.2.16.Final.

Critical Impact
An on-path attacker can replay an expired OCSP GOOD response to bypass certificate revocation checks, causing Netty-based servers to accept a revoked TLS certificate.

Affected Products

Netty versions prior to 4.1.136.Final
Netty versions prior to 4.2.16.Final
Applications using OcspServerCertificateValidator for TLS certificate validation

Discovery Timeline

2026-07-29 - CVE-2026-56821 published to the National Vulnerability Database (NVD)
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-56821

Vulnerability Analysis

The vulnerability resides in Netty's OcspServerCertificateValidator, which validates X.509 certificates using OCSP responses. OCSP responses carry a validity window bounded by thisUpdate and nextUpdate fields. A correct validator must reject responses whose nextUpdate has passed. In vulnerable Netty releases, the validator detects the expired response and emits a warning flag, but the code path continues and still returns VALID when the OCSP status is GOOD. This weakness maps to CWE-299: Improper Check for Certificate Revocation. Applications that revoked a compromised or misissued certificate cannot rely on the validator to enforce that revocation.

Root Cause

The root cause is missing enforcement of OCSP response freshness. The validator inspects the nextUpdate field, identifies that the response is stale, but does not short-circuit the validation result. As a result, the status decision is based solely on the cached GOOD assertion rather than on a current, authoritative revocation state from the certificate authority's OCSP responder.

Attack Vector

An on-path attacker who previously captured a valid GOOD OCSP response for a target certificate can replay that response to a Netty-based server after the certificate has been revoked. Because the server treats the expired GOOD response as VALID, the revoked certificate is accepted for the TLS handshake. Exploitation requires network positioning and a previously observed OCSP response, which is why the attack complexity is high. No authentication or user interaction is required. The vulnerability is described in the Netty GitHub Security Advisory GHSA-g7hg-vrcf-mvmr.

Detection Methods for CVE-2026-56821

Indicators of Compromise

TLS sessions established with certificates whose serial numbers appear on the issuing certificate authority's current Certificate Revocation List (CRL).
OCSP responses observed with thisUpdate and nextUpdate timestamps significantly earlier than the current time being served to Netty endpoints.
Repeated identical OCSP response payloads (same nonce or signature) delivered across multiple sessions, indicating replay.

Detection Strategies

Inventory Java applications and identify use of Netty's OcspServerCertificateValidator through dependency analysis tools such as Software Composition Analysis (SCA) scanners.
Compare netty-handler versions in build manifests (pom.xml, build.gradle) against the fixed versions 4.1.136.Final and 4.2.16.Final.
Correlate TLS handshake logs with authoritative CRL or fresh OCSP queries to detect acceptance of revoked certificates.

Monitoring Recommendations

Log OCSP response thisUpdate, nextUpdate, and producer timestamps at the application layer for offline audit.
Alert on TLS peer certificates that resolve to revoked status when re-queried against the issuing CA out-of-band.
Monitor network traffic for anomalous OCSP response reuse patterns from the same client identity.

How to Mitigate CVE-2026-56821

Immediate Actions Required

Upgrade Netty to version 4.1.136.Final or 4.2.16.Final across all affected applications and rebuild dependent artifacts.
Audit all services that invoke OcspServerCertificateValidator and confirm they reject expired OCSP responses after the upgrade.
Rotate any certificates suspected of being accepted while revoked, and revalidate trust chains against a current CRL.

Patch Information

The Netty maintainers fixed the flaw in versions 4.1.136.Final and 4.2.16.Final. Refer to the Netty GitHub Security Advisory GHSA-g7hg-vrcf-mvmr for the full patch notes and commit references.

Workarounds

Implement an application-level check that rejects OCSP responses whose nextUpdate timestamp precedes the current time before trusting the certificate.
Use CRL-based revocation checking as a defense in depth alongside OCSP for high-value services.
Enforce OCSP stapling with must-staple certificates and validate stapled response freshness at the TLS termination layer.

bash

# Update Netty dependency in Maven pom.xml to the fixed version
mvn versions:set-property -Dproperty=netty.version -DnewVersion=4.1.136.Final
mvn clean verify