HackerOne Bug Bounty Disclosure: apple-sectrust-fallback-ignores-curlopt-crlfile-letting-a-revoked-cert-pass

Report title Apple SecTrust fallback ignores CURLOPT_CRLFILE, letting a revoked cert pass

Report link

Date submitted 2026-09-08T06:14:44.082Z

### What Is the Issue?

On Apple platforms, curl can use Apple’s native **SecTrust** system to verify TLS certificates. The report found that this fallback verification can ignore a certificate revocation list supplied through `CURLOPT_CRLFILE` or the command-line option `–crlfile`.

As a result, curl may continue connecting to a server even when its certificate is explicitly listed as revoked in the CRL file provided by the application.

### How Does the Bug Happen?

When curl checks a certificate with OpenSSL or GnuTLS, the configured CRL file is used to detect revoked certificates. Normally, a revoked certificate causes verification to fail.

However, when curl is built with Apple SecTrust support and is using the system’s native certificate store, curl may pass the failed verification to Apple’s SecTrust API. SecTrust is not given the custom CRL file, so it performs an independent check without knowing the operator’s private revocation list.

If Apple’s own trust and revocation checks succeed, curl treats the certificate as valid and allows the TLS connection to continue.

### When Is the Vulnerability Triggered?

The issue requires several conditions:

curl is built with Apple SecTrust support.

The native Apple certificate store is being used.

The application sets `CURLOPT_CRLFILE`, or the user runs curl with `–crlfile`.

OpenSSL or GnuTLS rejects the certificate because of the CRL.

Apple’s SecTrust system does not independently know that the certificate has been revoked.

This is especially relevant for private, internal, or corporate certificate authorities whose revocation information is not available to Apple’s trust services.

### Demonstrated Impact

The proof of concept creates a private certificate authority, issues a certificate, revokes it using a CRL, and serves the revoked certificate from a local HTTPS server.

Despite supplying the CRL to curl, the vulnerable configuration allows the connection to succeed. In the demonstrated case, curl completes the TLS handshake and receives an HTTP response from the server instead of rejecting the revoked certificate.

`CURLOPT_CRLFILE` is an explicit security control. Applications use it when they need to reject certificates listed on a private or locally managed revocation list.

Ignoring that list can cause an application to trust a certificate that its operator has deliberately revoked. This could allow continued connections to compromised, decommissioned, or otherwise unauthorized servers.

### What Caused the Regression?

Earlier versions of the Apple SecTrust fallback only activated for a specific OpenSSL verification error. A later change broadened the fallback so that Apple SecTrust was consulted after any OpenSSL verification failure when the native certificate store was enabled.

That broader behavior included CRL-related failures, even though Apple SecTrust was never given the custom CRL file. The change therefore allowed Apple’s successful verification to override the caller’s failed CRL check.

The Apple SecTrust fallback should not run when a custom CRL file is configured, unless SecTrust can be given equivalent revocation information.

At minimum, curl should fail closed when `CURLOPT_CRLFILE` rejects a certificate. Another possible fix is to restore a narrower fallback condition that excludes CRL-related verification failures.

### Overall Assessment

This is a certificate-revocation bypass affecting specific Apple curl builds and configurations. It does not defeat all TLS verification, but it can undermine an explicitly configured CRL policy. Applications that rely on `CURLOPT_CRLFILE` should ensure that their curl version includes a fix or disable the affected native SecTrust fallback until one is available.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.

HackerOne report summary

Programme

Submitted by Anteater

Profile

Report title Apple SecTrust fallback ignores CURLOPT_CRLFILE, letting a revoked cert pass

Report link

Date submitted 2026-09-08T06:14:44.082Z

### What Is the Issue?

On Apple platforms, curl can use Apple’s native **SecTrust** system to verify TLS certificates. The report found that this fallback verification can ignore a certificate revocation list supplied through `CURLOPT_CRLFILE` or the command-line option `–crlfile`.

As a result, curl may continue connecting to a server even when its certificate is explicitly listed as revoked in the CRL file provided by the application.

### How Does the Bug Happen?

When curl checks a certificate with OpenSSL or GnuTLS, the configured CRL file is used to detect revoked certificates. Normally, a revoked certificate causes verification to fail.

However, when curl is built with Apple SecTrust support and is using the system’s native certificate store, curl may pass the failed verification to Apple’s SecTrust API. SecTrust is not given the custom CRL file, so it performs an independent check without knowing the operator’s private revocation list.

If Apple’s own trust and revocation checks succeed, curl treats the certificate as valid and allows the TLS connection to continue.

### When Is the Vulnerability Triggered?

The issue requires several conditions:

curl is built with Apple SecTrust support.

The native Apple certificate store is being used.

The application sets `CURLOPT_CRLFILE`, or the user runs curl with `–crlfile`.

OpenSSL or GnuTLS rejects the certificate because of the CRL.

Apple’s SecTrust system does not independently know that the certificate has been revoked.

This is especially relevant for private, internal, or corporate certificate authorities whose revocation information is not available to Apple’s trust services.

### Demonstrated Impact

The proof of concept creates a private certificate authority, issues a certificate, revokes it using a CRL, and serves the revoked certificate from a local HTTPS server.

Despite supplying the CRL to curl, the vulnerable configuration allows the connection to succeed. In the demonstrated case, curl completes the TLS handshake and receives an HTTP response from the server instead of rejecting the revoked certificate.

`CURLOPT_CRLFILE` is an explicit security control. Applications use it when they need to reject certificates listed on a private or locally managed revocation list.

Ignoring that list can cause an application to trust a certificate that its operator has deliberately revoked. This could allow continued connections to compromised, decommissioned, or otherwise unauthorized servers.

### What Caused the Regression?

Earlier versions of the Apple SecTrust fallback only activated for a specific OpenSSL verification error. A later change broadened the fallback so that Apple SecTrust was consulted after any OpenSSL verification failure when the native certificate store was enabled.

That broader behavior included CRL-related failures, even though Apple SecTrust was never given the custom CRL file. The change therefore allowed Apple’s successful verification to override the caller’s failed CRL check.

The Apple SecTrust fallback should not run when a custom CRL file is configured, unless SecTrust can be given equivalent revocation information.

At minimum, curl should fail closed when `CURLOPT_CRLFILE` rejects a certificate. Another possible fix is to restore a narrower fallback condition that excludes CRL-related verification failures.

### Overall Assessment

This is a certificate-revocation bypass affecting specific Apple curl builds and configurations. It does not defeat all TLS verification, but it can undermine an explicitly configured CRL policy. Applications that rely on `CURLOPT_CRLFILE` should ensure that their curl version includes a fix or disable the affected native SecTrust fallback until one is available.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.