curl 8.22.0 Fixes Ten Security Flaws

curl 8.22.0 arrived on September 2 with a small feature list but a much bigger reason for developers to pay attention: the release addresses ten newly disclosed security vulnerabilities across curl, libcurl and wcurl. Nine affect curl or its underlying library, while one affects the newer wcurl command. The update also adds HTTP Message Signatures support, Apple GSS Framework support and other protocol changes, making this more than a routine maintenance release.

curl 8.22.0 is primarily a security release

The most consequential change is the coordinated disclosure of ten security issues. The curl project lists affected versions through 8.21.0 and marks 8.22.0 as the fixed release for all ten advisories. Most of the flaws are rated low severity, but CVE-2026-19931, involving Negotiate authentication and connection reuse, is rated medium, while CVE-2026-80229, an OpenSSL provider use-after-free flaw, carries a critical severity classification in the project's advisory table.

That spread matters because curl is rarely used only as a program a developer runs manually. libcurl is the reusable networking library behind applications that need to make HTTP, HTTPS and other network requests, so a vulnerable library can remain embedded inside software even when users never type the curl command themselves. The project therefore recommends upgrading both curl and libcurl rather than treating the update as optional housekeeping.

Several flaws affect how connections and credentials are reused

One of the more significant issues is CVE-2026-19931, which affects curl 7.64.1 through 8.21.0. Under particular Negotiate authentication conditions, libcurl could reuse an existing connection in a way that exposed credentials or connection state to the wrong session. The project rates this flaw medium severity, making it the clearest reason for developers using authenticated network services to prioritize the update.

Other advisories target narrower configurations. CVE-2026-80231 affects Windows and macOS users of the native certificate store, where an HTTPS connection could be reused despite a different certificate-store setting. CVE-2026-80230 concerns certificate pinning when OpenSSL is used, while CVE-2026-82208 involves certificate-authority cache behavior with wolfSSL. These are not universal attacks against every curl installation; they depend on particular backends or options, which is why reading the affected-configuration details matters before judging risk.

Cookie handling also gets two fixes

Cookie behavior is another thread running through the release. CVE-2026-80255 could cause a cookie marked with the Secure attribute to be stored without that protection when a horizontal tab appeared in a particular position in the header. The practical consequence is that the cookie could later be sent over unencrypted HTTP, rather than being restricted to HTTPS.

CVE-2026-82209 is different. When libcurl has Public Suffix List support enabled, it could mishandle a cookie whose domain matched an origin that was itself a public suffix. The curl project says exploitation requires the affected apex domain to issue the cookie, so this is not a case where an arbitrary attacker can simply plant the cookie. Both problems are nevertheless fixed in 8.22.0, which removes the need for applications to work around the parsing behavior themselves.

One memory-safety bug is limited to libcurl

Developers embedding libcurl should pay particular attention to CVE-2026-18924, a use-after-free flaw associated with HTTP/2 server push. A use-after-free occurs when software continues using memory after that memory has already been released, creating the possibility of crashes or other unintended behavior. The curl project says this issue affects libcurl rather than the standalone curl command-line tool.

The distinction is useful when deciding what needs testing. A machine used only for ordinary command-line curl operations is not exposed to this particular bug, whereas an application linked against libcurl may be. The project lists versions from 7.44.0 through 8.21.0 as affected and recommends upgrading to 8.22.0 or applying the relevant patch.

The release also changes curl's networking capabilities

Security is not the only reason developers may encounter behavior changes after upgrading. curl 8.22.0 adds support for RFC 9421 HTTP Message Signatures, a standard for attaching cryptographically verifiable signatures to HTTP messages. It also adds Apple GSS Framework support, an option for using Apple's fast UDP implementation with QUIC, and API guards intended to make certain interfaces safer to use.

The release also removes TLS-SRP support. TLS-SRP is a TLS authentication mechanism based on the Secure Remote Password protocol, and its removal matters mainly to software that still depends on that specific authentication path. The curl project also says HTTP/2 Server Push is scheduled for removal in March 2027, giving maintainers time to identify applications that still rely on the feature rather than discovering the change during a future upgrade.

What developers should do before the next build

For projects that directly install curl or libcurl, 8.22.0 is the version to test. The previous release, 8.21.0, was published on June 24, making this a roughly ten-week interval between stable releases. The curl project recommends upgrading, although individual advisories also describe narrower mitigations for applications that cannot move immediately.

The more complicated cases are software distributions and applications that consume libcurl indirectly. A developer may not have chosen the vulnerable library version themselves because it arrived through an operating-system package, framework or other dependency. Checking the actual libcurl version in the production environment is therefore more useful than checking only whether the curl executable has been updated.

The next issue to watch is compatibility, not another feature race

curl 8.22.0 is a good example of why networking libraries deserve the same upgrade discipline as compilers and application frameworks. The headline feature list is short, but the security advisories touch authentication, certificate validation, cookies, HTTP/2 and memory management across different configurations. Most users will never trigger these paths, yet applications that do can inherit the problem through a library they barely notice.

For maintainers, the immediate task is straightforward: identify whether curl or libcurl is present, check which TLS and authentication backends are enabled, and test the application against 8.22.0. The release is already available, while curl's own version history lists 8.23.0 as the next pending release, so the useful question now is not whether to wait for a bigger feature release. It is whether the software you ship still depends on an older networking stack.