The security of internet communications is a vital concern. HTTP Strict Transport Security (HSTS) is one way we secure web traffic by forcing browsers and tools to use HTTPS instead of insecure HTTP. In popular tools like curl, HSTS makes it simple: if you’ve accessed a website over HTTPS once, curl remembers to always use HTTPS for that site. But back in 2022, a surprising bug — now known as CVE-2022-30115 — let people sneak past this safety feature using a tiny trick with a trailing dot in the hostname.

Let’s break down what went wrong, how attackers could abuse it, and see it in action with example code.

What is HSTS in curl?

In versions of curl that support HSTS, after you visit https://example.com, curl stores a rule telling itself: _“Always use HTTPS for this domain now.”_ This avoids accidental downgrades to insecure HTTP later.

Example: Let’s say you do this

curl --hsts hsts.txt https://example.com


Now, if your next request is curl --hsts hsts.txt http://example.com, curl automatically upgrades it to HTTPS, keeping you safe.

Domain Names and Trailing Dots

A trailing dot at the end of domain (like example.com.) means the fully qualified domain name (FQDN). Both example.com and example.com. should point to the same place… but computers can treat them as technically different.

The Bypass

In CVE-2022-30115, curl’s HSTS cache did not treat example.com and example.com. as the same, so it kept separate security rules.

- If you stored the HSTS rule while visiting _without_ a dot (example.com), and then requested _with_ a dot (example.com.), curl would not upgrade to HTTPS.

Visual Explanation

+--------------------+-----------+-----------+
|                    | No dot    | Trailing Dot |
+--------------------+-----------+-----------+
| HSTS cache present |   YES     |    NO     |
+--------------------+-----------+-----------+
|    Request to      |   YES     |    YES    |
| (which version?)   |           |           |
+--------------------+-----------+-----------+

Let’s say you run curl like this

curl --hsts hsts-cache.txt https://example.com


This adds HSTS for example.com to your cache.

Now, if an attacker gets you to visit

curl --hsts hsts-cache.txt http://example.com.


(the only difference is the trailing dot)

curl does NOT recognize that this is the same domain with HSTS, so it does not auto-upgrade to HTTPS. This lets traffic go over insecure HTTP — perfect for man-in-the-middle attacks.

Step 1: Store HSTS for example.com

curl --hsts hsts.txt https://example.com

Check that the cache has an HSTS entry

cat hsts.txt

You’ll see something like

example.com 1 165480000

Step 2: Try to bypass with trailing dot

curl --hsts hsts.txt http://example.com.


👉 Expected: curl _should_ upgrade this to HTTPS.  
😱 Reality (with the bug): It sends the request over HTTP, ignoring HSTS rules.

Store HSTS for the trailing dot variant

curl --hsts hsts.txt https://example.com.

Now, request without the dot

curl --hsts hsts.txt http://example.com


Again, it lets through the insecure request.

Official References

- cURL Security Advisory: CVE-2022-30115
- National Vulnerability Database: CVE-2022-30115
- cURL GitHub Issue: HSTS Trailing Dot Bypass

While most users don’t type trailing dots, attackers can

- Trick scripts or users into using a trailing dot in automation commands (think: shell scripts, cron jobs).

Patch and Fix

The curl devs fixed this by making curl always treat domain names as the same, with or without a trailing dot when working with HSTS.

Upgrade to curl 7.83.1 or newer!  
Or check your distro’s security updates.

Quick Takeaways

- Even small weirdness (like a single “.” at the end of a domain!) can lead to real-world vulnerabilities.

Always keep your tools up-to-date.

- When writing scripts, be careful with domain formats — and don’t assume example.com and example.com. are treated identically everywhere!

Timeline

Published on: 06/02/2022 14:15:00 UTC
Last modified on: 06/22/2022 13:47:00 UTC