The version of application-gateway-kubernetes-ingress / azcopy / cert-manager / cf-cli / coredns installed on the remote Azure Linux 3.0 host is prior to tested version. It is, therefore, affected by a vulnerability as referenced in the CVE-2024-51744 advisory.

  - golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in     `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they     should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims`     return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will     ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has     been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the     `ParseWithClaims` function will immediately return in dangerous situations (e.g., an invalid signature),     limiting the combined errors only to situations where the signature is valid, but further validation     failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of     the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100     % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0,     please make sure that you are properly checking for all errors (dangerous ones first), so that you are     not running in the case detailed above. (CVE-2024-51744)

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.

  - golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in     `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they     should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims`     return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will     ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has     been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the     `ParseWithClaims` function will immediately return in dangerous situations (e.g., an invalid signature),     limiting the combined errors only to situations where the signature is valid, but further validation     failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of     the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100     % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0,     please make sure that you are properly checking for all errors (dangerous ones first), so that you are     not running in the case detailed above. (CVE-2024-51744)

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

The remote SUSE Linux SLES15 / openSUSE 15 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2024:4042-1 advisory.

    - Update to version 0.0.20241112T145010 2024-11-12T14:50:10Z.
      Refs jsc#PED-11136       Go CVE Numbering Authority IDs added or updated with aliases:
      * GO-2024-3250 CVE-2024-51744 GHSA-29wx-vh33-7x7r

    - Update to version 0.0.20241108T172500 2024-11-08T17:25:00Z.
      Refs jsc#PED-11136       Go CVE Numbering Authority IDs added or updated with aliases:
      * GO-2024-3260 CVE-2024-45794 GHSA-q78v-cv36-8fxj
      * GO-2024-3262 CVE-2024-10975 GHSA-2w5v-x29g-jw7j

    - Update to version 0.0.20241106T172143 2024-11-06T17:21:43Z.
      Refs jsc#PED-11136       Go CVE Numbering Authority IDs added or updated with aliases:
      * GO-2024-3251 CVE-2024-10389 GHSA-q3rp-vvm7-j8jg
      * GO-2024-3252 CVE-2024-51746 GHSA-8pmp-678w-c8xx
      * GO-2024-3253 CVE-2024-48057 GHSA-ghx4-cgxw-7h9p
      * GO-2024-3254 CVE-2024-51735 GHSA-wvv7-wm5v-w2gv

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-2025:0333 advisory.

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

    CVE-2025-30204:
    golang-jwt is a Go implementation of JSON Web Tokens. Prior to     5.2.2 and 4.5.2, the function parse.ParseUnverified splits (via a call to strings.Split) its argument     (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization     header consists of Bearer  followed by many period characters, a call to that function incurs allocations     to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant     factor of about 16. This issue is fixed in 5.2.2 and 4.5.2.

    CVE-2025-30153:
    kin-openapi is a Go project for handling OpenAPI files. Prior to 0.131.0, when validating a request with a     multipart/form-data schema, if the OpenAPI schema allows it, an attacker can upload a crafted ZIP file     (e.g., a ZIP bomb), causing the server to consume all available system memory. The root cause comes from     the ZipFileBodyDecoder, which is registered automatically by the module (contrary to what the     documentation says). This vulnerability is fixed in 0.131.0.

    CVE-2025-22868:
    An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during     parsing.

    CVE-2024-6104:
    go-retryablehttp prior to 0.7.7 did not sanitize urls when writing them to its log file. This could lead     to go-retryablehttp writing sensitive HTTP basic auth credentials to its log file. This vulnerability,     CVE-2024-6104, was fixed in go-retryablehttp 0.7.7.

    CVE-2024-51744:
    golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in     `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they     should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims`     return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will     ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has     been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the     `ParseWithClaims` function will immediately return in dangerous situations (e.g., an invalid signature),     limiting the combined errors only to situations where the signature is valid, but further validation     failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of     the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100     % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0,     please make sure that you are properly checking for all errors (dangerous ones first), so that you are     not running in the case detailed above.

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.

The version of runfinch-finch installed on the remote host is prior to 1.6.0-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2DOCKER-2025-050 advisory.

    2025-02-12: CVE-2024-51744 was added to this advisory.

    2025-02-12: CVE-2024-45338 was added to this advisory.

    Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to     an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that A call to this     function does not guarantee that the key offered is in fact used to authenticate. Specifically, the SSH     protocol allows clients to inquire about whether a public key is acceptable before proving control of the     corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the     keys were provided cannot be used to infer which key the client successfully authenticated with, if any.
    Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make     security relevant determinations based on it once the connection is established, may make incorrect     assumptions. For example, an attacker may send public keys A and B, and then authenticate with A.
    PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may     then make authorization decisions based on key B for which the attacker does not actually control the     private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0     enforces the property that, when successfully authenticating via public key, the last key passed to     ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will     now be called multiple times with the same key, if necessary. Note that the client may still not control     the last key passed to PublicKeyCallback if the connection is then authenticated with a different method,     such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the     Extensions field of the Permissions return value from the various authentication callbacks to record data     associated with the authentication attempt instead of referencing external state. Once the connection is     established the state corresponding to the successful authentication attempt can be retrieved via the     ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing     it across authentication attempts; users of third-party libraries should refer to the relevant projects     for guidance. (CVE-2024-45337)

    An attacker can craft an input to the Parse functions that would be processed non-linearly with respect to     its length, resulting in extremely slow parsing. This could cause a denial of service. (CVE-2024-45338)

    golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in     `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they     should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims`     return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will     ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has     been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the     `ParseWithClaims` function will immediately return in dangerous situations (e.g., an invalid signature),     limiting the combined errors only to situations where the signature is valid, but further validation     failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of     the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100     % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0,     please make sure that you are properly checking for all errors (dangerous ones first), so that you are     not running in the case detailed above. (CVE-2024-51744)

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.

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

    2025-02-11: CVE-2024-45338 was added to this advisory.

    2025-02-11: CVE-2024-51744 was added to this advisory.

    Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to     an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that A call to this     function does not guarantee that the key offered is in fact used to authenticate. Specifically, the SSH     protocol allows clients to inquire about whether a public key is acceptable before proving control of the     corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the     keys were provided cannot be used to infer which key the client successfully authenticated with, if any.
    Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make     security relevant determinations based on it once the connection is established, may make incorrect     assumptions. For example, an attacker may send public keys A and B, and then authenticate with A.
    PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may     then make authorization decisions based on key B for which the attacker does not actually control the     private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0     enforces the property that, when successfully authenticating via public key, the last key passed to     ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will     now be called multiple times with the same key, if necessary. Note that the client may still not control     the last key passed to PublicKeyCallback if the connection is then authenticated with a different method,     such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the     Extensions field of the Permissions return value from the various authentication callbacks to record data     associated with the authentication attempt instead of referencing external state. Once the connection is     established the state corresponding to the successful authentication attempt can be retrieved via the     ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing     it across authentication attempts; users of third-party libraries should refer to the relevant projects     for guidance. (CVE-2024-45337)

    An attacker can craft an input to the Parse functions that would be processed non-linearly with respect to     its length, resulting in extremely slow parsing. This could cause a denial of service. (CVE-2024-45338)

    golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in     `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they     should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims`     return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will     ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has     been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the     `ParseWithClaims` function will immediately return in dangerous situations (e.g., an invalid signature),     limiting the combined errors only to situations where the signature is valid, but further validation     failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of     the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100     % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0,     please make sure that you are properly checking for all errors (dangerous ones first), so that you are     not running in the case detailed above. (CVE-2024-51744)

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	名称	产品	系列	发布时间	最近更新时间	严重程度
233497	Azure Linux 3.0 Security Update: application-gateway-kubernetes-ingress / azcopy / cert-manager / cf-cli / coredns (CVE-2024-51744)	Nessus	Azure Linux Local Security Checks	2025/3/29	2025/9/15	low
246302	Linux Distros Unpatched Vulnerability : CVE-2024-51744	Nessus	Misc.	2025/8/8	2025/10/14	low
212587	SUSE SLES15 / openSUSE 15 Security Update : govulncheck-vulndb (SUSE-SU-2024:4042-1)	Nessus	SuSE Local Security Checks	2024/12/12	2025/9/5	high
239114	TencentOS Server 4: osbuild-composer (TSSA-2025:0333)	Nessus	Tencent Local Security Checks	2025/6/16	2025/12/4	high
214926	Amazon Linux 2 : runfinch-finch (ALASDOCKER-2025-050)	Nessus	Amazon Linux Local Security Checks	2025/2/4	2025/2/14	critical
215029	Amazon Linux 2023 : runfinch-finch (ALAS2023-2025-834)	Nessus	Amazon Linux Local Security Checks	2025/2/5	2025/2/14	critical

检测

插件搜索

low

low

high

high

critical

critical