CVE-2023-38546: libcurl Cookie Duplication Bug and Patch 8.4.0

A subtle bug in libcurl’s handle-duplication logic can let an attacker plant cookies into a running process under a narrow set of conditions — a reliability bug that turned into a security issue and was assigned CVE‑2023‑38546. The flaw is small in scope, rated low severity by the curl project, and was fixed by the curl maintainers in the 8.4.0 release; nonetheless it is an instructive example of how API semantics, file-system assumptions, and library embedding can combine to create surprising behavior that affects real-world applications.

Background / Overview​

libcurl exposes easy handles (the CURL easy handle) which encapsulate the state for individual transfers. Applications create, configure, reuse, and sometimes duplicate these handles. The API function curl_easy_duphandle() was added precisely for that purpose: clone the handle state so you can reuse configuration without rebuilding it from scratch. The CVE arises from what gets cloned — specifically the “cookies enabled” flag — being copied without copying the cookie storage state correctly.
When a handle with cookies enabled is duplicated, the clone inherited the cookie-enabled state but not the cookie list itself. If the original handle had never been instructed to read cookies from a file, the cloned handle recorded a filename of the literal text none (four ASCII letters, no quotes) as if that were the cookie file. Subsequent use of that clone — when the application does not explicitly set a cookie source — causes libcurl to attempt to read cookies from a file named none in the current working directory. If an attacker can place a readable file named none in the program’s working directory, and the file is in the correct cookie-file format, libcurl will load those cookies into the cloned handle’s cookie jar at runtime. That sequence of conditions is what enables an attacker to “insert cookies at will” into a process that embeds vulnerable libcurl versions.
Affected libcurl versions were 7.9.1 up to and including 8.3.0; the fix landed in curl 8.4.0. The curl advisory identifies the root cause as an instance of CWE‑73 (External Control of Filename or Path). The project set a low severity score because exploiting it requires a particular chain of circumstances and because cookie injection — while potentially useful to an attacker — is not as powerful as a remote code execution bug.

---

How the flaw works — a technical breakdown​

1. Handle duplication semantics​

• libcurl’s easy handle contains many configuration items: URLs, headers, cookies, SSL options, timeouts and more.
• curl_easy_duphandle() is intended to clone that configuration so an application can fork a base handle and run multiple, slightly different transfers concurrently.

2. Cookie enabling vs. cookie storage​

• There are two orthogonal concepts: the cookie-enabled boolean (is cookie handling turned on?) and the cookie storage (the list of cookies, and whether they were loaded from a file).
• The bug copies the boolean but fails to copy the cookie storage; the duplicated handle thinks it should load cookies from a named source but doesn’t have a proper pointer to the original cookie list. Instead it records the literal filename none.

3. The file named "none"​

• If the duplicated handle is used without the application explicitly setting a cookie file or cookie list, libcurl attempts to load cookies from its stored filename. Because that filename is the literal string none (not a null/empty sentinel), the library will try to open a file by that name in the process’s current working directory and parse it as a cookie jar. If an attacker can create such a file and control its contents, those cookies are loaded into the running process’s cookie jar and will be used for subsequent transfers made through that handle.

4. Why the attack surface is small but non-zero​

• The bug requires all of these to be true:
• The process uses a vulnerable libcurl version (7.9.1 ≤ version ≤ 8.3.0).
• The application calls curl_easy_duphandle() on an easy handle with cookies enabled.
• The source handle never read cookies from a disk file (so the duplicated handle records filename "none").
• The cloned handle is used without the application explicitly setting a cookie file or otherwise overriding that state.
• An attacker can place (and ensure read access to) a file named none in the process’s current working directory, and that file must be in a format libcurl will accept as cookies.

Each condition reduces practical exploitability, but none are impossible in real-world deployments — especially in complex or poorly constrained environments like container images, multi-tenant hosts, developer machines, CI runners, or user-mode services started from writable directories.

---

Who and what is affected​

• The flaw affects libcurl as a library embedded by applications; the curl command-line tool is not affected by the exploit scenario described. The vulnerability was introduced by a commit and only became exploitable once the duphandle API behavior was present; applications that never duplicate handles are not at risk from this particular path.
• Distributions and vendors that packaged the affected libcurl versions released advisories and updates after the curl project published its advisory. Multiple Linux distribution advisories and cloud vendor security bulletins track the issue and the corresponding fixes or patches. System integrators and software vendors who bundle libcurl should verify whether their builds used an affected libcurl build.
• In practice the more likely victims are applications that:
• embed libcurl directly (server-side components, agent software, middleware),
• duplicate already-configured handles for convenience,
• run with a current working directory that an attacker can write to (or can be influenced), or
• are run in environments where third parties can drop files in the filesystem (shared directories, insecure container volumes, unattended developer machines).

