https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 20:44:05 +0000 https://db.gcve.eu/vuln/ghsa-272m-gcwp-mpwg <p><strong>Affected:</strong> Maven: io.netty:netty-handler-ssl-ocsp</p> <p>### Summary Netty&#39;s OcspClient does not validate that the CertificateID in an OCSP response matches the requested CertificateID. A bad actor can replay a `GOOD` status response issued for an unrelated certificate (by the same CA) to bypass revocation checks for any certificate.</p> <p>### Details `io.netty.handler.ssl.ocsp.OcspClient#validateResponse` fails to assert that the CertificateID within the returned `BasicOCSPResp` matches the original certificate being validated.</p> <p>When `OcspClient.query(...)` executes, it builds an OCSP request using the victim certificate&#39;s serial number and issuer hash. It then sends this request and receives a response. While the client verifies the signature of the response against the trusted issuer (or a valid responder chain), it never checks the CertificateID inside the response payload.</p> <p>A bad actor who has access to any other valid, non-revoked certificate issued by the same CA can obtain a legitimately signed OCSP response indicating that the unrelated certificate is `GOOD`. The bad actor can then return this valid response to the Netty client when it queries the status of any other certificate (e.g., a revoked certificate) issued by the same CA. Because the signature is valid (signed by the CA) and the CertificateID is ignored, the client will incorrectly accept the target certificate as valid.</p> <p>As per https://datatracker.ietf.org/doc/html/rfc6960#section-3.2 we have:</p> <p>``` Prior to accepting a signed response for a particular certificate as…</p> <p><strong>Affected:</strong> Maven: io.netty:netty-handler-ssl-ocsp</p> <p>### Summary Netty&#39;s OcspClient does not validate that the CertificateID in an OCSP response matches the requested CertificateID. A bad actor can replay a `GOOD` status response issued for an unrelated certificate (by the same CA) to bypass revocation checks for any certificate.</p> <p>### Details `io.netty.handler.ssl.ocsp.OcspClient#validateResponse` fails to assert that the CertificateID within the returned `BasicOCSPResp` matches the original certificate being validated.</p> <p>When `OcspClient.query(...)` executes, it builds an OCSP request using the victim certificate&#39;s serial number and issuer hash. It then sends this request and receives a response. While the client verifies the signature of the response against the trusted issuer (or a valid responder chain), it never checks the CertificateID inside the response payload.</p> <p>A bad actor who has access to any other valid, non-revoked certificate issued by the same CA can obtain a legitimately signed OCSP response indicating that the unrelated certificate is `GOOD`. The bad actor can then return this valid response to the Netty client when it queries the status of any other certificate (e.g., a revoked certificate) issued by the same CA. Because the signature is valid (signed by the CA) and the CertificateID is ignored, the client will incorrectly accept the target certificate as valid.</p> <p>As per https://datatracker.ietf.org/doc/html/rfc6960#section-3.2 we have:</p> <p>``` Prior to accepting a signed response for a particular certificate as…</p> https://db.gcve.eu/vuln/ghsa-272m-gcwp-mpwg