1SEAL-2026-009: OpenSSL 3.6 stapled OCSP verification can accept unauthorized responders from the peer chain
summary
OpenSSL 3.6 introduced a stapled OCSP verification path in
check_cert_ocsp_resp() that called
OCSP_basic_verify(bs, ctx->chain, ctx->store, OCSP_TRUSTOTHER).
that combination is unsafe for stapled responses. ctx->chain is the
peer-provided certificate chain, not a trusted OCSP responder store. passing it as the
responder candidate set while also enabling OCSP_TRUSTOTHER collapses the
boundary between the certificate being validated and the authority allowed to attest to
its revocation status.
in affected deployments, a remote TLS server can staple a fabricated good
OCSP response signed by an unauthorized certificate from the presented chain, including
the leaf certificate itself, and have that response accepted when the consumer enables
X509_V_FLAG_OCSP_RESP_CHECK.
vendor classification
OpenSSL publicly triaged
PR #30323 as
triaged: bug rather than a security advisory.
this advisory disagrees with the non-security classification for affected deployments,
but agrees that exposure is narrower than a generic “all OpenSSL users are affected”
framing. the vulnerable path is real, remotely reachable, and security-relevant, but it
is mode-dependent on X509_V_FLAG_OCSP_RESP_CHECK being enabled and confined
to the 3.6 stapled-response verifier.
severity
HIGH in affected deployments.
CWE: CWE-295 (Improper Certificate Validation)
no CVE or OpenSSL security advisory had been published as of 2026-03-29.
why this still matters:
- the attacker is a remote TLS peer
- the bypass affects revocation and certificate status decisions
- the acceptance condition is deterministic once OCSP response checking is enabled
- the public regression test in PR #30323 now enforces the negative case that previously passed
affected versions
confirmed affected for the network-exposed stapled OCSP verification path:
openssl-3.6.0openssl-3.6.1
confirmed not affected for this stapled-response path:
openssl-3.5.5and earlier, where thischeck_cert_ocsp_resp()path is not present
patched versions
public upstream fixes:
master:8a630915c045212b8b2fb82c29107979cd5bba84openssl-3.6:70e676bbc07558e59277392b392fb7e6a1930677
openssl-4.0.0-beta1
contains the fix.
am i affected?
you are affected by the core issue if all of the following are true:
- you use OpenSSL
3.6.0or3.6.1 - your application enables
X509_V_FLAG_OCSP_RESP_CHECKfor stapled OCSP responses - you rely on stapled OCSP verification as a meaningful status or revocation control
root cause
- a TLS peer sends a certificate chain and a stapled OCSP response
check_cert_ocsp_resp()passes the peer chain toOCSP_basic_verify()as responder candidate material- the same call enables
OCSP_TRUSTOTHER - a certificate found in the presented chain can be treated as an acceptable OCSP responder signer
- an unauthorized signer from that chain, including the leaf certificate, can attest to
goodstatus in the affected path
exploitation
the report included a deterministic end-to-end local TLS handshake showing that a fabricated stapled OCSP response signed by an unauthorized chain certificate could still be accepted when OCSP response checking was enabled.
the public regression test in PR #30323 captures the simplest variant of the same bug class: a leaf-signed stapled OCSP response must fail, and after the fix it does.
fix
the main fix is a one-line trust decision change in the stapled-response verifier:
before:
OCSP_basic_verify(bs, ctx->chain, ctx->store, OCSP_TRUSTOTHER)
after:
OCSP_basic_verify(bs, ctx->chain, ctx->store, 0)
the merged fix also updates apps/ocsp.c so it respects
verify_flags instead of unconditionally forcing OCSP_TRUSTOTHER.
workarounds
- backport
70e676bbc07558e59277392b392fb7e6a1930677if you maintain a 3.6.0/3.6.1 deployment - review whether your application enables
X509_V_FLAG_OCSP_RESP_CHECK - avoid treating peer-provided chain certificates as trusted OCSP responder material in custom verification logic
timeline
| date | event |
|---|---|
| 2026-02-14 | reported privately to OpenSSL |
| 2026-03-09 | OpenSSL triages the issue as a regular bug and requests a public PR |
| 2026-03-09 | public PR #30323 opened |
| 2026-03-21 | fix merged to master and openssl-3.6 |
| 2026-03-24 | openssl-4.0.0-beta1 released with the fix |
| 2026-03-29 | public advisory; no OpenSSL security advisory or CVE observed as of this date |
credit
discovered and reported by Oleh Konko (1seal).