Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessTarget curl client with HSTS persistence enabled
-
ExploitReturn crafted HSTS response erasing persisted entries
-
ExecutionLater requests to affected hosts no longer forced to HTTPS
-
ImpactDowngrade/MITM victim traffic on subsequent connection
Vulnerability Assessment
| Exploitation Conditions | Requires that the HSTS persistence feature be explicitly enabled (curl command-line --hsts <file>, or libcurl CURLOPT_HSTS pointing at a persistent cache file) - this is NOT a default configuration, which is the primary limiting factor. The attacker must also control the server curl connects to, or be an active on-path (MITM) attacker able to inject/modify the HSTS response. Impact is limited to erasing persisted HSTS entries (an integrity loss to the HSTS store); there is no direct code execution or data disclosure. The practical harm is indirect and deferred: a later connection to an affected host may no longer be forced to HTTPS, enabling a downgrade only if the attacker can also intercept that subsequent traffic. |
| Impact | This is a genuinely low-priority issue despite affecting ubiquitous software. No CVSS vector, EPSS score, KEV listing, or POC is provided in the input, and the curl project itself rates it LOW severity. The vulnerability is a security-mechanism-weakening bug (HSTS cache integrity), not a code-execution or direct data-disclosure flaw. Key signals are therefore CONFLICTING in the sense that product reach (curl is one of the most widely deployed libraries on earth) is maximal, but intrinsic severity and realistic exploitability are minimal: the attacker must already be positioned as the server (or an active MITM) AND the victim must have the opt-in HSTS persistence feature enabled. No active-exploitation signal exists (no KEV, no POC), so this should be patched during routine maintenance rather than treated as an emergency. Note: no CVSS vector was supplied, so authentication/attack-vector qualifiers below are inferred from the advisory text and the nature of HSTS, not from a confirmed vector - verify against the curl advisory at curl.se/docs/security.html. |
| Exploit ScenarioDerived | A malicious or compromised HTTPS server (or an active network attacker already able to influence responses) returns a crafted HSTS (Strict-Transport-Security) response to a curl/libcurl client that has HSTS persistence enabled. Processing this response erases previously persisted HSTS entries, so on a later connection curl no longer enforces HTTPS-only for those hosts, opening the door to a subsequent protocol-downgrade or MITM against the affected origins. No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Persisted HSTS entries held by curl and libcurl can be erased when a malicious or on-path server returns a crafted Strict-Transport-Security response, allowing an attacker to strip previously stored HTTPS-only policy for other hosts. Only builds running up to and including 8.22.0 that have HSTS persistence explicitly enabled (the curl tool's --hsts <file> option, or libcurl with CURLOPT_HSTS pointed at a cache file) are exposed - this is not a default configuration, which is the main limiting factor. The assessed impact is integrity-only (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N), with no code execution or direct data disclosure; harm is indirect and deferred, since a later connection to a de-pinned host is only downgradable if the attacker can also intercept that subsequent traffic. No public exploit code has been identified at time of analysis and there is no indication of active exploitation. Fixes ship in curl 8.23.0, which resolves this issue alongside twenty-three other CVEs published on the same date.
RemediationAI
Upgrade to curl/libcurl 8.23.0, which is the vendor-released patch for this issue and includes the fixing commits referenced from https://curl.se/docs/security.html; the same release also resolves the other twenty-three advisories published in the same batch, so a single upgrade clears the entire set. Where an immediate upgrade is not possible, the most effective compensating control is to stop using persistent HSTS: omit the curl --hsts <file> option (or the -H alias) and do not set CURLOPT_HSTS in libcurl integrations, which removes the file an attacker could erase - the trade-off is that HSTS pins are then lost between invocations, so a subsequent session to a previously pinned host could still be downgraded by an on-path attacker. A secondary hardening step is to make the HSTS cache file non-writable by the process (read-only mount, or restricted file permissions) so a hijacked response cannot mutate stored entries, with the side effect that legitimate new HSTS entries will no longer be learned or updated across sessions. Because exploitation also requires server control or an active man-in-the-middle position, deployments that terminate outbound TLS through a controlled egress proxy with certificate validation intact substantially reduce practical risk. Monitor the project's vulnerability table at https://curl.se/docs/security.html for the per-CVE first/last affected version detail before deciding which pinned versions to rebuild.
Affected ProductsAI
curl and libcurl builds from the release branch through 8.22.0 are affected, and the fix is delivered in curl 8.23.0; the vulnerability table entry for this issue's sibling HSTS flaws lists a first-affected version and a last-affected version of 8.22.0, and the oss-security advisory confirms the whole set of twenty-four issues is resolved by the 8.23.0 release. Exposure requires the HSTS persistence feature to be active - the curl command-line tool invoked with --hsts <file>, or an application embedding libcurl that sets CURLOPT_HSTS to a writable cache file - so default builds that never enable persistence are not affected in practice. No CPE strings were supplied with this record, so exact vendored-package boundaries (Linux distributions, container base images, language bindings bundling libcurl) must be derived from each vendor's own curl version. Vendor and project advisories are at https://curl.se/docs/security.html and the release announcement at https://seclists.org/oss-sec/2026/q4/154, with an additional third-party advisory reference at https://rock-solid.curl.dev for the project's LTS support branch.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
HSTS (HTTP Strict Transport Security, RFC 6797) lets a server instruct a client to treat a host as HTTPS-only for a given max-age. curl implements this via an in-memory HSTS store that can be persisted to and loaded from a file - the --hsts <file> command-line option or the libcurl CURLOPT_HSTS option. The flaw is an integrity failure in how curl processes incoming Strict-Transport-Security response headers against that persisted store: a server-supplied header (such as one carrying max-age=0, or an otherwise malformed/attacker-influenced value) causes curl to delete entries already saved on disk rather than only affecting the current host's own directive. Because the HSTS file is a shared, cross-host trust cache, corrupting it has effects well beyond the responding origin. No CWE was assigned in the provided data, but the root-cause class is improper validation of externally supplied data written into a persistent security-policy store. This CVE is part of a cluster of HSTS/cache-handling fixes in curl 8.23.0, including CVE-2026-87862 (cache import drops a longer-lived child entry) and CVE-2026-86412 (server-set cookie erases the cookie jar), which suggests a broader review of persistence-layer state handling in the release. The affected component is curl/libcurl itself, not a plugin, and the exposure is bounded by whether persistence was enabled and whether the attacker controls or can MITM the server curl talks to.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
Server-delivered response so AV:N/PR:N/UI:N; AC:H because non-default HSTS persistence must be enabled and harm needs a follow-on downgrade; only HSTS-store integrity affected (I:L), no C/A impact.
Description PRE-NVD
Threat Intelligence Overview
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
Attack Technique
OS command injection occurs when an application passes unsanitized user input directly into system shell commands.
GitHub PoC
Exploit-DB