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.

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 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:01985-1 advisory.

    release-notes-susemanager:

    - Update to SUSE Manager 4.3.15.2
      * SUSE Manager 4.3 will transition to LTS after June 2025
      * CVE Fixed         CVE-2023-45288, CVE-2024-11741, CVE-2024-45337, CVE-2024-45339         CVE-2024-51744, CVE-2024-9264, CVE-2024-9476, CVE-2025-22870         CVE-2025-22872, CVE-2025-2703 CVE-2025-27144, CVE-2025-3454         CVE-2025-3580, CVE-2025-4123, CVE-2024-47535

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 remote openSUSE 15 host has packages installed that are affected by a vulnerability as referenced in the openSUSE- SU-2025:0131-1 advisory.

    - Update to version 1.12.1:
      * core: Increase CNAME lookup limit from 7 to 10 (#7153)
      * plugin/kubernetes: Fix handling of pods having DeletionTimestamp set
      * plugin/kubernetes: Revert 'only create PTR records for endpoints with         hostname defined'
      * plugin/forward: added option failfast_all_unhealthy_upstreams to return         servfail if all upstreams are down
      * bump dependencies, fixing boo#1239294 and boo#1239728

    - Update to version 1.12.0:
      * New multisocket plugin - allows CoreDNS to listen on multiple sockets
      * bump deps

    - Update to version 1.11.4:
      * forward plugin: new option next, to try alternate upstreams when receiving         specified response codes upstreams on (functions like the external plugin         alternate)
      * dnssec plugin: new option to load keys from AWS Secrets Manager
      * rewrite plugin: new option to revert EDNS0 option rewrites in responses

    - Update to version 1.11.3+git129.387f34d:
      * fix CVE-2024-51744 (bsc#1232991)         build(deps): bump github.com/golang-jwt/jwt/v4 from 4.5.0 to 4.5.1 (#6955)
      * core: set cache-control max-age as integer, not float (#6764)
      * Issue-6671: Fixed the order of plugins. (#6729)
      * `root`: explicit mark `dnssec` support (#6753)
      * feat: dnssec load keys from AWS Secrets Manager (#6618)
      * fuzzing: fix broken oss-fuzz build (#6880)
      * Replace k8s.io/utils/strings/slices by Go stdlib slices (#6863)
      * Update .go-version to 1.23.2 (#6920)
      * plugin/rewrite: Add 'revert' parameter for EDNS0 options (#6893)
      * Added OpenSSF Scorecard Badge (#6738)
      * fix(cwd): Restored backwards compatibility of Current Workdir (#6731)
      * fix: plugin/auto: call OnShutdown() for each zone at its own OnShutdown() (#6705)
      * feature: log queue and buffer memory size configuration (#6591)
      * plugin/bind: add zone for link-local IPv6 instead of skipping (#6547)
      * only create PTR records for endpoints with hostname defined (#6898)
      * fix: reverter should execute the reversion in reversed order (#6872)
      * plugin/etcd: fix etcd connection leakage when reload (#6646)
      * kubernetes: Add useragent (#6484)
      * Update build (#6836)
      * Update grpc library use (#6826)
      * Bump go version from 1.21.11 to 1.21.12 (#6800)
      * Upgrade antonmedv/expr to expr-lang/expr (#6814)
      * hosts: add hostsfile as label for coredns_hosts_entries (#6801)
      * fix TestCorefile1 panic for nil handling (#6802)

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 a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:1333-1 advisory.

    - CVE-2024-6104: cosign: hashicorp/go-retryablehttp: Fixed sensitive information disclosure to log file     (bsc#1227031)
    - CVE-2024-51744: cosign: github.com/golang-jwt/jwt/v4: Fixed bad documentation of error handling in     ParseWithClaims leading to potentially dangerous situations (bsc#1232985)
    - CVE-2025-27144: cosign: github.com/go-jose/go-jose/v4,github.com/go-jose/go-jose/v3: Fixed denial of     service in Go JOSE's Parsing (bsc#1237682)
    - CVE-2025-22870: cosign: golang.org/x/net/proxy: Fixed proxy bypass using IPv6 zone IDs (bsc#1238693)
    - CVE-2025-22868: cosign: golang.org/x/oauth2/jws: Fixed unexpected memory consumption during token     parsing (bsc#1239204)
    - CVE-2025-22869: cosign: golang.org/x/crypto/ssh: Fixed denial of service in the Key Exchange     (bsc#1239337)

    Other fixes:

    - Update to version 2.5.0 (jsc#SLE-23476):
      * Update sigstore-go to pick up bug fixes (#4150)
      * Update golangci-lint to v2, update golangci-lint-action (#4143)
      * Feat/non filename completions (#4115)
      * update builder to use go1.24.1 (#4116)
      * Add support for new bundle specification for attesting/verifying OCI image attestations (#3889)
      * Remove cert log line (#4113)
      * cmd/cosign/cli: fix typo in ignoreTLogMessage (#4111)
      * bump to latest scaffolding release for testing (#4099)
      * increase 2e2_test docker compose tiemout to 180s (#4091)
      * Fix replace with compliant image mediatype (#4077)
      * Add TSA certificate related flags and fields for cosign attest (#4079)

    - Update to version 2.4.3 (jsc#SLE-23476):
      * Enable fetching signatures without remote get. (#4047)
      * Bump sigstore/sigstore to support KMS plugins (#4073)
      * sort properly Go imports (#4071)
      * sync comment with parameter name in function signature (#4063)
      * fix go imports order to be alphabetical (#4062)
      * fix comment typo and imports order (#4061)
      * Feat/file flag completion improvements (#4028)
      * Udpate builder to use go1.23.6 (#4052)
      * Refactor verifyNewBundle into library function (#4013)
      * fix parsing error in --only for cosign copy (#4049)
      * Fix codeowners syntax, add dep-maintainers (#4046)

    - Update to version 2.4.2 (jsc#SLE-23476):
      - Updated open-policy-agent to 1.1.0 library (#4036)
         -  Note that only Rego v0 policies are supported at this time
      - Add UseSignedTimestamps to CheckOpts, refactor TSA options (#4006)
      - Add support for verifying root checksum in cosign initialize (#3953)
      - Detect if user supplied a valid protobuf bundle (#3931)
      - Add a log message if user doesn't provide --trusted-root (#3933)
      - Support mTLS towards container registry (#3922)
      - Add bundle create helper command (#3901)
      - Add trusted-root create helper command (#3876)       Bug Fixes:
      - fix: set tls config while retaining other fields from default http transport (#4007)
      - policy fuzzer: ignore known panics (#3993)
      - Fix for multiple WithRemote options (#3982)
      - Add nightly conformance test workflow (#3979)
      - Fix copy --only for signatures + update/align docs (#3904)

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 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 version of application-gateway-kubernetes-ingress / azcopy / cert-manager / cf-cli / coredns 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
246302	Linux Distros Unpatched Vulnerability : CVE-2024-51744	Nessus	Misc.	low
240808	SUSE SLES15 : Security update 4.3.15 for Multi-Linux Manager Server (SUSE-SU-2025:01985-1)	Nessus	SuSE Local Security Checks	critical
234644	openSUSE 15 Security Update : coredns (openSUSE-SU-2025:0131-1)	Nessus	SuSE Local Security Checks	low
234602	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : cosign (SUSE-SU-2025:1333-1)	Nessus	SuSE Local Security Checks	high
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	low
233496	CBL Mariner 2.0 Security Update: application-gateway-kubernetes-ingress / azcopy / cert-manager / cf-cli / coredns (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

low

critical

low

high

low

low

low

low

low

low

low

medium

critical

critical

low

low

high