# CVE-2020-8286: Inferior OCSP verification

curl's OpenSSL backend failed to match the serial number in a stapled OCSP response to the peer certificate, so a revoked cert could pass validation.

- Payout: hidden
- Severity: medium
- Program: curl
- Found by: ospoco
- Disclosed: 2020-12-09
- CVE: CVE-2020-8286
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/1048457
- Library page: https://bugbountylibrary.com/r/h1%3A1048457
- Tags: area:oss domain:oss impact:integrity kind:bounty platform:hackerone sev:medium tech:curl technique:source-review vuln:crypto

**Target:** TLS/OCSP validation in lib/vtls/openssl.c
**Root cause:** curl does not verify that the certificate serial number in the stapled OCSP response matches the serial number of the peer certificate being validated, so any valid OCSP response from the same issuer is accepted.
**Steps:**
1. Identify a site with a revoked certificate, e.g. `https://revoked.grc.com`.
2. Obtain a valid OCSP response for a different site signed by the same issuer: `openssl ocsp -issuer grc_chain.pem -cert grc_cert.pem -text -url http://ocsp.digicert.com -respout grc_ocsp_resp.der`.
3. Run `./curl_ocsp_vuln_test https://revoked.grc.com` — curl correctly fails with 'SSL server certificate status verification FAILED'.
4. Re-run with the substituted response: `./curl_ocsp_vuln_test https://revoked.grc.com --replace_ocsp grc_ocsp_resp.der` — curl succeeds and returns the page.
**How found:** Code reading of /lib/vtls/openssl.c revealed the OCSP response serial number was never compared against the peer certificate serial; confirmed by crafting a test program that swaps in an OCSP response from a same-issuer valid site.
**Exploitation:** An attacker who can intercept traffic (MITM) to a site whose certificate is revoked but shares an issuer with any valid site substitutes a valid OCSP response from that issuer; curl accepts the revoked certificate and establishes a 'validated' connection to the attacker-controlled endpoint.
**Insight:** When auditing OCSP stapling, check that the response's CertID (issuer hash + serial) is bound to the peer cert, not just that the response signature verifies — same-issuer responses are interchangeable otherwise.