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.

vendor_unpatched cve-2024-51744: Unpatched CVEs for Debian Linux (cve-2024-51744)

The version of application-gateway-kubernetes-ingress / azcopy / cert-manager / cf-cli / coredns / etcd 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 version of application-gateway-kubernetes-ingress / azcopy / cert-manager / cf-cli / coredns / etcd installed on the remote CBL Mariner 2.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 version of docker installed on the remote host is prior to 25.0.8-1. It is, therefore, affected by a vulnerability as referenced in the ALAS2ECS-2025-048 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)

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

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

The version of docker installed on the remote host is prior to 25.0.8-1. It is, therefore, affected by a vulnerability as referenced in the ALAS2NITRO-ENCLAVES-2025-050 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)

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

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

The version of docker installed on the remote host is prior to 25.0.8-1. It is, therefore, affected by a vulnerability as referenced in the ALAS2DOCKER-2025-051 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)

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

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 a vulnerability as referenced in the ALAS2023-2025-852 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)

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

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

The remote SUSE Linux SLES15 / openSUSE 15 host has packages installed that are affected by a vulnerability as referenced in the SUSE-SU-2025:0546-1 advisory.

    golang-github-prometheus-prometheus was updated from version 2.45.6 to 2.53.3 (jsc#PED-11649):

    - Security issues fixed:
      * CVE-2024-51744: Updated golang-jwt to version 5.0 to fix bad error         handling (bsc#1232970)

    - Highlights of other changes:
      * Performance:
        - Significant enhancements to PromQL execution speed, TSDB operations (especially querying and     compaction) and           remote write operations.
        - Default GOGC value lowered to 75 for better memory management.
        - Option to limit memory usage from dropped targets added.
      * New Features:
        - Experimental OpenTelemetry ingestion.
        - Automatic memory limit handling.
        - Native histogram support, including new functions, UI enhancements, and improved scraping.
        - Improved alerting features, such as relabeling rules for AlertmanagerConfig and a new query_offset     option.
        - Expanded service discovery options with added metadata and support for new services.
        - New promtool commands for PromQL formatting, label manipulation, metric pushing, and OpenMetrics     dumping.
      * Bug Fixes:
        - Numerous fixes across scraping, API, TSDB, PromQL, and service discovery.
      * For a detailed list of changes consult the package changelog or         https://github.com/prometheus/prometheus/compare/v2.45.6...v2.53.3

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

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

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 / openSUSE 15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:0525-1 advisory.

    dracut-saltboot was updated to version 0.1.1728559936.c16d4fb:

    - Added MAC based terminal naming option (jsc#SUMA-314)

    golang-github-prometheus-prometheus was updated from version 2.45.6 to 2.53.3 (jsc#PED-11649):

    - Security issues fixed:
      * CVE-2024-51744: Updated golang-jwt to version 5.0 to fix bad error         handling (bsc#1232970)

    - Highlights of other changes:
      * Performance:
        - Significant enhancements to PromQL execution speed, TSDB operations (especially querying and     compaction) and           remote write operations.
        - Default GOGC value lowered to 75 for better memory management.
        - Option to limit memory usage from dropped targets added.
      * New Features:
        - Experimental OpenTelemetry ingestion.
        - Automatic memory limit handling.
        - Native histogram support, including new functions, UI enhancements, and improved scraping.
        - Improved alerting features, such as relabeling rules for AlertmanagerConfig and a new query_offset     option.
        - Expanded service discovery options with added metadata and support for new services.
        - New promtool commands for PromQL formatting, label manipulation, metric pushing, and OpenMetrics     dumping.
      * Bug Fixes:
        - Numerous fixes across scraping, API, TSDB, PromQL, and service discovery.
      * For a detailed list of changes consult the package changelog or         https://github.com/prometheus/prometheus/compare/v2.45.6...v2.53.3

    grafana was updated from version 9.5.18 to 10.4.13 (jsc#PED-11591,jsc#PED-11649):

    - Security issues fixed:
      * CVE-2024-45337: Prevent possible misuse of ServerConfig.PublicKeyCallback by upgrading         golang.org/x/crypto (bsc#1234554)
      * CVE-2023-3128: Fixed authentication bypass using Azure AD OAuth (bsc#1212641)
      * CVE-2023-6152: Add email verification when updating user email (bsc#1219912)
      * CVE-2024-6837: Fixed potential data source permission escalation (bsc#1236301)
      * CVE-2024-8118: Fixed permission on external alerting rule write endpoint (bsc#1231024)

    - Potential breaking changes in version 10:
      * In panels using the `extract fields` transformation, where one         of the extracted names collides with one of the already         existing ields, the extracted field will be renamed.
      * For the existing backend mode users who have table         visualization might see some inconsistencies on their panels.
        We have updated the table column naming. This will         potentially affect field transformations and/or field         overrides. To resolve this either: update transformation or         field override.
      * For the existing backend mode users who have Transformations         with the `time` field, might see their transformations are         not working. Those panels that have broken transformations         will fail to render. This is because we changed the field         key. To resolve this either: Remove the affected panel and         re-create it; Select the `Time` field again; Edit the `time`         field as `Time` for transformation in `panel.json` or         `dashboard.json`
      * The following data source permission endpoints have been removed:
        `GET /datasources/:datasourceId/permissions`         `POST /api/datasources/:datasourceId/permissions`         `DELETE /datasources/:datasourceId/permissions`         `POST /datasources/:datasourceId/enable-permissions`         `POST /datasources/:datasourceId/disable-permissions`
        - Please use the following endpoints instead:
          `GET /api/access-control/datasources/:uid` for listing data            source permissions           `POST /api/access-control/datasources/:uid/users/:id`,           `POST /api/access-control/datasources/:uid/teams/:id` and           `POST /api/access-control/datasources/:uid/buildInRoles/:id`           for adding or removing data source permissions
      * If you are using Terraform Grafana provider to manage data source permissions, you will need to     upgrade your         provider.
      * For the existing backend mode users who have table visualization might see some inconsistencies on     their panels.
        We have updated the table column naming. This will potentially affect field transformations and/or     field overrides.
      * The deprecated `/playlists/{uid}/dashboards` API endpoint has been removed.
        Dashboard information can be retrieved from the `/dashboard/...` APIs.
      * The `PUT /api/folders/:uid` endpoint no more supports modifying the folder's `UID`
      * Removed all components for the old panel header design.
      * Please review https://grafana.com/docs/grafana/next/breaking-changes/breaking-changes-v10-3/         for more details
      * OAuth role mapping enforcement: This change impacts GitHub,         Gitlab, Okta, and Generic OAuth. To avoid overriding manually         set roles, enable the skip_org_role_sync option in the         Grafana configuration for your OAuth provider before         upgrading
      * Angular has been deprecated
      * Grafana legacy alerting has been deprecated
      * API keys are migrating to service accounts
      * The experimental dashboard previews feature is removed
      * Usernames are now case-insensitive by default
      * Grafana OAuth integrations do not work anymore with email lookups
      * The Alias field in the CloudWatch data source is removed
      * Athena data source plugin must be updated to version >=2.9.3
      * Redshift data source plugin must be updated to version >=1.8.3
      * DoiT International BigQuery plugin no longer supported
      * Please review https://grafana.com/docs/grafana/next/breaking-changes/breaking-changes-v10-0         for more details

    - This update brings many new features, enhancements and fixes highlighted at:
      * https://grafana.com/docs/grafana/next/whatsnew/whats-new-in-v10-4/
      * https://grafana.com/docs/grafana/next/whatsnew/whats-new-in-v10-3/
      * https://grafana.com/docs/grafana/next/whatsnew/whats-new-in-v10-2/
      * https://grafana.com/docs/grafana/next/whatsnew/whats-new-in-v10-1/
      * https://grafana.com/docs/grafana/next/whatsnew/whats-new-in-v10-0/:

    spacecmd was updated to version 5.0.11-0:

    - Updated translation strings

    supportutils-plugin-salt was updated to version 1.2.3:

    - Adjusted requirements for plugin to allow compatibility with supportutils 3.2.9 release (bsc#1235145)
    - Provide backwards-compatible scripts version

    supportutils-plugin-susemanager-client was updated to version 5.0.4-0:

    - Adjusted requirements for plugin to allow compatibility with supportutils 3.2.9 release (bsc#1235145)

    uyuni-tools was updated from version 0.1.23-0 to 0.1.27-0:

    - Security issues fixed:
      * CVE-2024-22037: Use podman secret to store the database credentials (bsc#1231497)

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.

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.

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-816 advisory.

    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.

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-048 advisory.

    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.

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.

ID	Name	Product	Family	Severity
233497	Azure Linux 3.0 Security Update: application-gateway-kubernetes-ingress / azcopy / cert-manager / cf-cli / coredns / etcd (CVE-2024-51744)	Nessus	Azure Linux Local Security Checks	low
233496	CBL Mariner 2.0 Security Update: application-gateway-kubernetes-ingress / azcopy / cert-manager / cf-cli / coredns / etcd (CVE-2024-51744)	Nessus	MarinerOS Local Security Checks	low
232229	Amazon Linux 2 : docker (ALASECS-2025-048)	Nessus	Amazon Linux Local Security Checks	low
216813	Amazon Linux 2 : docker (ALASNITRO-ENCLAVES-2025-050)	Nessus	Amazon Linux Local Security Checks	low
216812	Amazon Linux 2 : docker (ALASDOCKER-2025-051)	Nessus	Amazon Linux Local Security Checks	low
216787	Amazon Linux 2023 : docker (ALAS2023-2025-852)	Nessus	Amazon Linux Local Security Checks	low
216393	SUSE SLES15 / openSUSE 15 : Security update golang-github-prometheus-prometheus (SUSE-SU-2025:0546-1)	Nessus	SuSE Local Security Checks	low
216389	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : SUSE Manager Client Tools (SUSE-SU-2025:0525-1)	Nessus	SuSE Local Security Checks	medium
215029	Amazon Linux 2023 : runfinch-finch (ALAS2023-2025-834)	Nessus	Amazon Linux Local Security Checks	critical
214926	Amazon Linux 2 : runfinch-finch (ALASDOCKER-2025-050)	Nessus	Amazon Linux Local Security Checks	critical
214620	Amazon Linux 2023 : runfinch-finch (ALAS2023-2025-816)	Nessus	Amazon Linux Local Security Checks	low
214619	Amazon Linux 2 : runfinch-finch (ALASDOCKER-2025-048)	Nessus	Amazon Linux Local Security Checks	low
212587	SUSE SLES15 / openSUSE 15 Security Update : govulncheck-vulndb (SUSE-SU-2024:4042-1)	Nessus	SuSE Local Security Checks	high

Detections

Analytics

CVE-2024-51744

low

Tenable Plugins

Coming Soon

low

low

low

low

low

low

low

medium

critical

critical

low

low

high