Authorization: Negotiate sent to foreign origin

When built with wolfSSL, curl can successfully validate a pinned public key hash against a key the TLS peer does not possess. During the TLS handshake, wolfSSL validates the connection, but curl's subsequent re-parsing of the same certificate - tricked by a manipulated validity length field - extracts and matches a different embedded key, incorrectly authorizing the pinned public key.

auto client cert connection reuse mixup

Negotiate credentials sent to redirected origin

An ftp:// transfer configured with CURLUSESSLNONE can reuse a pooled FTP control connection that a previous easy handle upgraded with STARTTLS and authenticated using a client certificate. The second handle performs neither a new TLS handshake nor a new FTP login, so the server continues to authorize it under the first handle's certificate identity.

Hello,

Today the curl project publishes a set of twenty-four separate vulnerabilities in association with the release of curl 8.23.0.

All vulnerabilities have their fixes mentioned in text and link to the corresponding commit that fixes the problem.

Detailed information about all vulnerabilities are available on https://curl.se/docs/security.html

One vulnerability is considered severity HIGH:

CVE-2026-92392: HTTP/2 upload Use-After-Free

The other vulnerabilities are considered severity LOW:

CVE-2026-107929: local interface connection reuse mixup CVE-2026-107928: info leak uploading over WebSockets with GnuTLS CVE-2026-94266: password leak in CURLINFOEFFECTIVEURL CVE-2026-94265: Authorization: Negotiate sent to foreign origin CVE-2026-92391: curlmimefree stack overflow by recursion CVE-2026-92390: -J no-clobber guarantee bypassed with 103 early hints CVE-2026-92389: TFTP direction confusion CVE-2026-92388: FTP wildcard write callback mixup CVE-2026-92387: never-ending loop via server response omission CVE-2026-92386: server-set cookie aborts cookie jar load CVE-2026-87866: wolfSSL public-key pinning bypass CVE-2026-87865: knownhost callback mismatches key as missing CVE-2026-87864: IMAP APPEND plus CRLF conversion command injection CVE-2026-87863: HSTS response erases persisted entries CVE-2026-87862: HSTS cache import drops longer-lived child CVE-2026-87861: cross-origin reuse of a Negotiate connection CVE-2026-86415: auto client cert connection reuse mixup CVE-2026-86414: leaking host credentials to HTTP proxy CVE-2026-86413: Negotiate credentials sent to redirected origin CVE-2026-86412: server-set cookie erases cookie jar CVE-2026-86411: FTP connection reuse inherits client-certificate CVE-2026-86410: redirect to SFTP or SCP bypasses host verification CVE-2026-86409: stale SigV4 headers sent unintended

--

/ daniel.haxx.se || https://rock-solid.curl.dev

A remote HTTP server can set a cookie that curl accepts and writes to a Netscape cookie jar but cannot reload. On the next invocation using the same path for --cookie and --cookie-jar, curl fails before connecting, then the cleanup procedure replaces the jar with an empty file, deleting cookies for unrelated domains.

A flaw in the curl command line tool's logic makes it only set SSH host verification options when interacting directly using SFTP or SCP, and not as a result of following a redirect.

An authenticated HTTPS origin can supply an HSTS max-age value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.

-J no-clobber guarantee bypassed with 103 early hints

local interface connection reuse mixup

info leak uploading over WebSockets with GnuTLS

During an upload, curl mishandles HTTP/2 RSTSTREAM received from the server (with reason HTTP11REQUIRED or REFUSEDSTREAM) leading to a use after free of a struct Curleasy object.

During an upload, curl mishandles HTTP/2 RSTSTREAM received from the server (with reason HTTP11REQUIRED or REFUSEDSTREAM) leading to a use after free of a struct Curleasy object.

INFO ----

This Use-After-Free flaw has been proven to be possible to convert into a Remote Code Execution if a set of specific criteria are met by the malicious server:

- the exact curl version object and structure layout used for the transfer is known and used to derive attack offsets; - exact architecture details of the running curl needs to be known - a known and compatible libc allocator build and heap layout - nghttp2 and OpenSSL/TLS 1.3 behavior, including allocation effects around session tickets - a pinned CA bundle and other input-dependent allocation geometry - two parallel transfers and their scheduling/timing need to remain - correctly calibrated libc leak and symbol offsets; and - the exploit's current short-command constraint (approximately 23 bytes).

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2026-92392 to this issue.

