curl 8.22 Tightens HSTS Directive Matching for Proxy Clients

curl 8.22.0 changes how its HSTS parser recognizes directive names: known names must now match complete tokens rather than only matching a prefix. The release shipped on September 2, 2026, and the associated curl project change was developed in late August.

The bug report explains two concrete parser effects. A lookalike token beginning with includeSubDomains could be interpreted as the real directive, while a token beginning with max-age could interfere with processing a later valid max-age directive. The corrected parser treats longer lookalike names as unknown directives and continues processing recognized directives according to the applicable syntax.

For proxy-based collection and verification systems, this matters because HSTS decisions occur in the client. A stored policy can upgrade an HTTP URL to HTTPS before proxy negotiation reaches the origin. That can change the target scheme, port, CONNECT behavior, TLS handshake, and connection-pool key even though the input URL has not changed.

What changed in curl 8.22

The curl project's release notes summarize the fix as exact HSTS string matching. The related change describes the earlier behavior as case-insensitive prefix comparison. curl 8.22 tokenizes the directive name and compares the whole name against recognized directives.

The operational result is narrower and more predictable parsing:

• exact recognized directives keep their defined meaning;
• longer tokens that merely begin with a known name are treated as unknown;
• an unknown lookalike should not enable subdomain policy;
• a lookalike should not prevent a later valid directive from being processed.

This is a parser-correctness change, not permission to weaken TLS verification or ignore unexpected headers. Applications should still validate the behavior they depend on after upgrading.

Why proxy workflows should test it

HSTS state is held by the HTTP client, not established by the proxy exit IP. If the client upgrades a request to HTTPS, an HTTP proxy may receive a CONNECT request instead of a plain HTTP request. A SOCKS route may carry a different destination port. TLS policy, certificate validation, and connection reuse then apply to the upgraded destination.

That affects several legitimate workflows:

• regional availability checks that compare HTTP and HTTPS behavior;
• ad verification that must preserve a defined scheme and redirect trail;
• web collection jobs that reuse a persistent HSTS cache across workers;
• market-research crawlers that replay the same URL through multiple authorized routes;
• long-lived libcurl services upgraded without clearing or versioning cached state.

The change does not mean every job should erase HSTS state. It means teams need a controlled regression that distinguishes parsing, cached policy, proxy routing, and origin behavior.

Build a safe regression fixture

Use a hostname, HTTPS endpoint, certificate, and proxy routes your organization controls. Do not send crafted headers to third-party services.

Prepare four responses in an isolated fixture:

1. a valid max-age directive;
2. a valid includeSubDomains directive on a parent test hostname;
3. an unknown token whose name merely begins with includeSubDomains;
4. an unknown token beginning with max-age, followed by a valid max-age directive.

Use synthetic hostnames and a short, deterministic test duration. Keep certificate and hostname verification enabled. Record client version, HSTS-cache identity, input scheme, effective scheme, target port, proxy mode, connection reuse, and final result.

For wider upgrade discipline, follow the proxy connection pool age test. To isolate TLS configuration across proxy routes, use the proxy TLS trust profile guide.

Expected results after upgrade

With curl 8.22 or a vendor build containing the fix:

• the valid max-age case creates or updates policy as intended;
• the valid subdomain case applies only under the controlled parent-host policy;
• the longer subdomain lookalike is ignored as unknown and does not enable that policy;
• the longer max-age lookalike is ignored, while the later exact max-age remains processable;
• a resulting HTTP-to-HTTPS upgrade is visible before proxy and TLS stages;
• HTTPS certificate and hostname verification remain enabled.

Run each case with a new HSTS cache, then repeat with the same cache. A fresh process without the saved cache is the control. If behavior differs only when state is reused, inspect cache provenance and policy lifetime before blaming the proxy route.

Observe the whole request path

Capture these non-secret fields:

• test case ID and curl/libcurl version;
• raw fixture case name, not production header data;
• HSTS cache created, loaded, or reused;
• input URL scheme and effective scheme;
• destination hostname and port class;
• HTTP proxy, CONNECT, or SOCKS route;
• new or reused connection decision;
• TLS certificate and hostname verification outcome;
• redirect count and final response validation;
• cache update or expiration result.

Do not log cookies, bearer tokens, proxy passwords, private keys, customer URLs, or full browsing histories. The fixture should contain no production identities or data.

Upgrade without hiding state

Inventory the actual libcurl loaded by the serving process, including containers, static binaries, language bindings, and sidecars. Upgrade to curl 8.22.0 or a vendor package documenting the relevant fix.

Version test HSTS caches by client release during rollout. That lets operators compare old and new parsing without silently mixing state. Restart or drain workers according to change policy, but keep one controlled pre-upgrade artifact for comparison. Never copy production browsing state into a test environment.

After rollout, monitor unexpected scheme upgrades, CONNECT rate, TLS failures, target-port changes, HSTS cache writes, and validated success rate. A healthy deployment preserves legitimate exact directives while ignoring longer lookalikes.

Acceptance checklist

• [ ] The serving process reports curl/libcurl 8.22.0 or a documented patched build.
• [ ] HSTS cache location and ownership are known.
• [ ] Exact and lookalike directive cases are tested separately.
• [ ] The subdomain lookalike does not enable subdomain policy.
• [ ] The max-age lookalike does not block the later valid directive.
• [ ] Input and effective URL schemes are recorded.
• [ ] Proxy mode and destination port are recorded.
• [ ] TLS certificate and hostname verification remain enabled.
• [ ] Fresh-cache and reused-cache results are compared.
• [ ] Connection reuse does not conceal policy changes.
• [ ] Logs exclude credentials and production browsing data.

FAQ

Does the proxy parse HSTS for curl?

No. curl's HSTS behavior is client-side. The resulting scheme and connection may then change what the proxy is asked to carry.

Should unknown HSTS directives cause the entire header to fail?

The curl change specifically ensures that longer lookalike tokens take the unknown-directive path while recognized directives continue to be processed. Test the exact client behavior your application relies on.

Does this fix replace certificate validation?

No. HSTS can cause an HTTPS upgrade, but the client must still validate the certificate chain and hostname under its trust policy.

Must every upgrade clear the HSTS cache?

Not necessarily. Preserve intended policy, but version and control test state so old parser output does not make results ambiguous. Production cache handling should follow the application's security and change policies.

Source and responsible-use note

Internal research basis: curl project, curl 8.22.0 release announcement, published September 2, 2026; curl project change “hsts: match complete directive names,” opened August 23 and merged August 26, 2026; HTTP Strict Transport Security specification. External research URLs are retained only in the internal operations record; this public article contains no external links.

Run parser and proxy tests only against domains, endpoints, certificates, and routes you own or are authorized to assess. Respect privacy, provider limits, service terms, and organizational change controls.