The curl project has published an advisory for CVE-2026-3805, a
use-after-free bug in SMB connection reuse that affects libcurl and the curl command-line tool in releases 8.13.0 through 8.18.0 and was fixed in curl/libcurl 8.19.0; the flaw occurs when a second SMB request reuses a pooled connection and causes curl to dereference a pointer into freed memory, which can lead to a crash and — in narrow conditions — information leakage or further memory corruption. (
curl.se)
Background
SMB (Server Message Block) remains a core protocol for file and resource sharing across platforms. Many command-line tools, libraries, and embedded applications include
libcurl to perform SMB, HTTP(S), FTP and other transfers. Because libcurl is so widely reused, a vulnerability in its protocol handling can surface across a broad range of products and appliances, not just the curl executable itself.
The issue tracked as
CVE-2026-3805 was reported to the curl project in early March 2026 and coordinated fixes were released on March 11, 2026 as part of libcurl 8.19.0. The curl advisory describes the fault as a classic C-era memory-management mistake: a
pointer into pooled memory remains in a request structure when the pooled connection is recycled, the underlying memory is freed, and a later strlen() reads that freed pointer. The upstream advisory labels the severity as
Medium and recommends upgrading to 8.19.0 or applying the patch. (
curl.se)
What happened: technical summary
Root cause (high level)
At a technical level, the bug is caused by storing a
non-owning pointer into a buffer that the connection pooling code later frees. When the pooled SMB connection is reused for a second URL targeting the same host, memory management steps free a buffer that other request fields still reference. A subsequent operation — specifically a call to strlen(req->path) — reads the freed memory and triggers a heap use-after-free. That dereference can cause an immediate crash (denial-of-service), or in some tight scenarios where freed memory is reallocated with attacker-controlled data, it can produce information leakage or further memory corruption. (
redpacketsecurity.com)
Where it occurs
- Affects both libcurl and the curl command-line tool when built with SMB support and when connection reuse/pooling is in use.
- Introduced in curl 8.13.0 and present through 8.18.0; fixed in 8.19.0. (curl.se)
Reproduction considerations
Security researchers who reported and analyzed the bug used AddressSanitizer (ASAN) and local test servers to reproduce the issue. The general reproduction pattern requires making two SMB requests to the same host so that the second request reuses the pooled connection; ASAN will reliably flag the heap-use-after-free during testing. Because exploitation paths rely on precise memory state and often the attacker’s ability to control what gets allocated in the freed region, triggering reliable data leakage or remote code execution is non-trivial in practice — but a crash is practically guaranteed when the bug is hit. (
redpacketsecurity.com)
Who and what is affected
- Affected versions: curl/libcurl 8.13.0 through 8.18.0 (inclusive). (curl.se)
- Fixed in: curl/libcurl 8.19.0. Upgrading is the primary remediation. (curl.se)
- Downstream footprints: libcurl is embedded in many applications (desktop clients, backup utilities, IoT appliances, custom enterprise software). Not all distributions or products will show the vulnerable curl version, but the potential exposure extends beyond systems that expose the curl binary itself. (curl.se)
Ubuntu's security team published a related advisory (USN-8084-1) on March 11, 2026 listing CVE-2026-3805 alongside other curl fixes and indicating that the issue could cause curl to crash or possibly execute arbitrary code under certain circumstances; Ubuntu's note also includes package-level fixes for affected Ubuntu releases. This underscores that the vulnerability was triaged and handled by major distributions quickly after the upstream fix. (
ubuntu.com)
Impact analysis: realistic attacker models
Guaranteed effects
- Client crash (DoS): When the bug is triggered, the client process running curl/libcurl will likely crash. This is a reliable outcome and the easiest abuse case: an attacker operating an SMB server (or key element in the path) can cause the client to issue the sequence that triggers the freed-pointer read. (redpacketsecurity.com)
- Potential information leakage: If the freed region is reallocated with attacker-controlled or otherwise sensitive data before the strlen() is executed, that data can be read and copied into an outgoing packet. In very specific conditions this could leak memory contents that were thought to be inaccessible. The upstream advisory notes this is plausible but hard for an attacker to control. (curl.se)
Less likely, higher-impact scenarios
- Remote code execution (RCE): The curl advisory treats this outcome as unlikely; however, Ubuntu’s advisory mentions the possibility of arbitrary code execution under contrived conditions. Historically, use-after-free flaws have occasionally been escalated into code execution when an attacker can precisely manipulate heap layout; the difficulty is high but not zero. Organizations that require a conservative security posture should assume worst-case potential and patch promptly. (curl.se)
Attack surface and prerequisites
- The vulnerability is client-side, meaning a malicious or compromised SMB server (or a man-in-the-middle that can manipulate SMB responses) is the most realistic attacker-controlled element.
- The attacker needs to influence the sequence and timing of connection reuse and memory allocation, which raises exploitation complexity.
- Many real-world consumers of libcurl do not enable SMB support, reducing the reachable exposure for some environments. Still, a surprising number of network tools and embedded products do include SMB-capable libcurl builds. (curl.se)
Vendor and ecosystem response
- The curl project released a formal security advisory and coordinated the fix into curl/libcurl 8.19.0, published on March 11, 2026. The advisory includes the root cause, affected versions, and specific remediation steps: upgrade, apply the patch and rebuild, or avoid SMB transfers as a last resort. (curl.se)
- Major distributions (Ubuntu among them) issued security notices and released packaged fixes for affected releases the same day. Operators should watch their distribution's package channels and vendor-specific advisories to ensure they receive the patched libcurl package versions appropriate to their platform. (ubuntu.com)
- The original reporter and the patch author are publicly credited: Daniel Wade (reporter) and Stefan Eissing (patch contributor). The disclosure was coordinated through the curl project's HackerOne program and the normal CVE assignment channels. (redpacketsecurity.com)
Practical mitigation and remediation checklist
If you manage systems, applications, or devices that include libcurl, follow this prioritized checklist:
- Inventory: Identify every runtime that bundles or relies on libcurl. Search for:
- The curl binary (use curl --version on systems where curl is installed).
- Applications that bundle libcurl (check installed package manifests, vendor notices, and third-party software lists).
- Container images and embedded devices (firmware and appliance vendors often publish component manifests).
- Confirm versions: For each system, confirm the libcurl/curl version. The vulnerability affects versions 8.13.0 through 8.18.0 inclusive; anything older than 8.13.0 or updated to 8.19.0 and later is not affected. Upstream advisory lists exact version boundaries. (curl.se)
- Apply updates: Prefer upgrading to curl/libcurl 8.19.0 where feasible. For distribution-managed systems, install the vendor’s patched packages (Ubuntu, Red Hat, SUSE, etc. provide distro-specific updates). (curl.se)
- Rebuild where necessary: If you ship or maintain custom builds of libcurl, apply the upstream patch and rebuild with your configuration. The curl advisory gives a patch link and the upstream commit that resolves the issue. (curl.se)
- Temporary workarounds: If an immediate upgrade is impossible:
- Consider disabling SMB support in libcurl builds until you can patch. This may be practical for many HTTP-only workloads. (curl.se)
- Where possible, avoid using connection pooling for SMB endpoints; however, this may be impractical or insufficient as the precise trigger relies on reuse semantics.
- Monitoring and detection: Add checks to your telemetry for unexpected crashes in processes that embed libcurl or for sequences of SMB requests that coincide with process restarts. For development builds, ASAN (AddressSanitizer) is extremely effective at surfacing use-after-free conditions and can validate fixes during QA. (redpacketsecurity.com)
- Confirm third-party vendor patches: Many appliances and proprietary apps bundle libcurl; confirm with vendors that they have integrated the 8.19.0 fix or otherwise patched their product.
Detection, forensics, and indicators of compromise
- Crash traces: Look for stack traces referencing libcurl functions or your application’s SMB handling. A recurring crash during sequential SMB transfers to the same host is a red flag.
- ASAN output: If you can reproduce on a dev/test build, ASAN will print a clear use-after-free diagnostic with allocation and free backtraces. This is useful to confirm vulnerability presence and verify remediation. (redpacketsecurity.com)
- Network telemetry: Monitor for suspicious or unexpected SMB servers your clients contact. An uptick in SMB requests to untrusted hosts that correlate with client crashes should trigger deeper inspection.
- Binary/version indicators: Collect and catalog libcurl versions from endpoints. Deploy patch-management scans and compare installed versions to the affected range (8.13.0–8.18.0). (curl.se)
Why this matters despite limited exploitability
It’s tempting to minimize use-after-free bugs that require being the server the client contacts — and curl’s advisory states the real-world exploitation to leak specific secrets
seems extremely hard. However:
- libcurl is ubiquitous: it appears in desktop clients, backup software, embedded appliances, and SDKs. A flaw that can cause consistent process crashes can be weaponized for targeted denial-of-service campaigns against an organization’s tooling or for supply-chain manipulations that introduce further vulnerabilities.
- Attackers have historically chained client-side logic bugs with memory-management imperfections to achieve higher-impact results. Given the large install base, any systematic weakness merits rapid remediation.
- The conservative security posture is to treat client-side memory-safety issues as high priority to fix, even where proof-of-concept exploitation beyond crashing is limited. Upgrading is low-friction for many environments and removes a potential attack avenue quickly. (curl.se)
Risk assessment and enterprise recommendations
- Risk to typical enterprise users: Medium-low if SMB is not used (many web-only deployments do not compile SMB support). Medium if SMB-capable clients are widespread in your environment and those clients are configured to talk to untrusted hosts.
- Priority level: Patch immediately where libcurl is present and SMB is enabled. For large fleets, prioritize servers and endpoints used by distributed workforce tools and automated transfer systems that contact external SMB shares.
- Long-term posture: Add libcurl (and other third-party libraries) into your software bill-of-materials (SBOM) tracking and vulnerability management pipeline. Prioritize runtime memory safety scanning in your CI (ASAN, memory sanitizers) and require upstream patch tracking for embedded libraries.
Developer- and vendor-focused notes
- If you maintain an application that links libcurl statically, include the patch and rebuild all binaries; dynamic linking only helps if you can push a shared library update without breaking ABI compatibility for your product.
- If you ship an SDK that exposes SMB transfers, add explicit guidance for customers to update to 8.19.0 and publish the patched artifact quickly.
- For maintainers, the fix is a reminder that non-owning pointers into pooled or temporary buffers are a common source of memory-safety bugs in C. Consider targeted refactors that emphasize ownership (explicit allocations per-request or well-scoped lifetime annotations) to reduce the chance of regressions.
Transparency and disclosure notes
The curl project coordinated publication and credit to the reporter and patch author; the issue was reported via their HackerOne program and assigned CVE-2026-3805. The public advisory is explicit about the affected version range and the fix commit. The curl advisory and HackerOne disclosure include useful reproduction and root-cause details that help vendors and downstream packagers audit their builds. (
curl.se)
A Microsoft Security Response Center (MSRC) link for CVE-2026-3805 may show limited content without JavaScript enabled; organizations relying on vendor product pages should confirm visibility of advisories in their preferred vendor consoles. If a vendor page appears empty or shows a client-side rendering restriction, contact vendor support or consult the upstream advisory and distribution security notices for confirmation. (
msrc.microsoft.com)
Final assessment — strengths, residual risks, and next steps
- Strengths
- The curl project released a patch quickly and published clear advisory details (affected versions, root cause, fix commit and recommended actions). Upstream credit and timeline were fully transparent. (curl.se)
- Distributions like Ubuntu synchronized notices and released packaged updates the same day, making it straightforward for administrators to remediate using normal update channels. (ubuntu.com)
- The technical root cause is well documented, and the reproduction path is approachable for developers using ASAN during testing, enabling rapid verification. (redpacketsecurity.com)
- Residual risks
- Some embedded devices and proprietary applications may not receive timely updates; they could remain vulnerable longer than mainstream desktop or server packages.
- The practical difficulty of exploiting the bug to achieve targeted data exfiltration or code execution reduces the immediate likelihood of mass exploitation — but does not eliminate risk for targeted operations where an attacker controls a malicious SMB server. (curl.se)
- Actionable next steps for operations teams
- Immediately inventory and patch all curl/libcurl instances to 8.19.0 or later where SMB support is present. (curl.se)
- Confirm vendor statements and patch status for appliances and third-party tools that embed libcurl. (ubuntu.com)
- Add memory sanitizers (ASAN) to CI pipelines for components that use libcurl extensively; use ASAN to verify fixes in dev/test. (redpacketsecurity.com)
- Instrument crash-monitoring and SMB telemetry to detect anomalous behaviors that could indicate exploitation attempts.
CVE-2026-3805 is a sober reminder that even mature, well-maintained networking libraries can fall prey to classical C memory-management mistakes. The path to remediation is clear: verify your exposure, apply the 8.19.0 fix (or applicable vendor patches), and improve lifecycle controls so that third-party library updates are applied consistently across all production footprints. The immediate technical risk favors denial-of-service and accidental memory disclosure; the long-term security posture requires concerted inventory, patching, and a readiness to treat client-side memory-safety bugs as high-priority fixes. (
curl.se)
Source: MSRC
Security Update Guide - Microsoft Security Response Center