CWE-416: Use After Free

Severity: High

This bug is considered a C mistake (likely to have been avoided had we not been using C).

AFFECTED VERSIONS -----------------

- Affected versions: curl 8.12.0 to and including 8.22.0 - Not affected versions: curl < 7.12.0 and >= 8.23.0 - Introduced-in: https://github.com/curl/curl/commit/cd9107e0128191b7b5396b

libcurl is used by many applications, but not always advertised as such!

This flaw also affects the curl command line tool.

SOLUTION --------

- Fixed-in: https://github.com/curl/curl/commit/

RECOMMENDATIONS ---------------

A - Upgrade curl to version 8.23.0

B - Apply the patch to your local version

C - Do not use HTTP/2

TIMELINE --------

This issue was reported to the curl project on September 15, 2026.

curl 8.23.0 was released on October 14, 2026, coordinated with the publication of this advisory.

CREDITS -------

- Reported-by: Luna with Claude, Anthropic - Patched-by: Stefan Eissing

Thanks a lot!

When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a Set-Cookie header where the Domain attribute explicitly matches an origin host that is itself a public suffix (e.g., Domain=co.uk set by co.uk).

Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (.co.uk). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., attacker.co.uk).

A Set-Cookie: header using tab (horizontal tab, ASCII code 9) instead of space (ascii code 32) immediately before the Secure attribute causes curl to store the cookie without its Secure flag. The cookie might then wrongfully be sent over plaintext HTTP on subsequent requests to the same host.

A flaw in libcurl makes it wrongly reuse an HTTP connection setup for a given hostname using Negotiate authentication, when the initial request is done using empty credentials. This can make user B's request get sent over user A's previously authenticated connection.

A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.

Successfully using libcurl to do a transfer to a specific HTTP origin (hostA) with Digest authentication and then changing the origin to a different one (hostB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Authorization: header field meant for hostA, to hostB.

A flaw in curl’s cookie parsing logic allows a malicious HTTP server to set 'super cookies' that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl subsequently scopes and transmits to unrelated third-party domains.

libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different 'services'.

libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead.

When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.

When asking curl to use a .netrc file to find credentials and at the same time specifying a URL with a username(without a password), like https://user@example.com/, curl could wrongly get and use the password for another user set in the .netrc file for that host if such a one exists and there is no match for the specified user.

A vulnerability in libcurl caused the HTTP Referer: header to persist even when explicitly cleared. While the documentation states that passing NULL to CURLOPTREFERER suppresses the header, the option failed to clear the internal state. As a result, the previous referrer string was erroneously reused and sent in subsequent requests, potentially leaking sensitive information to unintended servers.

libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse.

libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key.

libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different "services".

libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead.

When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.

Last updated 10 July 2026

When a user invokes curl using a schemeless URL combined with --proto-default sftp (or scp), a disconnect occurs between the tool layer and libcurl. The tool layer incorrectly infers the URL scheme, which erroneously bypasses the initialization of critical SSH security options like CURLOPTSSHHOSTPUBLICKEYSHA256 and CURLOPTSSHKNOWNHOSTS. Conversely, the libcurl runtime successfully honors CURLOPTDEFAULTPROTOCOL and establishes the connection via SFTP/SCP as specified. Because the tool layer skipped the security configuration, these SSH host verification options are silently omitted, causing curl to connect to an unverified SSH remote host without throwing an error.

Successfully using libcurl to do a transfer to a specific HTTP origin (hostA) with Digest authentication and then changing the origin to a different one (hostB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Authorization: header field meant for hostA, to hostB.

By default, curl automatically responds to WebSocket PING frames. Because curl lacks an upper bound on memory allocation for unacknowledged frames, a malicious server can exhaust all available memory by flooding curl with rapid, sequential PING messages.

libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup.

An easy handle that first uses default native CA trust can continue trusting the native platform store after the application switches that same handle to custom CA material for a later transfer.