The remote Redhat Enterprise Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2026:69125 advisory.

    The curl packages provide the libcurl library and the curl utility for downloading files from servers     using various protocols, including HTTP, FTP, and LDAP.

    Security Fix(es):

    * libcurl: libcurl: Security feature bypass due to improper mTLS connection reuse (CVE-2026-8932)

    * curl: curl: Information disclosure via incorrect .netrc password lookup (CVE-2026-8926)

    * curl: libcurl: Unauthorized connection reuse due to a logical error (CVE-2026-8458)

    * curl: curl: Cookie injection via malicious HTTP server using super cookies (CVE-2026-8924)

    * curl: curl: Information disclosure via incorrect Digest authentication header reuse (CVE-2026-11856)

    * libcurl: libcurl: Information disclosure due to failure to clear proxy authentication credentials     (CVE-2026-9079)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux 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 version of libcurl installed on the remote host is 8.8.0 prior to 8.21.0. It is, therefore, affected by a credential disclosure vulnerability:

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

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

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.

ID	名前	製品	ファミリー	公開日	更新日	深刻度
348592	RHEL 10 : curl (RHSA-2026:69125)	Nessus	Red Hat Local Security Checks	2026/9/21	2026/9/21	critical
323001	libcurl 8.8.0 < 8.21.0 Stale Proxy Password Leak	Nessus	Misc.	2026/6/26	2026/7/8	critical
345801	Amazon Linux 2023 : curl, curl-minimal, libcurl (ALAS2023-2026-2132)	Nessus	Amazon Linux Local Security Checks	2026/9/14	2026/9/14	critical

検出

プラグインの検索

critical

critical

critical