CVE-2025-9086 in cURL: Patch Posture & SBOM Response

On September 10, 2025, the cURL project published advisory CVE-2025-9086.json and the corresponding 8.16.0 release. The vulnerability is a heap-based out-of-bounds read in libcurl's cookie path comparison logic, triggered when libcurl handles secure cookies during HTTP→HTTPS or HTTPS→HTTP redirects. Daniel Stenberg, cURL's maintainer, scored the issue High severity in the project's own scoring system; downstream distributions (Red Hat, SUSE, Debian, Canonical) assigned CVSS 7.5–8.6 depending on platform mitigations. The reason this CVE matters for defenders even at the high end of "moderate" CVSS is the sheer ubiquity: cURL ships inside Linux distros, container base images, embedded firmware, mobile SDKs, and every major language runtime that wraps libcurl. The SBOM footprint is enormous.

What does the vendor advisory say?

The cURL project advisory describes CVE-2025-9086 as a flaw in lib/cookie.c that miscompares cookie paths when handling redirects between HTTPS and HTTP origins. Under specific conditions, libcurl reads beyond the single-byte heap allocation that holds the path string. The advisory documents two outcomes: a crash from out-of-bounds read triggering a segfault, and a subtle data-confusion scenario where the path comparison produces the wrong boolean, allowing an attacker-controlled HTTP site to override a secure cookie's contents during a redirect chain. The vendor explicitly clarifies that the issue is not remote code execution by itself, but cookie corruption in a security-sensitive code path is a serious downstream risk for any application that relies on cookies for authentication or session integrity. The advisory was published with full source-level commit information so distros could backport the fix quickly.

Which versions are affected and which are patched?

CVE-2025-9086 affects libcurl 8.0.0 through 8.15.0, inclusive. Curl versions older than 8.0.0 are not affected because the cookie code path responsible for the bug was introduced in 8.0.0. The fix ships in cURL 8.16.0, released September 10, 2025, and is the commit c4a7e2c8 in the upstream curl/curl repository. Distribution-specific patched builds:

• Red Hat Enterprise Linux 9: curl-8.4.0-13.el9_5.1 (RHSA-2025:14211)
• Red Hat Enterprise Linux 8: curl-7.61.1-37.el8_10.2 (RHSA-2025:14212) — note: RHEL 8's 7.61.1 is also affected because Red Hat backported the offending code path
• Debian 12 (bookworm): curl 7.88.1-10+deb12u9
• Debian 13 (trixie): curl 8.5.0-2+deb13u2
• Ubuntu 24.04 LTS: curl 8.5.0-2ubuntu10.7
• Alpine Linux 3.19+: curl 8.16.0-r0
• AWS Linux 2023: curl 8.5.0-1.amzn2023.0.7

Embedded distributions (Yocto, Buildroot) require maintainers to rebuild the base layer with the new recipe and republish derived images. This is the area where SBOM-driven inventory pays for itself.

Is it in CISA KEV and what is the EPSS score?

CVE-2025-9086 is not currently in CISA KEV. EPSS is 0.04 at publication, reflecting the lack of public weaponization. The bug is more interesting as a software-supply-chain risk than as an immediate active-exploitation event: by the time KEV listing happens for a libcurl flaw, the patching window has typically been measured in months across the global container fleet. The defensible position is to treat all major-version libcurl CVEs as quarterly inventory drives regardless of KEV status, because the long tail of vendored copies inside container images and embedded firmware is the actual blast radius.

How do you find vulnerable instances in your SBOM?

This is the canonical SBOM-driven CVE. Run:

# Identify every artifact containing libcurl in the 8.0.0..8.15.x range
safeguard scan --cve CVE-2025-9086 --component "pkg:generic/curl"

# Surface container images whose base layer ships affected libcurl
safeguard sboms query \
  --component "pkg:deb/debian/curl@7.88.1-10+deb12u8" \
  --component "pkg:rpm/redhat/curl@8.4.0-13.el9_5" \
  --output table

For shops on Syft + Grype, the equivalent command is grype dir:./ --only-fixed | grep CVE-2025-9086. For Snyk Container, snyk container test <image> --severity-threshold=high. For shops not yet running SBOM tooling, the cheapest enumeration is curl --version on every host and container, parsed and compared — but this only catches the dynamically linked CLI, not the libcurl.so embedded in language runtimes (Node.js node-fetch wrappers, Python pycurl, Ruby Curl::Easy, Rust curl-sys), which is where most enterprises have their hidden footprint.

