curl 8.22 Hardens HTTP/3 Proxy Handling for Out-of-Order Response Headers

curl 8.22.0, released on September 2, 2026, includes a defensive HTTP/3 proxy fix described by the project as “fix NULL deref when non-:status header arrives before :status.” The correction matters to teams evaluating experimental HTTP/3 proxy paths because a malformed or unexpectedly ordered response should produce a controlled protocol failure, not terminate the client process.

The curl project explains that its HTTP/3 proxy header callback allocated the tunnel response object only after receiving the :status pseudo-header. A different header arriving first could then be stored through an object that did not yet exist, causing a null-pointer dereference. The change adds a guard before that object is used.

Why the ordering is abnormal

In an HTTP/3 response, :status is a required pseudo-header and must appear before regular response headers. A compliant peer should not send the sequence that exposed this path. That does not make defensive handling unnecessary: malformed input, a buggy intermediary, library behavior or a fuzz-generated sequence can still reach parser boundaries.

The project discussion characterizes the case as theoretical under normal protocol ordering, while still supporting the defensive check. The bug was found with a libFuzzer harness that drove curl's HTTP/3 proxy callbacks directly. This is a useful reminder that an uncommon path can still be worth testing when it sits on a process-crash boundary.

Scope the change accurately

This item is specifically about HTTP/3 proxy response handling. It is not a general fix for every HTTP/3 failure, ordinary HTTP CONNECT response, destination HTTP/3 exchange or malformed header condition.

Teams should first prove which hop is using which protocol:

• client to proxy over HTTP/3;
• a CONNECT or CONNECT-UDP exchange at the proxy layer;
• tunnel traffic to the destination;
• destination protocol negotiated inside or beyond the proxy route.

A destination using HTTP/3 does not prove the proxy hop uses HTTP/3. Likewise, a successful QUIC connection does not prove the tunnel response was parsed correctly.

Who should prioritize regression testing

Prioritize applications that use curl or libcurl 8.21.0 or earlier with HTTP/3 proxy features, especially custom builds, experimental proxy configurations, fuzz-tested clients and long-lived collection workers where one process handles many jobs.

Inventory the actual runtime version, QUIC backend, build features, proxy protocol and deployment artifact. The shell curl on a host may not be the same library bundled into a container, language binding or statically linked worker.

Do not claim exposure merely because a workload uses residential proxies. Ordinary HTTP or SOCKS proxy routes do not automatically use this HTTP/3 proxy callback.

Build a safe upgrade test

Use only a proxy endpoint and destination you own or are authorized to test. Never send malformed protocol input to a third-party service.

1. Record the curl/libcurl version, HTTP/3 backend and build configuration.
2. Establish a valid HTTP/3 proxy control response in which :status precedes regular headers.
3. In a controlled harness, inject a regular header before :status.
4. Test a response that omits :status completely.
5. Test duplicate or otherwise invalid pseudo-header sequences separately.
6. Capture process exit, curl result, protocol error, connection close, retry count and memory diagnostics.
7. Repeat through a single easy handle and through the multi interface used by production.
8. Confirm the worker remains alive and unrelated jobs continue.

The expected result for malformed sequences is a bounded error with no response accepted as valid. Do not require curl to recover a semantically valid response from invalid ordering; require it to avoid a crash, avoid partial-data success and avoid silent direct fallback.

Keep retry behavior conservative

A parser or protocol-order failure is not proof that changing a residential exit will help. Unlimited rotation can repeat the same malformed response, amplify cost and obscure the underlying client or gateway problem.

Classify the event separately from timeout, authentication failure, destination 429 and ordinary 5xx. Allow only a bounded retry when the operation is safe and policy explicitly permits it. Use the retry amplification guide to keep total attempts inside a shared budget.

If the HTTP/3 proxy path fails, fall back to another proxy protocol only when that route is configured, authorized and logged. Never fall back directly. The proxy bypass audit provides a fail-closed verification method.

Validate the complete result

After upgrading, do not stop at “the process no longer crashes.” Verify:

• valid HTTP/3 proxy responses still succeed;
• malformed ordering returns an explicit error;
• the body is not delivered as a valid result after header failure;
• callbacks do not receive partially initialized metadata;
• credentials and session state remain scoped to the proxy route;
• connection reuse does not carry failed state into a later transfer;
• concurrent transfers survive the malformed test;
• metrics distinguish proxy-header parsing from destination failure.

Use the HTTP/3 proxy evaluation guide for a broader test matrix and the proxy failover drill when validating an approved alternate route.

Deployment checklist

• Confirm the application uses an affected pre-8.22 runtime and the relevant HTTP/3 proxy path.
• Upgrade to curl/libcurl 8.22.0 or apply the project fix through the normal patch process.
• Rebuild all static binaries and containers that embed libcurl.
• Run valid, early-regular-header and missing-:status fixtures.
• Require bounded errors, no crash and no partial success.
• Test multi-handle concurrency and connection reuse.
• Keep retries bounded and breaker-aware.
• Prohibit silent direct fallback.
• Roll out by cohort while monitoring crashes, HTTP/3 proxy errors and valid outcomes.
• Retain a rollback artifact without reverting the security and reliability controls blindly.

FAQ

Is this a published curl security advisory?

The curl 8.22 change log lists it as a bugfix. Do not assign it a CVE or severity that the project did not publish.

Does every HTTP/3 user need this proxy test?

No. Confirm that the client-to-proxy hop uses curl's HTTP/3 proxy implementation. Destination-only HTTP/3 is a different path.

Should malformed responses be retried with another IP?

Not automatically. Treat the protocol error as diagnostic evidence. Retry only within an explicit, bounded policy and never rotate to evade destination controls.

What proves the upgrade succeeded?

Valid traffic continues, malformed order fails cleanly, the process and unrelated transfers remain healthy, and no partial response or direct bypass is accepted.

Source note and compliance

Internal research source: curl project, curl 8.22.0 release announcement and change log, September 2, 2026; curl project pull request “h3-proxy: fix NULL deref when non-:status header arrives before :status,” opened July 30 and merged July 31, 2026. Source URLs are retained only in the internal operations record.

Run malformed-response tests only on infrastructure you own or have explicit authorization to test. Respect provider agreements, destination terms, rate limits, privacy requirements and regional law. This fix improves defensive parsing; it is not a method for probing unrelated services or bypassing access controls.