---

Vendor response, timeline and fix​

• The curl project coordinated a fix and released curl 8.4.0 on October 11, 2023. The release removes the problematic behavior of storing a filename in the cookie struct for duplicated handles; the fix was back-ported where applicable and the advisory lists the recommended mitigations. The bug was reported via HackerOne and credited; the advisory includes a timeline for reporting and remediation.
• Downstream vendors (Linux distributions, cloud IMGs) issued packages or advisories after the upstream fix; cloud provider advisories and distribution security trackers list corresponding package updates. Administrators should check the platform-specific security notices for their distributions and update libcurl/curl packages that include the library.
• Public-facing vulnerability databases (NVD, vendor trackers) recorded the CVE and assigned it a low base severity; nonetheless the libraries and OS packages were patched or upgraded in the weeks following disclosure.

---

Practical exploitability and "in the wild" status​

Multiple security vendors and researchers examined the issue at disclosure time. The consensus in public advisories was that there were no known in‑the‑wild exploit reports for CVE‑2023‑38546 at the time the advisories and vendor write‑ups were published. Analysts noted that the chain of preconditions makes large-scale exploitation unlikely compared with higher‑severity, memory‑corruption bugs that permit remote code execution. Still, the potential for cookie-based session manipulation in specific deployment contexts was considered worth patching.
It is worth underlining what “no known in‑the‑wild reports” means: public telemetry and vendor scrutiny did not show evidence of exploitation at disclosure, but that does not logically imply zero risk — it only means there was no publicly disclosed proof of exploit campaigns at that time. Organizations should assume that any publicly disclosed vulnerability could eventually be weaponized and should prioritize fixes according to exposure and operational impact.

---

Developer and operator guidance — concrete steps​

Whether you are an application developer, packager, or system administrator, here are the prioritized actions to reduce risk.

Immediate (apply within days)​

• Upgrade libcurl/curl to 8.4.0 or later where possible. This is the canonical fix and the safest long-term resolution. Verify your platform’s package sources and apply vendor-supplied updates if they exist.
• If you cannot upgrade immediately, apply the in‑process mitigation suggested by the curl advisory: after calling curl_easy_duphandle() on a handle that may have cookies enabled, call:
• curl_easy_setopt(dup, CURLOPT_COOKIELIST, "ALL");
  This clears the cloned handle’s cookie list and avoids loading cookies from a filename wrongly recorded as "none". Use this as a stopgap until you can move to a patched libcurl.

Example (C):

CURL *dup = curl_easy_duphandle(orig);
if(dup) {
   curl_easy_setopt(dup, CURLOPT_COOKIELIST, "ALL");
   // ... use dup ...
}

• Audit deployments and packages for libcurl usage and version. Search installed packages, container images, and embedded libraries inside product bundles. Many vendors embed libcurl in binaries; a binary search for the libcurl SONAME or the presence of curl symbols is often required. Distribution security advisories list packaged updates — consult them and apply patches.

Short term (weeks)​

• Check application design: avoid running network-facing services with writable current working directories that untrusted users can reach. Consider changing service start-up scripts so the working directory is a non-writable, fixed directory (e.g., the application installation folder or a protected runtime directory). This does not directly fix the library bug but reduces the window for an attacker to drop a file named none.
• Instrument and monitor: add checks to detect the presence of files named none in directories used by network services, and alert when cookie files are loaded at runtime unexpectedly. Runtime logging that traces when libcurl reads a cookie file (or when cookies are loaded into an easy handle) can help detect anomalous behavior.

Longer-term (months)​

• Harden supply chain and patching: ensure vendors and internal teams have a clear process for updating embedded libraries like libcurl. The curl project releases new versions periodically; products that bundle upstream libraries should have a documented cadence for security updates. The macOS case (where the OS shipped an older curl build and later upgraded) shows how platform packaging lag can leave users on vulnerable snapshots until vendors ship their OS updates.
• Review API usage: developers should audit whether their applications need to duplicate handles at all. If cloning is used purely for convenience, refactor to use explicit creation and configuration of new handles to avoid accidental state inheritance. Document cookie semantics clearly in internal API guidelines.

