← research

1SEAL-2026-009: OpenSSL 3.6 stapled OCSP verification can accept unauthorized responders from the peer chain

high
HIGH CWE-295 openssl/openssl PR #30323 fixed on master and openssl-3.6 2026-03-29

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.0
  • openssl-3.6.1

confirmed not affected for this stapled-response path:

  • openssl-3.5.5 and earlier, where this check_cert_ocsp_resp() path is not present

patched versions

public upstream fixes:

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.0 or 3.6.1
  • your application enables X509_V_FLAG_OCSP_RESP_CHECK for stapled OCSP responses
  • you rely on stapled OCSP verification as a meaningful status or revocation control

root cause

  1. a TLS peer sends a certificate chain and a stapled OCSP response
  2. check_cert_ocsp_resp() passes the peer chain to OCSP_basic_verify() as responder candidate material
  3. the same call enables OCSP_TRUSTOTHER
  4. a certificate found in the presented chain can be treated as an acceptable OCSP responder signer
  5. an unauthorized signer from that chain, including the leaf certificate, can attest to good status 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 70e676bbc07558e59277392b392fb7e6a1930677 if 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).

references