curl is one of the most popular command-line tools for transferring data, used everywhere from simple downloads to enterprise scripts and critical infrastructure. It’s known for being flexible and strong on security—thanks, in part, to its support for HSTS (HTTP Strict Transport Security). But a sneaky vulnerability, assigned CVE-2023-23915, shows how a subtle mistake can bring it all crashing down under certain conditions.

In this long read, we’ll break down what CVE-2023-23915 is, how it works, why it matters, and how attackers could take advantage of it. If you write scripts, work in devops, or just use curl, you need to know about this vulnerability!

What is CVE-2023-23915?

CVE-2023-23915 is a “cleartext transmission of sensitive information” bug in curl affecting all versions before v7.88.. It specifically targets curl’s HSTS feature when multiple transfers happen at once (in parallel). This can result in a false sense of security—and, in some cases, actual exposure of confidential data in plain HTTP.

What is HSTS?

HSTS (HTTP Strict Transport Security) is a security policy that tells browsers (and tools like curl) to always use HTTPS for certain sites—even if someone tries to connect with plain HTTP. This means if a site tells curl “only use HTTPS for me!”, it should remember that and never use ordinary HTTP.

In code

curl --hsts my_hsts_cache.txt -L http://secure.example.com


Even if you provide http://..., curl will “upgrade” to HTTPS if HSTS has been previously set for the server.

Where’s the Problem?

When you do multiple downloads at once (like with xargs or in curl’s parallel mode), curl’s HSTS information can get lost or overwritten. Here’s how:

Whichever transfer finishes last writes out its memory copy, overwriting others.

If one transfer learned that a hostname is HTTPS-only (due to HSTS), and another did not, then the last one to finish will set the rules for *all* future curl runs. If the last transfer didn’t see the HSTS rule, curl will forget it ever existed.

In practice: Curl forgets to upgrade certain risky HTTP URLs to HTTPS, potentially exposing data like logins, tokens, or any sensitive info that should have been protected by TLS.

Code Snippet: The Issue in Action

Let's simulate the vulnerability. Suppose you already have a HSTS cache (curl.hsts) that says secure.example.com must use HTTPS.

# Initially, we set up HSTS for secure.example.com
curl --hsts curl.hsts https://secure.example.com

# Now run TWO downloads in parallel, one to a site enforcing HSTS, one not
printf "http://secure.example.com\nhttp://regular.example.com" | \
xargs -n 1 -P 2 -I % curl --hsts curl.hsts -O %

# Now, curl.hsts might have been overwritten by the last transfer
# Let's fetch insecurely again...
curl --hsts curl.hsts http://secure.example.com

Result: If regular.example.com finished last, your HSTS data may be gone, and curl won’t upgrade secure.example.com to HTTPS. Your request is sent *insecurely*—clear as day on the network.

Exploit Details: How Could an Attacker Abuse This?

An attacker isn’t going to abuse the bug *directly*—it’s more about circumventing your expectations of security in automated scripts.

The next time you request from your private server, curl forgets it should use HTTPS.

- Your request, including *credentials or tokens*, might go out over HTTP, and could be sniffed or MITM’d (man-in-the-middle attacked).

If the attacker can manipulate the timing of requests (say, by slowing down or speeding up certain responses), they can increase the chance your HSTS data is forgotten.

#### In real-world devops pipelines, if you use curl’s HSTS for many parallel tasks, don’t count on it for protection in versions before v7.88.!

How Was This Fixed?

From curl 7.88. and later, the HSTS cache file is written safely so that parallel transfers can’t unexpectedly clobber each other’s rules. This usually means atomic writes and stricter serialization of access.

You can find the fix in the curl changelog and the specific CVE announcement:
- CVE-2023-23915 - HSTS bypass with parallel transfers
- curl commit that addresses the bug

How to Protect Yourself

- Upgrade to curl v7.88. or newer! Always use the most recent version of curl, especially on production or automated systems.

Don’t trust the HSTS cache for critical upgrades in parallel scripts on vulnerable versions.

- Avoid writing to the same HSTS file in parallel curl invocations—split your jobs, or use separate files if you can’t upgrade.

Conclusion

CVE-2023-23915 is a reminder: even powerful security features can fail for subtle reasons—here, an easy-to-miss race in how an on-disk cache is handled during parallel work. If you rely on curl’s HSTS support, especially in scripts or automation (CI/CD, backups, etc), make sure you’ve patched!

Original References

- Official cURL CVE-2023-23915 advisory
- curl 7.88. release notes
- Commit with the bugfix


*Written exclusively for you. Stay safe out there in the command line!*

Timeline

Published on: 02/23/2023 20:15:00 UTC
Last modified on: 03/09/2023 19:15:00 UTC