---

Detection and forensic guidance​

Because this vulnerability results in cookie injection rather than memory corruption or RCE, indicators of compromise and forensic traces are subtle:

• Look for unexpected cookie files: search filesystem snapshots and logs for the existence of a file literally named none in directories where affected processes run, and check timestamps and file ownership. Detecting writes to such files by untrusted users or processes merits immediate investigation.
• Audit libcurl behavior: enable or add debug logging around libcurl cookie operations. If an application logs when it loads a cookie file or when a handle is duplicated, those logs help identify whether a duphandle triggered a cookie load from an unexpected filename.
• Search for vulnerable artifacts: enumerate binaries and packages to find which ones link to libcurl and check versions. Container images, plugins, and third‑party tools are likely places where vulnerable libcurl builds persist. Vendor advisories and the NVD entry can help determine whether a specific package corresponds to the affected version range.
• Correlate authentication/logon anomalies: if an attacker can inject cookies that allow session impersonation, watch for anomalous access patterns or session creations correlated to hosts where vulnerable libcurl instances are running.

---

Critical analysis — strengths and risks of the response​

What was done well​

• The curl project issued a focused advisory, implemented a clear fix, and coordinated the release (curl 8.4.0) timely with disclosure. The advisory included mitigation options and a succinct explanation of the root cause and the exact code path affected. That transparency made it practical for both packagers and integrators to respond quickly.
• Downstream vendors and distributions picked up the patching work and produced advisories or package updates. Security vendors analyzed exploitation risk and, importantly, communicated there were no known campaigns exploiting this issue at disclosure. That kind of vendor collaboration is what makes patching ecosystems effective.

Remaining risks and blind spots​

• The vulnerability demonstrates a perennial subtlety: API design decisions that seem purely functional (duplicate a handle’s state) can carry security semantics (what sentinel values mean). Libraries must be conservative about copying state that references external resources (such as disk filenames). The original behavior of storing "none" as a literal filename is an example of an implementation detail becoming a security hazard.
• Even low‑severity bugs matter in embedded contexts. A low‑severity library issue can be a powerful tool in a larger adversary playbook if the environment exposes the necessary preconditions. Shared developer machines, misconfigured CI runners, and publicly writable volumes in containers are real environments where an attacker could plausibly place a crafted file named none. Operational hygiene (writable CWDs, ephemeral build agents) is uneven across organizations and remains a recurring attack surface.
• Patching lag in vendors and OS distributions means some users continue to run older, vulnerable libcurl builds for weeks or months. Examples where platforms shipped older libcurl builds and later quietly upgraded them show that operators must be proactive in tracking library versions embedded in their stacks rather than relying on OS-level release notes alone.

---

Takeaways for WindowsForum readers (practical checklist)​

• If you maintain Windows or cross‑platform applications that embed libcurl, determine whether your product used a vulnerable libcurl version between 7.9.1 and 8.3.0. If so, prioritize building and shipping a new bundle with curl 8.4.0 or later.
• Search your systems and images for files named none in application working directories and remove or quarantine unexpected instances. Consider adding an automated check in build/CI pipelines to flag the presence of files named none.
• For product developers: after any use of curl_easy_duphandle(), either immediately call curl_easy_setopt(dup, CURLOPT_COOKIELIST, "ALL") or avoid duplicating cookie-enabled handles entirely when the cookie source is ambiguous. This is a low-effort and effective in-process mitigation until you can ship a libcurl upgrade.
• For enterprise patching teams: prioritize updating libcurl in server and endpoint images where the library is embedded in managed software. Track vendor advisories for packaged updates and coordinate staged rollouts that cover both servers and client tools that embed the library.

---

Conclusion​

CVE‑2023‑38546 is an example of a class of vulnerabilities that arise not from classic memory corruption, but from unexpected semantics and file‑system assumptions inside common libraries. The bug’s exploitation path is narrow and the practical severity was assessed as low, yet the fix is straightforward and the operational implications are non-trivial for software that embeds libcurl. The responsible course for operators and developers is clear: patch to curl 8.4.0 (or later) where possible, implement the advised temporary mitigations if immediate upgrades aren’t possible, and review application startup and working-directory practices to reduce the chance an attacker can manipulate application-visible files. The incident is a useful reminder that even small API‑level errors in ubiquitous libraries deserve swift attention.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center