libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key.

ubuntu_linux USN-8670-1: Ubuntu 24.04 LTS / Ubuntu Pro Realtime 24.04 LTS : curl vulnerability (USN-8670-1)

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-2132 advisory.

    A use-after-free vulnerability exists in libcurl when an application configures an HTTP/2 stream-     dependency tree via CURLOPT_STREAM_DEPENDS or CURLOPT_STREAM_DEPENDS_E, subsequently invokes     curl_easy_reset(), and finally terminates the handle with curl_easy_cleanup(). During this final cleanup     phase, libcurl attempts to access and modify an internal structure that was already freed during the reset     operation. (CVE-2026-10536)

    By default, curl automatically responds to WebSocket PING frames. Because curl lacks an upper bound on     memory allocation for unacknowledged frames, a malicious server can exhaust all available memory by     flooding curl with rapid, sequential PING messages. (CVE-2026-11586)

    Successfully using libcurl to do a transfer to a specific HTTP origin (hostA) with Digest authentication     and then changing the origin to a different one (hostB) for a second transfer, reusing the same handle,     makes libcurl wrongly pass on the Authorization: header field meant for hostA, to hostB. (CVE-2026-11856)

    When a user invokes curl using a schemeless URL combined with --proto-default sftp (or scp), a disconnect     occurs between the tool layer and libcurl. The tool layer incorrectly infers the URL scheme, which     erroneously bypasses the initialization of critical SSH security options like     CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS. Conversely, the libcurl runtime     successfully honors CURLOPT_DEFAULT_PROTOCOL and establishes the connection via SFTP/SCP as specified.
    Because the tool layer skipped the security configuration, these SSH host verification options are     silently omitted, causing curl to connect to an unverified SSH remote host without throwing an error.
    (CVE-2026-12064)

    A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an     existing live connection even though the TLS configuration mismatches so it should not. (CVE-2026-8286)

    libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated     ones, even when they are set to use different services.

    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 services. (CVE-2026-8458)

    A flaw in curl's cookie parsing logic allows a malicious HTTP server to set super cookies that bypass     the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl     subsequently scopes and transmits to unrelated third-party domains. (CVE-2026-8924)

    The curl logic that works with SASL authentication could end up cleaning up the GSASL context twice     without clearing the pointer in between, making it free() the same pointer twice. (CVE-2026-8925)

    When asking curl to use a .netrc file to find credentials and at the same time specifying a URL with a     username (without a password), like https://user@example.com/, curl could wrongly get and use the password     for another user set in the .netrc file for that host if such a one exists and there is no match for the     specified user. (CVE-2026-8926)

    When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration,     libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial     transfer authenticates against proxyA using Digest auth, a subsequent transfer routed through proxyB     erroneously leaks the Proxy-Authorization: header intended solely for proxyA. (CVE-2026-8927)

    libcurl would reuse a previously created connection even when some mTLS config related option had been     changed that should have prohibited reuse.

    libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of     them matches the setup. However, some TLS settings related to client certificates were left out from the     configuration match checks, making them match too easily. In particular options related to the private     key. (CVE-2026-8932)

    libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so,     leaving the old credentials around to get used for subsequent transfers that should not know nor use them.
    (CVE-2026-9079)

    Calling curl_easy_pause() within the event-based CURLMOPT_SOCKETFUNCTION callback triggers a use-after-     free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately     after that pointer's memory has been freed. (CVE-2026-9080)

    In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a     second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid     certificate.

    When libcurl returns to the hostname the second time with a cached SSL session     (CURLOPT_SSL_SESSIONID_CACHE is not disabled) and early data enabled (the CURLSSLOPT_EARLYDATA bit is set     in CURLOPT_SSL_OPTIONS), libcurl might send off the second request's bytes on that new connection before     enforcing the certificate verification failure. Potentially leaking sensitive information. (CVE-2026-9545)

    When a libcurl-based application performs transfers via SCP:// or SFTP:// and utilizes the     CURLOPT_SSH_KEYFUNCTION callback, it may silently accept an untrusted server. This vulnerability occurs     when a server presents a host key type that does not match the specific key type already recorded for that     host in the known_hosts file. Instead of rejecting the mismatch, the callback mechanism fails to properly     enforce the restriction, allowing the connection to succeed without warning and risking a potential man-     in-the-middle attack. (CVE-2026-9547)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-106769 advisory.

    libcurl would reuse a previously created connection even when some mTLS config     related option had been changed that should have prohibited reuse.

    libcurl keeps previously used connections in a connection pool for subsequent     transfers to reuse if one of them matches the setup. However, some TLS     settings related to client certificates were left out from the configuration     match checks, making them match too easily. In particular options related to     the private key.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

An update of the curl package has been released.

The version of libcurl installed on the remote host is 7.7 prior to 8.21.0. It is, therefore, affected by an improper certificate validation vulnerability:

  - libcurl would reuse a previously created connection even when some mTLS config related option had been     changed that should have prohibited reuse. (CVE-2026-8932)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - libcurl would reuse a previously created connection even when some mTLS config related option had been     changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool     for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to     client certificates were left out from the configuration match checks, making them match too easily. In     particular options related to the private key. (CVE-2026-8932)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
345801	Amazon Linux 2023 : curl, curl-minimal, libcurl (ALAS2023-2026-2132)	Nessus	Amazon Linux Local Security Checks	Local	critical
344441	Unity Linux 20.1050e / 20.1060e / 20.1070e Security Update: curl (UTSA-2026-106769)	Nessus	Unity Linux Local Security Checks	Local	high
334708	Photon OS 5.0: Curl PHSA-2026-5.0-90-0951	Nessus	PhotonOS Local Security Checks	Local	critical
333502	Photon OS 4.0: Curl PHSA-2026-4.0-1061	Nessus	PhotonOS Local Security Checks	Local	critical
323005	libcurl 7.7 < 8.21.0 Incomplete mTLS Config Matching in Connection Reuse	Nessus	Misc.	Local	high
322442	Linux Distros Unpatched Vulnerability : CVE-2026-8932	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-8932

high

Tenable Plugins

Coming Soon

critical

high

critical

critical

high

high