How do you update curl and find every copy you run?

To update curl, install the newest release from your operating system's package manager or from curl.se, then confirm with curl -V. The harder part is libcurl, which sits inside many applications, containers and language runtimes. Each of those copies needs its own check, because updating the command line tool alone fixes only one of them.

Why does curl need updating so often?

curl is a very large, very old C codebase that speaks dozens of protocols, and the project publishes advisories openly. When we fetched the curl vulnerability table on 18 October 2026, version 8.23.0 was the current release, dated 14 October 2026. The page for curl 8.22.0 lists 21 published security problems, and most are rated low severity.

One of them is rated high: CVE-2026-92392, a use after free during HTTP/2 uploads, present from 8.12.0 through 8.22.0. The advisory says it has been shown to be convertible into remote code execution only when a long list of conditions line up, including knowledge of the exact build and heap layout. That is a reason to patch on a normal schedule, not a reason to panic. The curl project itself recommends upgrading to 8.23.0, applying the patch, or not using HTTP/2.

Which copy of curl are you actually running?

Three different things share the name.

The command line tool is what curl -V reports. It also prints the libcurl version it was built against and the TLS library in use.

The shared library, libcurl, is loaded by other programs. A program such as a package manager, a PHP extension or a Python binding may call it without ever showing the word curl.

The statically linked or vendored copy is the one most teams miss. Some applications ship their own libcurl inside the binary or the container image, so updating the system package does nothing for them. curl's own advisories carry the sentence "libcurl is used by many applications, but not always advertised as such!" for exactly this reason.

What about distributions that backport fixes?

Linux distributions often keep an older version number and patch the security fix into it. A reported version of 8.5.0 on such a system does not automatically mean exposed. Read your distributor's security tracker for the specific CVE, and compare its fixed package version with what is installed. The reverse also holds: a container built from an old base image can carry a vulnerable curl for years because nobody rebuilds it.

A constructed example

Say a team runs a small API service in a container. They patch the host to curl 8.23.0 and consider the job done. The container image was built in March from a base image that includes curl 8.12.x, and a health check script inside it calls curl against an HTTP/2 endpoint. Nobody scanned the image, so the old copy is still running. The host fix did not touch it. A rebuild from a current base image closes the gap.

How to check or apply this

1. Run curl -V on every host and note the libcurl line, not just the tool version.
2. List your container images and read the curl version inside each one, either with an image scan or by running the version command in a throwaway container.
3. Search language packages that bundle or bind libcurl (for example, anything with "curl" in the name in your lockfiles).
4. For distribution packages, check the vendor's CVE page rather than comparing version numbers.
5. Upgrade, rebuild images, redeploy, and record the date.
6. If you cannot upgrade immediately, apply the project's workarounds listed in each advisory, such as avoiding the affected protocol or proxy mode.

Safeguard's dependency scanning builds an inventory of libraries across your repositories and images, and reachability analysis helps separate the copies that call the vulnerable code path from those that do not. The free scan at gold.safeguard.sh/scan checks up to 100 dependencies in your browser.

Quick check

Sources

• curl vulnerability table, fetched 18 October 2026
• curl download page, fetched 18 October 2026
• CVE-2026-92392 advisory
• CVE-2023-38545 advisory, for the "not always advertised" wording

Last reviewed: 18 October 2026.