The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the CIQ ciqsa-2026_1401 advisory.

    This advisory aggregates security fixes for the curl SRPM in CIQ LTS 9.6. It addresses 148 CVEs:
    CVE-2023-32001, CVE-2022-27775, CVE-2018-1000005, CVE-2022-27774, CVE-2022-32221, and 143 more.

Tenable has extracted the preceding description block directly from the CIQ 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 remote SUSE Linux SLES12 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:0066-1 advisory.

    - CVE-2025-14524: Fixed bearer token leak on cross-protocol redirect (bsc#1255731)
      - CVE-2025-15079: Fixed unknown host connection acceptance when set in the global knownhostsfile     (bsc#1255733)
      - CVE-2025-14819: Fixed issue where alteration of CURLSSLOPT_NO_PARTIALCHAIN could       accidentally lead to CA cache reuse for which partial chain was reversed (bsc#1255732)

Tenable has extracted the preceding description block directly from the SUSE 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 Tencent Linux installed on the remote TencentOS Server 4 host is prior to tested version. It is, therefore, affected by multiple vulnerabilities as referenced in the TSSA-2026:0101 advisory.

    Package updates are available for TencentOS Server 4 that fix the following vulnerabilities:

    CVE-2025-15224:
    When doing SSH-based transfers using either SCP or SFTP, and asked to do     public key authentication, curl would wrongly still ask and authenticate using     a locally running SSH agent.

    CVE-2025-15079:
    When doing SSH-based transfers using either SCP or SFTP, and setting the     known_hosts file, libcurl could still mistakenly accept connecting to hosts
    *not present* in the specified file if they were added as recognized in the     libssh *global* known_hosts file.

    CVE-2025-14819:
    When doing TLS related transfers with reused easy or multi handles and     altering the  `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally     reuse a CA store cached in memory for which the partial chain option was     reversed. Contrary to the user's wishes and expectations. This could make     libcurl find and accept a trust chain that it otherwise would not.

    CVE-2025-14524:
    When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer     performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP,     POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new     target host.

    CVE-2025-14017:
    When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,     changing TLS options in one thread would inadvertently change them globally     and therefore possibly also affect other concurrently setup transfers.

    Disabling certificate verification for a specific transfer could     unintentionally disable the feature for other threads as well.

Tenable has extracted the preceding description block directly from the Tencent 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.

According to the versions of the curl packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

    When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,     changing TLS options in one thread would inadvertently change them globally     and therefore possibly also affect other concurrently setup transfers.

    Disabling certificate verification for a specific transfer could     unintentionally disable the feature for other threads as well.(CVE-2025-14017)

    When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer     performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP,     POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new     target host.(CVE-2025-14524)

    When doing SSH-based transfers using either SCP or SFTP, and asked to do     public key authentication, curl would wrongly still ask and authenticate using     a locally running SSH agent.(CVE-2025-15224)

    When doing SSH-based transfers using either SCP or SFTP, and setting the     known_hosts file, libcurl could still mistakenly accept connecting to hosts
    *not present* in the specified file if they were added as recognized in the     libssh *global* known_hosts file.(CVE-2025-15079)

Tenable has extracted the preceding description block directly from the EulerOS curl 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 Rocky Linux 9.6 host has packages installed that are affected by a vulnerability as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1771501913 advisory.

  - When doing SSH-based transfers using either SCP or SFTP, and setting the known_hosts file, libcurl could     still mistakenly accept connecting to hosts *not present* in the specified file if they were added as     recognized in the libssh *global* known_hosts file. (CVE-2025-15079)

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

According to the versions of the curl packages installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

    When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling,     to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead     wrongly consider the response as fine.  If the returned status reports another error than 'revoked' (like     for example 'unauthorized') it is not treated as a bad certficate.(CVE-2024-8096)

    When curl is asked to use HSTS, the expiry time for a subdomain might overwrite a parent domain's cache     entry, making it end sooner or later than otherwise intended. This affects curl using applications that     enable HSTS and use URLs with the insecure `HTTP://` scheme and perform transfers with hosts like     `x.example.com` as well as `example.com` where the first host is a subdomain of the second host. (The HSTS     cache either needs to have been populated manually or there needs to have been previous HTTPS accesses     done as the cache needs to have entries for the domains involved to trigger this problem.) When     `x.example.com` responds with `Strict-Transport-Security:` headers, this bug can make the subdomain's     expiry timeout *bleed over* and get set for the parent domain `example.com` in curl's HSTS cache. The     result of a triggered bug is that HTTP accesses to `example.com` get converted to HTTPS for a different     period of time than what was asked for by the origin server. If `example.com` for example stops supporting     HTTPS at its expiry time, curl might then fail to access `http://example.com` until the (wrongly set)     timeout expires. This bug can also expire the parent's entry *earlier*, thus making curl inadvertently     switch back to insecure HTTP earlier than otherwise intended.(CVE-2024-9681)

    When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the     password used for the first host to the followed-to host under certain circumstances.This flaw only     manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry     either omits just the password or omits both login and password.(CVE-2024-11053)

    When libcurl is asked to perform automatic gzip decompression of content-encoded HTTP responses with the     `CURLOPT_ACCEPT_ENCODING` option,**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow     would make libcurl perform a buffer overflow.(CVE-2025-0725)

    When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the     password used for the first host to the followed-to host under certain circumstances.This flaw only     manifests itself if the netrc file has a `default` entry that omits both login and password. A rare     circumstance.(CVE-2025-0167)

    1. A cookie is set using the `secure` keyword for `https://target` 2. curl is redirected to or otherwise     made to speak with `http://target` (same hostname, but using clear text HTTP) using the same cookie set 3.
    The same cookie name is set - but with just a slash as path (`path='/'`).Since this site is not secure,     the cookie *should* just be ignored.4. A bug in the path comparison logic makes curl read outside a heap     buffer boundary The bug either causes a crash or it potentially makes the comparison come to the wrong     conclusion and lets the clear-text site override the contents of the secure cookie, contrary to     expectations and depending on the memory contents immediately following the single-byte allocation that     holds the path.The presumed and correct behavior would be to plainly ignore the second set of the cookie     since it was already set as secure on a secure host so overriding it on an insecure host should not be     okay.(CVE-2025-9086)

    curl's code for managing SSH connections when SFTP was done using the wolfSSH powered backend was flawed     and missed host verification mechanisms.This prevents curl from detecting MITM attackers and     more.(CVE-2025-10966)

    When doing SSH-based transfers using either SCP or SFTP, and setting the known_hosts file, libcurl could     still mistakenly accept connecting to hosts *not present* in the specified file if they were added as     recognized in the libssh *global* known_hosts file.(CVE-2025-15079)

    When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread     would inadvertently change them globally and therefore possibly also affect other concurrently setup     transfers.Disabling certificate verification for a specific transfer could unintentionally disable the     feature for other threads as well.(CVE-2025-14017)

    When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol     redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the     bearer token to the new target host.(CVE-2025-14524)

    When doing SSH-based transfers using either SCP or SFTP, and asked to do public key authentication, curl     would wrongly still ask and authenticate using a locally running SSH agent.(CVE-2025-15224)

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

    curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new     request uses different credentials for the HTTP proxy.The proper behavior is to create or use a separate     connection.(CVE-2026-3784)

    libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated     HTTP or HTTPS request.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 just     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).(CVE-2026-1965)

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

    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`.(CVE-2026-7168)

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

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

    curl might erroneously pass on credentials for a first proxy to a second proxy.This can happen when the     following conditions are true:1. curl is setup to use specific different proxies for different URL schemes     2. the first proxy needs credentials 3. the second proxy uses no credentials 4. 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(CVE-2026-6253)

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

    A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted     connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or     POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data     unencrypted.(CVE-2026-4873)

Tenable has extracted the preceding description block directly from the EulerOS Virtualization curl 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 CentOS Linux 8.5 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.5:CLSA-2026:1773135327 advisory.

  - When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol     redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the     bearer token to the new target host. (CVE-2025-14524)

  - When doing SSH-based transfers using either SCP or SFTP, and setting the known_hosts file, libcurl could     still mistakenly accept connecting to hosts *not present* in the specified file if they were added as     recognized in the libssh *global* known_hosts file. (CVE-2025-15079)

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

According to the versions of the curl packages installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

    When doing TLS related transfers with reused easy or multi handles and altering the     `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally reuse a CA store cached in memory for     which the partial chain option was reversed. Contrary to the user's wishes and expectations. This could     make libcurl find and accept a trust chain that it otherwise would not.(CVE-2025-14819)

    When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread     would inadvertently change them globally and therefore possibly also affect other concurrently setup     transfers.Disabling certificate verification for a specific transfer could unintentionally disable the     feature for other threads as well.(CVE-2025-14017)

    When doing SSH-based transfers using either SCP or SFTP, and setting the known_hosts file, libcurl could     still mistakenly accept connecting to hosts *not present* in the specified file if they were added as     recognized in the libssh *global* known_hosts file.(CVE-2025-15079)

    When doing SSH-based transfers using either SCP or SFTP, and asked to do public key authentication, curl     would wrongly still ask and authenticate using a locally running SSH agent.(CVE-2025-15224)

    When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol     redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the     bearer token to the new     target host.(CVE-2025-14524)

    curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new     request uses different credentials for the HTTP proxy.The proper behavior is to create or use a separate     connection.(CVE-2026-3784)

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

    libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated     HTTP or HTTPS request.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 just 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).(CVE-2026-1965)

Tenable has extracted the preceding description block directly from the EulerOS Virtualization curl 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	名前	製品	ファミリー	公開日	更新日	深刻度
353701	Rocky Linux 9.6 [CIQ] Security Update: curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal Multiple Vulnerabilities (ciqsa-2026_1401)	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/13	critical
282494	SUSE SLES12 Security Update : curl (SUSE-SU-2026:0066-1)	Nessus	SuSE Local Security Checks	2026/1/9	2026/4/30	medium
300436	TencentOS Server 4: curl (TSSA-2026:0101)	Nessus	Tencent Local Security Checks	2026/3/3	2026/4/30	medium
302387	EulerOS 2.0 SP12 : curl (EulerOS-SA-2026-1355)	Nessus	Huawei Local Security Checks	2026/3/16	2026/3/16	medium
360249	Rocky Linux 9.6 [TuxCare] Security Update: curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal (ALMALINUX9.6:CLSA-2026:1771501913)	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/1	medium
347185	EulerOS Virtualization 2.11.1 : curl (EulerOS-SA-2026-3408)	Nessus	Huawei Local Security Checks	2026/9/18	2026/9/18	high
348099	EulerOS Virtualization 2.11.0 : curl (EulerOS-SA-2026-3495)	Nessus	Huawei Local Security Checks	2026/9/18	2026/9/18	high
351763	CentOS Linux 8.5 [TuxCare] Security Update: curl / curl-minimal / libcurl / libcurl-devel / libcurl-minimal Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1773135327)	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	medium
377387	EulerOS Virtualization 2.15.1 : curl (EulerOS-SA-2026-4547)	Nessus	Huawei Local Security Checks	2026/11/7	2026/11/7	medium

検出

プラグインの検索

critical

medium

medium

medium

medium

high

high

medium

medium