08: CVE-2026-7009 fix incomplete for AWS-LC: `--cert-status` bypass on SecTrust path

How it was found

Summary

The fix for CVE-2026-7009 (commit 51905671e0) does not cover AWS-LC. In ossl_apple_verify() in lib/vtls/openssl.c, a missing OCSP staple is detected only when SSL_get_tlsext_status_ocsp_resp() returns a negative length. OpenSSL returns -1 for absence, but AWS-LC returns 0 with a NULL output pointer. On an AWS-LC + USE_APPLE_SECTRUST build, --cert-status silently accepts a certificate chain with no stapled OCSP response instead of failing with CURLE_SSL_INVALIDCERTSTATUS (91).

Root cause

ossl_apple_verify() in lib/vtls/openssl.c (lines 4752–4762):

long ocsp_len = 0;
bool ocsp_missing = FALSE;
if(conn_config->verifystatus && !octx->reused_session)
  ocsp_len = (long)SSL_get_tlsext_status_ocsp_resp(octx->ssl, &ocsp_data);

if(ocsp_len < 0) {
  ocsp_len = 0;
  ocsp_missing = TRUE;
}

AWS-LC declares SSL_get_tlsext_status_ocsp_resp as returning size_t. Its header (include/openssl/ssl.h) documents: "If there was no response, it sets |*out| to NULL and returns zero." The cast (long)0 is not < 0, so ocsp_missing stays FALSE.

The fallback verifystatus() check later in Curl_ossl_check_peer_cert() is also skipped because it is gated behind !octx->sectrust_verified (lines 4864–4868). Both layers of OCSP enforcement are bypassed.

Affected configuration

• curl built with AWS-LC as the OpenSSL backend (HAVE_BORINGSSL_LIKE)
• USE_APPLE_SECTRUST=ON (macOS, off by default)
• --cert-status / CURLOPT_SSL_VERIFYSTATUS enabled
• Fresh (non-reused) TLS session
• Server sends no OCSP staple

The CVE-2026-7009 advisory lists curl 8.20.0+ as unaffected and includes AWS-LC among affected backends, so the affected range may need revisiting.

Reproduction

1. Use curl 8.20.0 or 8.21.0 on macOS and build it against a current AWS-LC release with CURL_USE_OPENSSL=ON and USE_APPLE_SECTRUST=ON.
2. Confirm that the resulting binary reports both AWS-LC as its TLS backend and Apple SecTrust support.
3. Prepare an HTTPS test server with a hostname-valid certificate chain that Apple SecTrust accepts. A private test CA may be installed in a dedicated test keychain for this purpose.
4. Configure the server not to send a stapled OCSP response. Independently verify the absence of the TLS Certificate Status response with a TLS diagnostic client.
5. Ensure the test uses a fresh TLS connection without session resumption, because the affected check is performed for a non-reused session.
6. Connect with the AWS-LC-backed curl using the native CA store and require OCSP stapling with --cert-status or CURLOPT_SSL_VERIFYSTATUS.
7. Instrument ossl_apple_verify() or inspect it in a debugger and confirm that AWS-LC's SSL_get_tlsext_status_ocsp_resp() returns length zero and sets the response pointer to NULL.
8. Confirm that the affected condition checks only for a negative length, leaving ocsp_missing false for AWS-LC's zero-length result.
9. Observe the vulnerable result: Apple SecTrust accepts the otherwise trusted certificate chain and curl completes the transfer successfully despite the required OCSP staple being absent.
10. Change the missing-response test so that a non-positive length is treated as missing, rebuild curl, and repeat the request.
11. Observe the expected result: curl rejects the connection with CURLE_SSL_INVALIDCERTSTATUS and reports that no OCSP response was received.
12. As a regression control, configure the server to provide a valid, nonempty OCSP staple and repeat the request with the corrected build. Confirm that the valid response is still passed to SecTrust and the transfer succeeds.
13. Alternatively, verify the upstream correction by testing a revision containing commit c878bb36f8; the no-staple case must fail while the valid-staple case continues to work.

Expected result

When OCSP stapling is explicitly required, the absence of a response must terminate the connection with CURLE_SSL_INVALIDCERTSTATUS, regardless of the OpenSSL-compatible backend's return-value convention.

Vulnerable result

AWS-LC reports an absent response as (0, NULL), but curl checks only for a negative length. SecTrust can therefore accept the certificate chain and curl can complete the transfer without the required OCSP status.

Suggested fix

if(ocsp_len <= 0 || !ocsp_data) {
  ocsp_len = 0;
  ocsp_missing = TRUE;
}

This covers OpenSSL's -1 convention, AWS-LC's 0 + NULL convention, and any future backend that may signal absence differently.

Impact

Summary:

An attacker possessing a hostname-valid certificate and private key that SecTrust accepts—such as a revoked certificate whose status is not otherwise known locally—could impersonate the target without providing the required OCSP staple. This can enable interception or modification of TLS-protected traffic despite the client explicitly requesting certificate-status verification.