✓ProveIt
Examples / Report #3677759 Saved analysis

CVE-2026-6429: netrc credential leak with reused proxy connection

curl · 2026-04-169.7s analysis · $0.011 in model calls

What the report claims

libcurl leaks .netrc-derived Authorization credentials to unintended hosts during redirects over a reused HTTP proxy connection.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2026-6429 netrc credential leak with reused proxy connection

Shown for comparison after analysis. The pipeline did not see this label.

ProveIt's finding

More detail needed

There is not enough information to verify the reported bug.

Why this finding?
  • No curl source code for lib/url.c or lib/http.c was provided (curl_source section states 'no curl code could be retrieved for this report')
  • The PoC source, server scripts, .netrc file, and captured logs were not included in the materials
  • Deterministic checks only confirm file/symbol existence, not the credential handling logic during proxy reuse and redirects
  • Cannot evaluate whether .netrc credentials are properly scoped to their host during connection reuse without seeing the implementation
What still needs checking
  • Source code for lib/url.c and lib/http.c at revision ce7174555dec (or curl 8.19.0)
  • The PoC source file poc_netrc_proxy_redirect.c
  • The server scripts netrc_proxy_redirect_server.py and netrc_origin_redirect_server.py
  • The .netrc file used in testing
  • The captured proxy logs showing the Authorization header leakage
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2026-04-16 (ce7174555dec). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.

1 · Grounding
grounded
no model · 6 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
5 claims · 2161 tokens · $0.0002
3 · Evidence
0 code snippets
real curl source at ce7174555dec · 5 docs via Tavily
4 · Judgment
Nemotron-3-Ultra-550b-a55b
8143 tokens · 5.1s · $0.0108
5 · Receipts
0 of 0 citations verified
every citation must point at code the judge was shown
Review a draft reply to the reporter

Edit and verify before sending.

Thank you for the detailed report. To evaluate this claim, I need the curl source code for lib/url.c and lib/http.c at the tested revision (ce7174555dec or curl 8.19.0), as well as the PoC source (poc_netrc_proxy_redirect.c), server scripts, .netrc file, and captured logs. The materials provided did not include these. Could you please share them so I can examine the .netrc credential handling during proxy connection reuse across redirects?

Inspect all claims and source code 5 claims · 0 code excerpts

Report claims

C1flaw not verifiable

libcurl reuses an HTTP proxy connection across redirects and sends .netrc-derived Authorization headers to redirected hosts even when .netrc contains credentials only for the original host

Read the reasoning

The report claims libcurl reuses HTTP proxy connections across redirects and sends .netrc-derived Authorization headers to redirected hosts. However, no curl source code for lib/url.c or lib/http.c was provided in the curl_source section (it states 'no curl code could be retrieved for this report'). The deterministic checks only confirm these files exist at the revision, not their content. Without seeing the actual credential handling logic during redirect and proxy reuse, I cannot verify or contradict this claim.

C2location not verifiable

The flaw resides in lib/url.c and lib/http.c handling of .netrc credentials during redirect and proxy reuse

Read the reasoning

The report locates the flaw in lib/url.c and lib/http.c handling of .netrc credentials during redirect and proxy reuse. As with C1, the actual source code for these files was not provided, so I cannot examine the relevant code paths to confirm or deny this location claim.

C3trigger not verifiable

An HTTP redirect chain a.test → b.test → c.test executed over a keep‑alive proxy connection reuses the same TCP connection

Read the reasoning

The report describes a redirect chain a.test → b.test → c.test over a keep-alive proxy connection reusing the same TCP connection. While the PoC logs are described, the actual curl connection reuse implementation in lib/http.c and lib/url.c was not provided, so I cannot verify this trigger mechanism from the code.

C4impact not verifiable

Authorization header value from .netrc for a.test is sent to b.test and c.test, leaking credentials that belong only to a.test

Read the reasoning

The report claims the Authorization header value from .netrc for a.test is sent to b.test and c.test. This is the core impact claim, but without the curl source code showing how .netrc credentials are looked up and applied during redirects over reused proxy connections, I cannot verify this leakage occurs in the code.

C5reproduction not verifiable

The provided PoC starts a netrc proxy redirect server, a no‑proxy origin redirect server, builds poc_netrc_proxy_redirect.c and runs it, showing the same client_port and Authorization header for all three hosts

Read the reasoning

The report describes a PoC with server scripts and captured logs. However, the PoC source code (poc_netrc_proxy_redirect.c), server scripts, .netrc file, and logs were not provided in the materials. I only have the report's description of what they show, not the actual artifacts to examine.

Read the original report (excerpt)

Full report on HackerOne ↗

## Summary: libcurl can leak `.netrc`-derived host `Authorization` credentials across redirected hosts when an HTTP proxy connection is reused. In the PoC, `.netrc` contains credentials only for `a.test`, but after `a.test` redirects to `b.test` and then `c.test` over the same keep-alive proxy connection, libcurl sends `Authorization: Basic dXNlckE6cGFzc0E=` to `b.test` and `c.test`. The leaked header is `Authorization`, not `Proxy-Authorization`, and the attached controls show the leak disappears when connection reuse is forbidden, when each request uses a new easy handle, and when the same redirect flow is run without a proxy. The issue appears to involve the `.netrc` / redirect / proxy connection reuse path in `lib/url.c` and `lib/http.c`. I reproduced this on `curl 8.19.0 / libcurl 8.19.0` on x86_64 Linux. An attachment with the PoC source, server scripts, `.netrc` file, and captured logs is included. ## Affected version Reproduced on: `curl 8.19.0 (x86_64-pc-linux-gnu) libcurl/8.19.0 OpenSSL/3.5.5 zlib/1.3.1 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.68.1 ngtcp2/1.21.0 nghttp3/1.15.0 librtmp/2.3 mit-krb5/1.22.1 OpenLDAP/2.6.10` Platform: `Linux x86_64` ## Steps To Reproduce: 1. Ensure the attached `.netrc` file contains only: `machine a.test login userA password passA` 2. Start the proxy/server: `python3 -u netrc_proxy_redirect_server.py 18085` 3. Start the no-proxy origin control server: `python3 -u netrc_origin_redirect_server.py 18087` 4. Build the PoC: `cc poc_netrc_proxy_redirect.c -o poc_netrc_proxy_redirect $(curl-config --cflags --libs)` 5. Run the PoC: `./poc_netrc_proxy_redirect` 6. Observe the base case proxy log. `a.test`, `b.test`, and `c.test` all use the same `client_port`, showing proxy connection reuse, and the same host `Authorization` header is sent to all three hosts: `{"client_port": 49048, "host": "a.test", "path": "http://a.test/start", "authorization": "Basic dXNlckE6cGFzc0E=", "proxy_authorization": null}` `{"client_port": 49048, "host": "b.test", "path": "http://b.test/second", "authorization": "Basic dXNlckE6cGFzc0E=", "proxy_authorization": null}` `{"client_port": 49048, "host": "c.test", "path": "http://c.test/third", "authorization": "Basic dXNlckE6cGFzc0E=", "proxy_authorization": null}` 7. Observe the controls: - with `CURLOPT_FORBID_REUSE=1`, `b.test` and `c. …

Source code

No source code was retrieved for this analysis. The evidence may be incomplete.