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!
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.
-J no-clobber guarantee bypassed with 103 early hints
local interface connection reuse mixup
curl 7.62.0 through 7.70.0 is vulnerable to an information disclosure vulnerability that can lead to a partial password being leaked over the network and to the DNS server(s).
Last updated 10 July 2026
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.
An issue in curl’s QUIC UDP receive function allows a malicious HTTP/3 server to trigger a remote denial of service against a curl or libcurl client. Because the helper function discards zero-length UDP datagrams before counting them toward the per-call packet budget, a connected QUIC peer can continuously stream empty datagrams to indefinitely stall the client.
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.
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.
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.
info leak uploading over WebSockets with GnuTLS
When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances.
If the hostname that the first request is redirected to has information in the used .netrc file, with either of the machine or default keywords, curl would pass on the bearer token set for the first host also to the second one.
Authorization: Negotiate sent to foreign origin
Negotiate credentials sent to redirected origin
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.
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.
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.
1. A cookie is set using the secure keyword for
curl's WebSocket code did not update the 32-bit mask pattern for each new outgoing frame as the specification says. Instead it used a fixed mask that persisted and was used throughout the entire connection.
curl's code for managing SSH connections when SFTP was done using the wolfSSH powered backend was flawed and missed host verification mechanisms.
This prevents curl from detecting MITM attackers and more.
netrc and default credential leak
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 flaw was found in curl. When curl is configured to use specific proxies for different URL schemes, and a redirect occurs from a URL using a credentialed proxy to a URL using a non-credentialed proxy, curl may inadvertently send the credentials of the first proxy to the second. This can lead to the unauthorized disclosure of proxy credentials (CWE-522), potentially allowing an attacker to gain unauthorized access or information.
curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.
A flaw was found in curl. When curl is configured to use specific proxies for different URL schemes, and a redirect occurs from a URL using a credentialed proxy to a URL using a non-credentialed proxy, curl may inadvertently send the credentials of the first proxy to the second. This can lead to the unauthorized disclosure of proxy credentials (CWE-522), potentially allowing an attacker to gain unauthorized access or information.
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 exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.
When asked to both use a .netrc file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances.
This flaw only manifests itself if the netrc file matches the redirect target hostname, but the entry omits password or both login & password.
A curl transfer with a.com that redirects to b.com that uses a .netrc like below (with a match, but no password specified for the second host), would make curl pass on alicespassword as password even in the second transfer to the separate host b.com.
~~~ machine a.com login alice password alicespassword
default login bob ~~~