CVE-2026-3805

What it actually does

This is a use-after-free flaw in curl's SMB handling. When curl performs a second SMB request to the same host, it can reuse a pointer to memory that has already been freed. That stale pointer can cause memory corruption and process instability, most realistically resulting in a crash of the curl-using process. The assigned impact is availability-only: no direct confidentiality or integrity impact is indicated by the provided scoring.

Why it matters to the business

Applications, automation jobs, backup workflows, monitoring tools, package retrieval processes, or other services that use curl/libcurl with SMB URLs could be crashed by interacting with a malicious or specially crafted SMB endpoint. This can interrupt file-transfer workflows and dependent business processes. The issue is not currently listed in CISA KEV, has no reported exploit maturity, and has low EPSS, so broad active exploitation is not indicated; however, internet- or network-exposed workflows that automatically fetch SMB resources should still be prioritized for remediation because exploitation does not require authentication.

How an attack unfolds

An attacker positions or controls an SMB server that a vulnerable curl/libcurl client will contact, or otherwise causes a vulnerable application to make repeated SMB requests to the same SMB host. During the first request, curl allocates and later frees internal SMB-related memory. On a subsequent request to the same host, vulnerable versions may incorrectly reuse a pointer into that freed memory. The attacker-controlled interaction can then trigger invalid memory access in the client process, causing the command-line curl process or the application embedding libcurl to terminate unexpectedly. Based on the provided impact data, exploitation is expected to be denial-of-service rather than data theft or code execution.

How to fix it

Upgrade curl/libcurl to a vendor release that contains the fix for CVE-2026-3805 once available from the operating system, container image, language runtime, appliance, or application vendor. Because no exact fixed versions were provided, use vendor advisories and package repositories as the source of truth. Rebuild or redeploy applications that statically link libcurl, because updating the system package alone will not fix embedded copies. If immediate patching is not possible, reduce exposure by disabling or blocking SMB URL handling where feasible, restricting outbound SMB traffic to trusted destinations, preventing untrusted users from supplying SMB URLs to curl-backed workflows, and isolating workloads that must retrieve SMB resources.

How to confirm the fix worked

Confirm the installed curl and libcurl versions against the relevant vendor advisory and verify that the patched package or rebuilt application is actually in use at runtime. Inventory both command-line curl installations and applications that embed or statically link libcurl. Test representative workflows that use SMB URLs, especially repeated requests to the same host, to ensure they no longer crash. For containers and appliances, verify the base image or firmware includes the corrected curl/libcurl build. Confirm network controls block unexpected outbound SMB access where that mitigation is relied upon.

Typical attack path

1. Identify an application, script, service, or automation path that uses curl/libcurl to access SMB URLs.
2. Control, impersonate, or lure the vulnerable client toward an SMB server that can receive repeated requests from the same client.
3. Cause the client to perform an initial SMB request to the attacker-controlled or malicious SMB host.
4. Cause a second SMB request to the same host so curl reuses stale freed memory.
5. Trigger process instability or a crash, disrupting the curl invocation or the parent application using libcurl.

How to detect it

To determine whether exploitation may have occurred, review logs and telemetry for curl or libcurl-using processes that contacted SMB servers shortly before crashing. Relevant sources include application logs, job scheduler logs, systemd service logs, container stdout/stderr, endpoint detection telemetry, crash dumps, core dump records, Windows Error Reporting where applicable, Linux kernel or journal logs, and network telemetry for outbound SMB connections. Look for repeated SMB requests to the same host followed by segmentation faults, access violations, abnormal process termination, service restarts, failed automation jobs, or container restarts. Network logs should be reviewed for unexpected outbound TCP 445 or 139 traffic from systems that normally should not access SMB resources. Because the vulnerability does not define a unique payload string, detection is primarily behavioral: repeated SMB access by curl/libcurl followed by process crash or instability.

• curl: (23) Failed writing body
• curl: (56)
• Segmentation fault
• segfault at
• core dumped
• Access violation
• EXCEPTION_ACCESS_VIOLATION
• systemd-coredump
• Process terminated with signal SIGSEGV
• TCP/445
• TCP/139
• smb://

What your security team should do

• Inventory all uses of curl/libcurl, including operating system packages, container images, statically linked binaries, appliances, and third-party applications.
• Prioritize patching systems or applications that use curl/libcurl to access SMB URLs, especially automated workflows that process user-supplied or externally influenced URLs.
• Monitor vendor advisories for the exact fixed curl/libcurl versions and deploy them promptly when available for each platform.
• Restrict outbound SMB traffic to approved internal servers and block SMB access to untrusted networks where business requirements allow.
• Review applications that accept URLs from users or external data sources and prevent SMB schemes unless explicitly required.
• Add crash and abnormal-termination monitoring for curl-using services until remediation is complete.
• Treat the current exploitation likelihood as lower because the issue is not KEV-listed, has low EPSS, and has no known mature exploit, but do not defer remediation for systems where SMB fetches are exposed to untrusted input.