# Netty: Missing CertificateID Validation in OCSP Response Allows Replay Attacks

Netty's OcspClient ignores the CertificateID in OCSP responses, letting an attacker replay a GOOD response from the same CA to bypass revocation checks.

- Payout: Research
- Severity: high
- Program: Netty
- Found by: violetagg
- Disclosed: 2026-07-22
- CVE: CVE-2026-56820
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-272m-gcwp-mpwg
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-272m-gcwp-mpwg
- Tags: area:oss domain:oss impact:integrity kind:research platform:ghsa sev:high tech:java technique:source-review vuln:auth-bypass vuln:crypto

**Target:** OCSP client in netty-handler-ssl-ocsp (io.netty.handler.ssl.ocsp.OcspClient#validateResponse)
**Root cause:** validateResponse verifies the response signature against the trusted issuer but never asserts that the CertificateID inside the BasicOCSPResp matches the certificate serial/issuer hash sent in the request, violating RFC 6960 §3.2.
**Steps:**
1. Obtain any valid non-revoked certificate issued by the same CA as the target certificate.
2. Fetch a legitimately signed OCSP GOOD response for that unrelated certificate from the CA's responder.
3. When the Netty client queries the target (e.g. revoked) certificate, return the cached GOOD response instead.
4. Client verifies signature OK, ignores CertificateID, and accepts the revoked cert as valid (PoC testCertIdBypass in OcspClientTest).
**How found:** Reporter compared OcspClient#validateResponse against RFC 6960 §3.2 requirement that the response certificate identity match the request, spotting the missing CertificateID assertion, then built a test with a forged response for an unrelated cert.
**Exploitation:** Attacker with a valid cert from the same CA pre-fetches its GOOD OCSP response, then serves it as the OCSP reply for any other certificate from that CA (e.g. via MITM or controlling the responder URL), defeating revocation checking.
**Insight:** When auditing OCSP/CRL validation, check that the response's CertID (serial + issuer hash) is compared to the request, not just the signature — signature-only checks enable cross-certificate replay within the same CA.