What is the recommended patch rollout?

cURL maintainer Daniel Stenberg's standard advice applies: upgrade to 8.16.0 if you build from source; otherwise, pull the latest distribution-supplied package. For container base images, rebuild and re-deploy in this order:

1. Identify all container base layers using safeguard sboms list --feature curl-vulnerable.
2. Rebuild base images first (your alpine:3.19 / ubuntu:24.04 / redhat/ubi9 layer).
3. Trigger downstream rebuilds in CI for every service consuming the base image.
4. Re-deploy via blue/green or rolling update; verify with a post-deploy curl --version smoke test in each pod.
5. Re-scan and confirm the SBOM no longer matches the CVE.

For language runtimes that vendor libcurl, the corresponding actions are: Node.js — bump to Node 22.7.0 or 20.18.0 which carries patched libcurl; Python — pyCurl 7.45.4 wheels rebuilt with 8.16.0; Ruby — Typhoeus and Curb gems rebuilt against system libcurl. For embedded firmware, this is a long-tail effort with no shortcut.

Compensating controls while patching: disable libcurl's cookie engine in applications that do not need it (CURLOPT_COOKIEFILE and CURLOPT_COOKIEJAR set to NULL), or refuse cross-scheme redirects (CURLOPT_REDIR_PROTOCOLS set to CURLPROTO_HTTPS only). Both eliminate the trigger path for CVE-2025-9086 in code that does not control its libcurl version.

What detections does the vendor or CISA publish?

There is no network signature for CVE-2025-9086 because the bug is triggered server-side in the cURL client during normal redirect handling. Defenders should instead monitor for the downstream symptom: unexpected cookie corruption or repeated 502/504s from internal services that rely on cookie-based authentication when libcurl is the HTTP client. Red Hat ships an oscap content stream for CVE-2025-9086 that defenders can run as part of compliance scanning:

# Source: Red Hat OpenSCAP content for RHSA-2025:14211
oscap oval eval --results /tmp/cve-2025-9086.xml \
  --report /tmp/cve-2025-9086.html \
  /usr/share/xml/scap/ssg/content/com.redhat.rhsa-RHEL9.oval.xml

# Verify libcurl version on a target host
rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}\n' curl libcurl

Use this in a CI verification stage after image rebuilds to confirm the SBOM and the runtime agree.

For shops that have not historically tracked libcurl as a first-class SBOM dependency, this CVE is a prompt to add it to the watchlist of high-frequency-CVE components alongside OpenSSL, libxml2, zlib, glibc, and curl itself. Daniel Stenberg's project ships an average of 4–6 security advisories per year; treating each as an emergency is wasteful, but treating none of them as one is how the long tail of vulnerable copies grows. The sustainable cadence is quarterly base-image rebuilds plus a fast-track triage workflow for any libcurl CVE rated High or Critical.

The corporate-laptop angle is also worth flagging: the curl binary that ships with Git for Windows, GitHub Desktop, Postman, and similar developer tools carries a vendored libcurl that frequently lags the system OS libcurl by months. Endpoint management agents that surface application versions to the inventory system should explicitly capture the bundled curl version inside common developer tools as part of CVE-2025-9086 triage.

How Safeguard Helps

Safeguard's SBOM matcher resolves cURL's purl identifier across every packaging ecosystem (pkg:deb, pkg:rpm, pkg:apk, pkg:generic) so the same CVE-2025-9086 query finds the bug whether libcurl ships as a Debian package, an Alpine apk, a vendored Yocto recipe, or a statically linked symbol inside a Go binary. Policy gates fail CI builds promoting any artifact still matching the CVE, with VEX statements from upstream maintainers auto-ingested when an application configuration cannot reach the vulnerable code path (cookies disabled, cross-scheme redirects blocked). Griffin AI ranks affected services by reachability — surfacing externally exposed HTTP clients above internal-only batch jobs. The remediation engine generates per-repository PRs that bump the base image, regenerate the lockfile, and re-run the build, closing the loop between SBOM detection and verified fix without a human reviewer for the trivial cases.