curl on Mac: macOS Still Ships 8.7.1, a March 2024 Build

Every Mac has curl built in, and on macOS 26.4.1 it is curl 8.7.1, released on March 27, 2024. Upstream is at 8.22.0, out September 2, 2026. Apple has kept the 8.7.1 label through every source drop it has published since August 2024, while backporting a handful of fixes underneath it.

The age is the obvious problem, but it isn't what surprised me most. I ran Apple's /usr/bin/curl next to Homebrew's 8.22.0 on the Mac mini M4 that runs this blog. Apple's build trusts the system keychain even when you pass --cacert. It rejects --tlsv1.3 as "not built-in" while it negotiates TLS 1.3 by default. Its --fail returns exit 56 over HTTP/2, where Homebrew's returns the documented 22. Nine options added since 8.7.1 fail with exit code 2. And 24 of curl's published advisories that cover 8.7.1 have no fix in Apple's records. Running brew install curl doesn't change any of that, because the curl you type is still Apple's.

Which curl does a Mac have?

$ /usr/bin/curl -V
curl 8.7.1 (x86_64-apple-darwin25.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.68.0
Release-Date: 2024-03-27
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL threadsafe UnixSockets

A few details in that output are easy to misread. The x86_64 in the first line is the build triple, not the CPU you're on. The binary is universal (x86_64 and arm64e), and the arm64e slice prints the same line. MultiSSL means libcurl has two TLS backends compiled in, and the one in parentheses is the inactive one. So Apple's curl talks TLS through LibreSSL 3.3.6 by default, not SecureTransport. Apple's curl.plist lists this as a local change: "On macOS, use openssl if present, secure-transport if not."

The protocol list has no scp, sftp, ws or wss, and the features have no HTTP3, brotli, zstd, IDN or PSL. With --compressed, Apple's curl sends Accept-Encoding: deflate, gzip, and Homebrew's adds br, zstd. The binary is signed as com.apple.curl on the sealed system volume, so you can't replace it, only put another curl ahead of it in PATH.

Apple's open source tags show how long the label has held. curl-156 (May 2024) was 8.6.0. curl-158 (August 2024) through curl-166.0.0.0.1 (June 2026) all define LIBCURL_VERSION "8.7.1".

--cacert doesn't limit trust

I generated a throwaway self-signed CA and passed it as the only trusted certificate for a request to www.cloudflare.com. That request should fail, because Cloudflare's certificate doesn't chain to my CA.

$ /usr/bin/curl -s --cacert mine.pem -o /dev/null -w '%{http_code}\n' https://www.cloudflare.com/
200
$ OPENSSL_X509_TEA_DISABLE=1 /usr/bin/curl -s --cacert mine.pem -o /dev/null https://www.cloudflare.com/; echo $?
60
$ /opt/homebrew/opt/curl/bin/curl -s --cacert mine.pem -o /dev/null https://www.cloudflare.com/; echo $?
60

Apple's LibreSSL falls back to the system trust store when verification against your CA file fails. Daniel Stenberg, curl's lead developer, reported this to Apple in December 2023 and published Apple's reply in March 2024: Apple considers the fallback intentional and won't change it. It still behaves that way on 26.4.1. If you use --cacert to pin a private CA, for example in a health check that should fail when someone swaps the certificate, Apple's curl will accept any publicly trusted certificate instead. Setting OPENSSL_X509_TEA_DISABLE=1, a variable a commenter on that post found in Apple's source, made it fail with exit 60 in my test. Forcing the SecureTransport backend also failed with 60.

--tlsv1.3 is "not built-in"

To test TLS version flags I ran two local openssl s_server instances from Homebrew's OpenSSL 3, one that only speaks TLS 1.3 and one that only speaks TLS 1.2, and pointed each curl at both. Exit codes:

curl	Flags	TLS 1.3-only server	TLS 1.2-only server
Apple, default (LibreSSL)	none	0	0
Apple, default (LibreSSL)	--tlsv1.3	4	4
Apple, CURL_SSL_BACKEND=secure-transport	none	35	0
Apple, CURL_SSL_BACKEND=secure-transport	--tlsv1.3	35	0
Homebrew 8.22.0	--tlsv1.3	0	35

The default backend negotiates TLS 1.3 without complaint, but asking for it explicitly returns exit 4, "A requested feature, protocol or option was not found built-in". A script that adds --tlsv1.3 as a hardening step breaks on every Mac. The SecureTransport row is worse. That backend can't speak TLS 1.3 at all, and --tlsv1.3, which means "at least 1.3", connected to the 1.2-only server and exited 0. Against Cloudflare it reported TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. Only Homebrew's curl did what the man page says on every combination.

Nine newer options fail with exit 2

I ran each option against a local file:// URL on both binaries. Version numbers are from the "Added in" line of Homebrew's curl man page.

Option	Added in	Apple 8.7.1
--http3, --http3-only	7.66 / 7.88	"installed libcurl version doesn't support this"
--ip-tos	8.9.0	unknown option
--skip-existing	8.10.0	unknown option
--sigalgs	8.14.0	unknown option
--follow	8.16.0	unknown option
--out-null	8.16.0	unknown option
--parallel-max-host	8.16.0	unknown option
--knownhosts	8.17.0	unknown option

Older options you might worry about are fine: --json, --url-query, --variable, --retry-all-errors, --etag-save and -w '%{certs}' all work on 8.7.1. The ones that bite are recent additions that show up in current documentation and in answers written against current curl. Copy a command that uses --follow or --out-null onto a Mac and it fails before sending a request.

Security fixes: 7 backported, 24 without a record

curl publishes every advisory as machine-readable JSON with the exact list of affected versions. On October 10, 2026 it had 215 entries, and 39 include 8.7.1. I sorted them against two Apple sources: the backport list in curl.plist and the curl entries in Apple's security notes for all 13 macOS Tahoe releases, 26 through 26.7.1.

Eight don't apply to Apple's build. Six need GnuTLS, wolfSSL, wolfSSH, libssh or SCP/SFTP support, which Apple doesn't compile in. CVE-2025-0725 only affects zlib 1.2.0.3 or older, and Apple ships 1.2.12.

Seven have an Apple fix. The plist lists backports for CVE-2024-9681, CVE-2024-7264, CVE-2025-14524, CVE-2025-14017 and CVE-2025-14819, and the macOS Tahoe 26.6 notes add CVE-2026-3783 and CVE-2026-3784. Only the first three were out by 26.4, so this machine, still on 26.4.1, has 28 without a fix on record.

The other 24 appear in neither source, nine rated Medium by curl. Two are from 2024: CVE-2024-6197, a stack-buffer free() in the certificate parser, and CVE-2024-11053, a netrc credential leak on redirect. Most of the 2026 ones need a specific setup, such as a proxy, Negotiate or Digest auth, netrc, or connection reuse across different settings. A plain curl https://… download hits few of them. "No record" also doesn't prove a bug is there. Apple could fix something without listing it. All I can say is that neither of Apple's public records mentions these 24.

Homebrew's curl is keg-only

After brew install curl, which -a curl on this machine still printed only /usr/bin/curl. The formula is keg-only, so it isn't linked into /opt/homebrew/bin. It's the same setup I hit with sqlite3 on Mac, and the opposite of jq on Mac, where Homebrew's copy does win when it's on PATH. To use the newer curl:

# interactive shells: ~/.zshrc
export PATH="/opt/homebrew/opt/curl/bin:$PATH"

# scripts and launchd jobs: call it by path
CURL=/opt/homebrew/opt/curl/bin/curl
"$CURL" -fsS --follow https://example.com/

The second form matters for anything that runs unattended. A launchd job starts with PATH=/usr/bin:/bin:/usr/sbin:/sbin, so a bare curl there is always Apple's. That applies to this business: there are 11 curl calls across 6 shell scripts in my ops/ directory, including the deploy check and the Telegram notifier that the launchd jobs call, and every one of them runs Apple's 8.7.1. I grepped them for --tlsv1.3, --cacert, --follow and the other options above, and none use them, which is why I hadn't noticed any of this.

One difference I had already run into without knowing its cause. In August I wrote that curl --fail returns exit code 56 instead of 22 over HTTP/2. I only had Apple's curl then. With both binaries side by side, it turns out to be specific to Apple's 8.7.1:

$ /usr/bin/curl -fsS -o /dev/null https://httpbingo.org/status/404; echo $?
curl: (56) The requested URL returned error: 404
56
$ /opt/homebrew/opt/curl/bin/curl -fsS -o /dev/null https://httpbingo.org/status/404; echo $?
curl: (22) The requested URL returned error: 404
22

I got the same split on three URLs that return 404 or 500. With --http1.1, both binaries return 22. The timeout code from curl exit code 28 is 28 on both.

My recommendation: keep Apple's curl for quick manual requests. Call Homebrew's curl by full path in any script that pins a CA with --cacert, sets a minimum TLS version, or uses an option from the table above. The same goes for scripts that should get upstream security fixes on curl's schedule, not on whatever schedule Apple uses.

FAQ

What version of curl comes with macOS?

macOS 26.4.1 ships curl 8.7.1, released by curl on March 27, 2024, built against LibreSSL 3.3.6 with SecureTransport as a second TLS backend. Apple's published source has carried the 8.7.1 label since August 2024 and backports some security fixes under it. The current upstream release is 8.22.0, from September 2, 2026.

How do I update curl on a Mac?

You can't replace /usr/bin/curl because it is on the sealed system volume. Run brew install curl, then put /opt/homebrew/opt/curl/bin at the front of PATH or call /opt/homebrew/opt/curl/bin/curl directly. The Homebrew formula is keg-only, so a plain curl command keeps running Apple's version until you change PATH. launchd jobs always get Apple's curl unless they use the full path.

Why does curl on Mac ignore --cacert?

Apple's LibreSSL falls back to the macOS system trust store when a certificate fails verification against the --cacert file, so any publicly trusted certificate is still accepted. Apple told curl's maintainer in 2024 that this is intentional. Setting OPENSSL_X509_TEA_DISABLE=1, or using Homebrew's curl, makes --cacert the only trust source, and the request fails with exit 60 when the certificate doesn't match.

Method: I ran every test on a Mac mini M4 (Mac16,10, 16 GB) on macOS 26.4.1 (25E253) on October 10, 2026, comparing /usr/bin/curl with Homebrew's curl 8.22.0 (OpenSSL 3.6.5). The TLS tests used a throwaway P-256 self-signed certificate and two local openssl s_server instances, one limited to TLS 1.3 and one to TLS 1.2, plus live requests to www.cloudflare.com. I tested each option against a file:// URL and recorded exit codes, and ran --fail against three URLs returning 404 or 500, forcing HTTP/2 and then HTTP/1.1. Advisory counts come from curl's vuln.json as fetched on October 10, 2026. Apple's backports come from curl.plist and curlver.h at the apple-oss-distributions/curl tags curl-152 through curl-166.0.0.0.1, and from the curl entries in Apple's security notes for macOS Tahoe 26 through 26.7.1. I didn't test Intel Macs, any macOS version other than 26.4.1, or whether each of the 24 unrecorded advisories can actually be triggered in Apple's build.