Examples / Report #3721183 Saved analysis

CVE-2026-8458: wrong reuse for different services

curl · 2026-05-0810.1s analysis · $0.013 in model calls

What the report claims

curl 8.20.0 incorrectly reuses HTTP Negotiate connections across different service principals when using CURLOPT_SERVICE_NAME, allowing a connection authenticated for one service to be reused for another without a new handshake.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2026-8458 wrong reuse for different services

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

ProveIt's finding

Needs human review

The available evidence does not settle the report. A maintainer should investigate.

Why this finding?

No curl source code was provided for lib/http_negotiate.c or lib/url.c where the HTTP Negotiate connection reuse logic resides
Deterministic checks confirm the relevant files and symbols exist at the target revision, but their content is needed to verify the claims
The report is detailed and plausible with specific reproduction steps, but the code that would decide the claims is missing
External source E1 (RFC 5545) is about iCalendar, not curl or HTTP Negotiate authentication, and does not address CVE-2026-5545

What still needs checking

Content of lib/http_negotiate.c at revision 1698a3f85799, specifically the connection reuse logic and how it handles STRING_SERVICE_NAME / STRING_PROXY_SERVICE_NAME
Content of lib/url.c at revision 1698a3f85799, specifically the authenticated connection reuse matching logic

How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2026-05-08 (1698a3f85799). Test 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 · 8 references checked out, 0 did not

2 · Claims

NVIDIA-Nemotron-3-Nano-30B-A3B

5 claims · 2912 tokens · $0.0003

3 · Evidence

0 code snippets

real curl source at 1698a3f85799 · 3 docs via Tavily

4 · Judgment

Nemotron-3-Ultra-550b-a55b

9396 tokens · 7.1s · $0.0125

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, we need to see the connection reuse logic in lib/http_negotiate.c and lib/url.c from the curl-8.20.0 release. The provided deterministic checks confirm these files exist, but their content was not included. Could you provide the relevant sections of these files, particularly where authenticated HTTP connections are matched for reuse and where STRING_SERVICE_NAME / STRING_PROXY_SERVICE_NAME are used in that matching?

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

Report claims

C1flaw not verifiable

curl reuses an HTTP Negotiate-authenticated connection for a later request to the same host even when the requested service principal changes via CURLOPT_SERVICE_NAME

Read the reasoning

The report claims curl reuses an HTTP Negotiate-authenticated connection when the service principal changes via CURLOPT_SERVICE_NAME. However, no curl source code was provided for lib/http_negotiate.c or lib/url.c where the connection reuse logic resides. The deterministic checks confirm these files and symbols exist at the revision, but without the actual code I cannot verify whether the service name is checked during connection reuse.

C2location not verifiable

in lib/http_negotiate.c the connection reuse logic does not treat the service name as part of the authenticated connection identity

Read the reasoning

The report identifies lib/http_negotiate.c as the location where connection reuse logic fails to treat the service name as part of the authenticated connection identity. The file exists per deterministic checks, but its content was not provided, so I cannot confirm or contradict this claim.

C3trigger not verifiable

using CURLOPT_SERVICE_NAME to request a different service principal on the same host after an initial Negotiate authentication

Read the reasoning

The trigger (using CURLOPT_SERVICE_NAME to request a different service principal on the same host after initial Negotiate authentication) is plausible and CURLOPT_SERVICE_NAME exists per deterministic checks, but without the code showing how this option interacts with connection reuse, I cannot verify the code path.

C4impact not verifiable

the reused connection sends no new Authorization header and performs no new Negotiate handshake, causing the second request to be served under the first service's auth context

Read the reasoning

The impact claim (reused connection sends no new Authorization header, no new Negotiate handshake, second request served under first service's auth context) depends on the connection reuse logic which I cannot inspect without the source code.

C5reproduction not verifiable

run curl with two sequential requests using --negotiate --service-name svcA then --negotiate --service-name svcB on the same host; observe reuse message and lack of new Authorization header

Read the reasoning

The reproduction steps are detailed and specific, but I cannot verify they would trigger the described behavior without seeing the connection reuse implementation in lib/http_negotiate.c and lib/url.c.

What the report says about other projects

not addressed CVE-2026-5545 addressed wrong reuse of HTTP Negotiate-authenticated connections but did not cover service-principal changes

Read the original report (excerpt)

Full report on HackerOne ↗

## Summary: I found an incomplete-fix variant of CVE-2026-5545 in curl/libcurl 8.20.0. libcurl 8.20.0 still wrongly reuses an HTTP Negotiate-authenticated connection for a later request to the same host even when the requested service principal changes via `CURLOPT_SERVICE_NAME` / `--service-name`. In my reproduction, request 1 authenticates a persistent HTTP connection for service principal `svcA`. Request 2 then targets `svcB` on the same host, but libcurl reuses the already authenticated connection, sends no new `Authorization` header for `svcB`, and performs no new Negotiate handshake for `svcB`. The server still serves the `svcB` request under the auth context previously established for `svcA`. This is wrong authenticated connection reuse across changed service principals. This appears to be an incomplete-fix variant of CVE-2026-5545, which addressed wrong reuse of HTTP Negotiate-authenticated connections but did not cover service-principal changes in the reproduced path. ## Affected version Runtime verified on Linux x86_64 using a local build from the official `curl-8.20.0` release source tarball with `GSS-API` / `SPNEGO` enabled. Runtime output from the tested binary: ```text curl 8.20.0 (x86_64-pc-linux-gnu) libcurl/8.20.0 OpenSSL/3.6.1 zlib/1.3.1 mit-krb5/1.22.1 Release-Date: 2026-04-29 Protocols: http https ipfs ipns ws wss Features: alt-svc AsynchDNS Debug GSS-API HSTS HTTPS-proxy IPv6 Kerberos Largefile libz SPNEGO SSL threadsafe TLS-SRP UnixSockets ``` ## Steps To Reproduce: 1. Build curl 8.20.0 with GSS-API / SPNEGO enabled. ```bash cd /tmp curl -fsSLo /tmp/curl-8.20.0.tar.xz https://curl.se/download/curl-8.20.0.tar.xz tar -xf /tmp/curl-8.20.0.tar.xz cd /tmp/curl-8.20.0 ./configure \ --prefix=/tmp/curl-8.20.0-install \ --enable-debug \ --with-openssl \ --with-gssapi \ --disable-ldap \ --disable-ldaps \ --without-libidn2 \ --without-libpsl \ --without-brotli \ --without-zstd \ --without-libssh2 \ --without-nghttp2 \ --disable-ftp \ --disable-file \ --disable-tftp \ --disable-rtsp \ --disable-dict \ --disable-telnet \ --disable-pop3 \ --disable-imap \ --disable-smb \ --disable-smtp \ --disable-gopher \ --disable-mqtt \ --disable-manual make -j2 ``` 2. Build the attached GSS interposer and start the attached keep-alive test server. ```bash gcc -shared -fPIC -o /tmp/libpoc_gss_service …

Source code

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