CVE-2026-3805: 
cURL vulnerability analysis and mitigation

CVE-2026-3805 is a use-after-free vulnerability in curl's SMB connection reuse logic, where a second SMB request to the same host causes curl to dereference a data pointer into already-freed memory. It affects curl versions 8.13.0 through 8.18.0 (inclusive), introduced by commit f4831daa9b2a97e8a29 and fixed in 8.19.0. The vulnerability was reported on March 8, 2026, and publicly disclosed on March 11, 2026, coordinated with the release of curl 8.19.0. It carries a CVSS v3.1 base score of 7.5 (High) for availability impact, though the curl project itself rates the severity as Medium (curl Advisory, Red Hat, oss-security).

The root cause is CWE-416 (Use After Free) and CWE-825 (Expired Pointer Dereference) in curl's SMB protocol handler. When curl reuses an SMB connection to the same host for a second request, it incorrectly retains a data pointer that references memory already freed from the first transfer. The vulnerable code path first calls strlen() on the freed pointer, checks if the length is ≤ 1024, and then copies the string into the outgoing SMB packet — potentially including stale or sensitive data that happened to occupy that memory region. The bug was introduced in commit f4831daa9b2a97e8a29 and fixed in commit e090be9f73a7a71459ef678c. A proof-of-concept involving building curl with AddressSanitizer (ASAN), running a fake SMB server, and issuing sequential SMB requests (e.g., curl -u guest:guest "smb://127.0.0.1:5445/share1/file1" ... "smb://127.0.0.1:5445/share2/file2") reliably triggers the crash (curl Advisory, HackerOne PoC, oss-security).

The primary impact is a denial of service — the curl process crashes when the freed memory is accessed during a second SMB request to the same host. There is a theoretical secondary risk of sensitive data leakage: if another allocation has reused the freed memory region between the two SMB transfers, the stale contents could be copied into the outgoing SMB packet. However, the curl project notes this scenario is "extremely hard for an attacker to willingly abuse" and considers the practical risk minimal. The vulnerability affects both the curl command-line tool and libcurl, meaning any application embedding libcurl and performing sequential SMB transfers to the same host is potentially affected (curl Advisory, oss-security).

1. Setup: Build curl from source with AddressSanitizer enabled (./configure CFLAGS="-fsanitize=address" && make) to confirm the vulnerability, or use a stock vulnerable curl binary (versions 8.13.0–8.18.0).
2. Deploy a fake SMB server: Run a Python-based fake SMB server (as described in the HackerOne PoC) listening on localhost port 5445, configured to serve at least two shares (share1 and share2).
3. Trigger the UAF: Execute two sequential SMB requests to the same host using curl:

   curl -u guest:guest "smb://127.0.0.1:5445/share1/file1" "smb://127.0.0.1:5445/share2/file2"

4. Observe the crash: On the second request, curl dereferences the freed memory pointer in the SMB handler, causing a heap-use-after-free crash (visible as an ASAN report or segmentation fault).
5. Potential data leakage: In a real application context, if the freed memory has been reallocated and populated with sensitive data between the two requests, that data may be copied into the outgoing SMB packet (HackerOne PoC, curl Advisory).

• Process: Unexpected crash or segmentation fault of the curl process or any application embedding libcurl when performing sequential SMB transfers to the same host; ASAN heap-use-after-free reports in debug builds.
• Logs: Application logs showing curl/libcurl crashes or abnormal termination during SMB operations; error messages referencing SMB connection reuse or freed memory.
• Network: Malformed or truncated SMB packets sent from the curl client to an SMB server; unexpected connection resets during the second SMB request to the same host.
• File System: Core dump files generated by curl or libcurl-linked applications following SMB transfer sequences (curl Advisory, HackerOne PoC).

The primary fix is to upgrade curl and libcurl to version 8.19.0 or later, released March 11, 2026. Alternatively, the specific fix commit (e090be9f73a7a71459ef678c) can be applied and libcurl rebuilt from source. As a workaround for environments that cannot immediately upgrade, SMB transfers should be disabled or restricted — the curl advisory explicitly recommends avoiding SMB transfers as option C. Downstream distributions including Ubuntu (USN-8084-1), SUSE/openSUSE, Fedora, Amazon Linux 2023, and Red Hat have issued updated packages (curl Advisory, Ubuntu Advisory, Red Hat, oss-security).

Daniel Stenberg (curl project lead) published the release announcement for curl 8.19.0 on his blog, coordinated with the advisory disclosure. The oss-security mailing list carried the official advisory on March 11, 2026. The curl project characterized the practical risk as "minimal" given the difficulty of reliably exploiting the data leakage aspect. Social media activity was modest, with mentions on Bluesky and Mastodon. Multiple Linux distributions (Ubuntu, SUSE, Fedora, openSUSE, Amazon Linux) promptly issued security updates, reflecting standard patch cadence for curl vulnerabilities (Daniel Stenberg Blog, oss-security).