Summary

• use after free in SMB connection reuse (CVE-2026-3805)

Description

When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.

INFO

When the bad code hits, curl first makes a strlen() on the (freed) memory pointer, then checks that the size is less than or equal than 1024 for it to do something.

Then it copies that string to the outgoing package which then potentially could leak sensitive data if the application happened to put it there in the meantime since the previous transfer.

This seems extremely hard for an attacker to willingly abuse or to massage the application into leaking specific information. It also seems highly unlikely that any application ever did this sequence without getting a crash or another issue that would indicate there is a problem in curl. The risk here is therefore minimal.

CWE-416: Use After Free

Severity: Medium

Base Score:  7.5 HIGH - Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

• bad reuse of HTTP Negotiate connection (CVE-2026-1965)

Description

libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request.

INFO

libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead.

When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates connections and not requests, contrary to how HTTP is designed to work.

An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with user1:password1 and then does another operation to the same server also using Negotiate but with user2:password2 (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1...

The set of authentication methods to use is set with CURLOPT_HTTPAUTH.

Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: CURLOPT_FRESH_CONNECT, CURLOPT_MAXCONNECTS and CURLMOPT_MAX_HOST_CONNECTIONS (if using the curl_multi API).

CWE-305: Authentication Bypass by Primary Weakness

Severity: Medium

Base Score:  6.5 MEDIUM - Vector:  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

• token leak with redirect and netrc (CVE-2026-3783)

Description

When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances.

INFO

If the hostname that the first request is redirected to has information in the used .netrc file, with either of the machine or default keywords, curl would pass on the bearer token set for the first host also to the second one.

CWE-522: Insufficiently Protected Credentials

Severity: Medium

Base Score:  5.3 MEDIUM - Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

•  cross-proxy Digest auth state leak - CVE-2026-7168

Description

Successfully using libcurl to do a transfer over a specific HTTP proxy (proxyA) with Digest authentication and then changing the proxy host to a second one (proxyB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Proxy-Authorization: header field meant for proxyA, to proxyB.

INFO

An evil proxyB could use this incoming request header field to impersonate the client in communicating with proxyA, as the header contains the authenticated state.

There is nothing in the request details passed to proxyB that reveal the name or the address of proxyA, which mitigates this problem.

CWE-294: Authentication Bypass by Capture-replay

Severity: Medium

Base Score: 5.3    MEDIUM - Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

• netrc credential leak with reused proxy connection - CVE-2026-6429

Description

When asked to both use a .netrc file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.

INFO

To trigger, this flaw requires that both the original URL and the redirect URL are using clear text http:// URLs, that both are performed over the same HTTP proxy and that the same connection is reused.

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Severity: Medium

Base Score:  5.3 MEDIUM - Vector:  CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

• stale custom cookie host causes cookie leak - CVE-2026-6276

Description

Using libcurl, when a custom Host: header is first set for an HTTP request and a second request is subsequently done using the same easy handle but without the custom Host: header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.

INFO

Setting a custom Host: header is mostly done for debugging purposes when doing clear text HTTP transfers. When using HTTPS, setting a custom hostname like this is not enough for asking for a specific virtual host since then the SNI also needs to be correct. This condition reduces the impact of this flaw, and is probably a contributing factor why no one else found it before this.

CWE-346: Origin Validation Error

Severity: Low

Base Score:  7.5 HIGH - Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

• wrong reuse of SMB connection - CVE-2026-5773

Description

libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers.

libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead.

When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different "share" than the new subsequent transfer should.

This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.

INFO

curl only supports SMB version 1 and no later version. SMB version 1 is considered insecure and deprecated and is therefore commonly disabled in servers. curl is scheduled to drop support for SMB later in 2026. SMB support is opt-in since 8.20.0.

In this flaw, the code erroneously did not consider the share name as a property to match for connection reuse.

CWE-488: Exposure of Data Element to Wrong Session

Severity: Low

Base Score:  7.5 HIGH - Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

• wrong reuse of HTTP Negotiate connection - CVE-2026-5545

Description

libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host.

libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead.

When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials.

An application that first uses Negotiate authentication to a server with user1:password1 and then does another operation to the same server asking for any authentication method but for user2:password2 (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1…

INFO

The set of authentication methods to use is set with CURLOPT_HTTPAUTH.

Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: CURLOPT_FRESH_CONNECT, CURLOPT_MAXCONNECTS and CURLMOPT_MAX_HOST_CONNECTIONS (if using the curl_multi API).

CWE-305: Authentication Bypass by Primary Weakness

Severity: Medium

Base Score:  6.5 MEDIUM - Vector:  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N

• proxy credentials leak over redirect-to proxy - CVE-2026-6253

Description

curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true:

•     curl is setup to use specific different proxies for different URL schemes
•     the first proxy needs credentials
•     the second proxy uses no credentials
•     while using the first proxy (using say http://), curl is asked to follow a redirect to a URL using another scheme (say https://), accessed using a second, different, proxy

INFO

The credentials are passed on base64 encoded. The receiving proxy gets no hint as for where or how the credentials are valid.

CWE-522: Insufficiently Protected Credentials

Severity: Medium

Base Score:  5.9 MEDIUM - Vector:  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Products Affected

• Brocade SANnav base OS (OVA versions)  before 3.0.0a and SANnav 3.0.0 through 3.0.1

Products Not Affected

• Brocade Fabric OS
  [VEX Justification: Vulnerable_code_not_present]
• Brocade SANnav Standard Non-OVA deployment
  [VEX:Vulnerable_code_not_in_execute_path] 

Solution

• Security update provided in Brocade SANnav 3.0.0a OVA, OVA OS patches - 8.x (sannav_ova_8x_os_06_2026) and 9x (sannav_ova_9x_os_06_2026).

Revision History

Disclaimer

THIS DOCUMENT IS PROVIDED ON AN AS-IS BASIS SOLELY FOR INFORMATIONAL PURPOSES AND DOES NOT IMPLY ANY KIND OF GUARANTY OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. YOUR USE OF THE INFORMATION CONTAINED HEREIN IS AT YOUR OWN RISK. ALL INFORMATION PROVIDED HEREIN IS BASED ON BROCADE'S CURRENT KNOWLEDGE AND UNDERSTANDING OF THE VULNERABILITY AND IMPACT TO BROCADE HARDWARE AND SOFTWARE PRODUCTS. BROCADE RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.