CVE-2026-5773

What it actually does

libcurl’s SMB(S) connection reuse logic can incorrectly treat an existing connection to the same SMB server as valid for a later transfer that targets a different SMB share. In affected applications that use libcurl for SMB or SMBS transfers, a request intended for one share may be serviced over a connection associated with another share. The practical result is request confusion: the application may download data from the wrong share or upload data into the wrong share while using the same server name and the same credentials. This primarily affects confidentiality and data-placement correctness; it is not a generic arbitrary code execution flaw.

Why it matters to the business

Applications that use libcurl for SMB(S) transfers may retrieve the wrong files or place files in the wrong repository, potentially exposing sensitive data, corrupting business workflows, or causing records to be stored in unintended locations. The issue is especially relevant for automation, backup, document-processing, file-ingestion, and server-side URL-fetching systems that access multiple SMB shares on the same server. Although the issue is not currently listed in CISA KEV and EPSS is low, exploit code is reported as available and the issue has been public for about 90 days, so internet-facing or user-influenced file-transfer services should be prioritized.

How an attack unfolds

An attacker looks for an application that uses libcurl to perform SMB or SMBS transfers and can be influenced to make multiple requests to different shares on the same SMB server. The attacker then causes or waits for a valid SMB connection to be established to one share, followed by another transfer that should target a different share on the same server. Because of the faulty connection-reuse decision, libcurl may reuse the existing connection tied to the wrong share. If the application is downloading, it may receive a file from the unintended share; if uploading, it may write data into the unintended share. The attacker’s success depends on request ordering, connection pooling behavior, use of SMB(S), and whether the application accepts attacker-controlled or semi-controlled SMB URLs or paths.

How to fix it

Upgrade curl/libcurl to a version that contains the vendor fix when available from the operating system, package manager, container base image, or embedded software supplier. Because no fixed versions were provided in the input, use vendor advisories and distribution security errata to identify the exact corrected package for each platform. Rebuild and redeploy statically linked applications, appliances, containers, and language bindings that bundle libcurl. As interim mitigation, avoid using libcurl for SMB(S) transfers where requests to multiple shares on the same server can occur, disable SMB(S) URL handling in server-side fetchers if not required, segregate transfers by process or handle where practical, clear or avoid connection reuse for SMB(S) workflows, and restrict user-controlled SMB(S) destinations.

How to confirm the fix worked

Inventory systems for curl/libcurl packages and embedded copies, then verify that the installed runtime library is the corrected vendor build rather than only the command-line curl binary. Confirm application dependency trees, container images, and statically linked binaries have been rebuilt against the fixed libcurl. Functionally test representative SMB(S) workflows by performing sequential transfers to different shares on the same server and confirming that each transfer reads from or writes to the intended share. Where SMB(S) support is not required, validate that applications reject smb:// and smbs:// URLs or that the protocol is disabled in libcurl allowlists.

Typical attack path

1. Identify an application or service that uses libcurl for SMB or SMBS transfers.
2. Determine whether the application can be made to access multiple shares on the same SMB server.
3. Trigger or observe a transfer that opens a reusable SMB connection to one share.
4. Trigger a subsequent transfer intended for a different share on the same server before the connection pool entry expires.
5. Rely on libcurl’s faulty reuse logic to service the second request over the wrong share context.
6. Harvest incorrectly returned data or cause an upload to be written to an unintended share.

How to detect it

There is no unique network signature or file artifact that proves exploitation because the vulnerable behavior looks like legitimate SMB(S) traffic using valid credentials. To investigate possible prior exploitation, correlate application logs, libcurl/curl verbose logs if enabled, SMB server audit logs, file server access logs, and data-loss-prevention events. Look for service accounts accessing SMB shares they do not normally use, unexpected reads shortly after reads from a different share on the same server, uploads appearing in the wrong share or directory, mismatches between application-requested SMB paths and SMB server-side access records, and user-initiated requests that caused back-to-back SMB(S) transfers to different shares on the same host. Pay particular attention to systems where users can submit URLs or paths that are later fetched server-side, and review historical activity since public disclosure if logs are available.

What your security team should do

• Prioritize systems that use libcurl for SMB(S), especially file-ingestion services, backup jobs, document automation, and server-side URL-fetching features.
• Treat exploit availability and the 90-day public exposure window as reasons to remediate even though the CVE is not currently in CISA KEV and EPSS is low.
• Inventory operating-system packages, containers, appliances, and statically linked applications for affected curl/libcurl versions and embedded copies.
• Upgrade or rebuild affected components using vendor-corrected curl/libcurl packages as soon as available.
• Temporarily disable or block smb:// and smbs:// URL handling in applications where SMB(S) transfers are not business-critical.
• Review SMB share permissions and reduce cross-share read/write access for service accounts to limit the impact of wrong-share access.
• Add regression tests for applications that perform sequential SMB(S) transfers to multiple shares on the same server.
• Monitor SMB server logs and application transfer logs for unexpected access to shares by service accounts that normally should not touch them.