Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) 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.

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

    Update to version 3.17.1:

    - CVE-2024-45338: Fixed denial of service due to non-linear parsing of case-insensitive content     (bsc#1235318).
    - CVE-2024-45337: Fixed misuse of ServerConfig.PublicKeyCallback to prevent authorization bypass in     golang.org/x/crypto (bsc#1234482).

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 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:0601-1 advisory.

    - CVE-2025-21613: Fixed argument injection via the URL field (bsc#1235573).
    - CVE-2024-45337: Fixed authorization bypass in golang.org/x/crypto via the ServerConfig.PublicKeyCallback     callback       (bsc#1234597).

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

    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/

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

The version of cert-manager / cf-cli / docker-buildx / docker-compose / moby-compose / moby-engine / packer 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-45337 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)

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

The remote openSUSE 15 host has a package installed that is affected by multiple vulnerabilities as referenced in the openSUSE-SU-2025:0056-1 advisory.

    Update to version 0.58.2 (

          boo#1234512, CVE-2024-45337,           boo#1235265, CVE-2024-45338):

      * fix(misconf): allow null values only for tf variables [backport: release/v0.58] (#8238)
      * fix(suse): SUSE - update OSType constants and references for compatility [backport: release/v0.58]     (#8237)
      * fix: CVE-2025-21613 and CVE-2025-21614 : go-git: argument injection via the URL field [backport:
    release/v0.58] (#8215)
      * fix(sbom): attach nested packages to Application [backport: release/v0.58] (#8168)
      * fix(python): skip dev group's deps for poetry [backport: release/v0.58] (#8158)
      * fix(sbom): use root package for `unknown` dependencies (if exists) [backport: release/v0.58] (#8156)
      * chore(deps): bump `golang.org/x/net` from `v0.32.0` to `v0.33.0` [backport: release/v0.58] (#8142)
      * chore(deps): bump `github.com/CycloneDX/cyclonedx-go` from `v0.9.1` to `v0.9.2` [backport:
    release/v0.58] (#8136)
      * fix(redhat): correct rewriting of recommendations for the same vulnerability [backport: release/v0.58]     (#8135)
      * fix(oracle): add architectures support for advisories [backport: release/v0.58] (#8125)
      * fix(sbom): fix wrong overwriting of applications obtained from different sbom files but having same     app type [backport: release/v0.58] (#8124)
      * chore(deps): bump golang.org/x/crypto from 0.30.0 to 0.31.0 [backport: release/v0.58] (#8122)
      * fix: handle `BLOW_UNKNOWN` error to download DBs [backport: release/v0.58] (#8121)
      * fix(java): correctly overwrite version from depManagement if dependency uses `project.*` props     [backport: release/v0.58] (#8119)
      * release: v0.58.0 [main] (#7874)
      * fix(misconf): wrap AWS EnvVar to iac types (#7407)
      * chore(deps): Upgrade trivy-checks (#8018)
      * refactor(misconf): Remove unused options (#7896)
      * docs: add terminology page to explain Trivy concepts (#7996)
      * feat: add `workspaceRelationship` (#7889)
      * refactor(sbom): simplify relationship generation (#7985)
      * docs: improve databases documentation (#7732)
      * refactor: remove support for custom Terraform checks (#7901)
      * docs: drop AWS account scanning (#7997)
      * fix(aws): change CPU and Memory type of ContainerDefinition to a string (#7995)
      * fix(cli): Handle empty ignore files more gracefully (#7962)
      * fix(misconf): load full Terraform module (#7925)
      * fix(misconf): properly resolve local Terraform cache (#7983)
      * refactor(k8s): add v prefix for Go packages (#7839)
      * test: replace Go checks with Rego (#7867)
      * feat(misconf): log causes of HCL file parsing errors (#7634)
      * chore(deps): bump the aws group across 1 directory with 7 updates (#7991)
      * chore(deps): bump github.com/moby/buildkit from 0.17.0 to 0.17.2 in the docker group across 1     directory (#7990)
      * chore(deps): update csaf module dependency from csaf-poc to gocsaf (#7992)
      * chore: downgrade the failed block expand message to debug (#7964)
      * fix(misconf): do not erase variable type for child modules (#7941)
      * feat(go): construct dependencies of `go.mod` main module in the parser (#7977)
      * feat(go): construct dependencies in the parser (#7973)
      * feat: add cvss v4 score and vector in scan response (#7968)
      * docs: add `overview` page for `others` (#7972)
      * fix(sbom): Fixes for Programming Language Vulnerabilities and SBOM Package Maintainer Details (#7871)
      * feat(suse): Align SUSE/OpenSUSE OS Identifiers (#7965)
      * chore(deps): bump the common group with 4 updates (#7949)
      * feat(oracle): add `flavors` support (#7858)
      * fix(misconf): Update trivy-checks default repo to `mirror.gcr.io` (#7953)
      * chore(deps): Bump up trivy-checks to v1.3.0 (#7959)
      * fix(k8s): check all results for vulnerabilities (#7946)
      * ci(helm): bump Trivy version to 0.57.1 for Trivy Helm Chart 0.9.0 (#7945)
      * feat(secret): Add built-in secrets rules for Private Packagist (#7826)
      * docs: Fix broken links (#7900)
      * docs: fix mistakes/typos (#7942)
      * feat: Update registry fallbacks (#7679)
      * fix(alpine): add `UID` for removed packages (#7887)
      * chore(deps): bump the aws group with 6 updates (#7902)
      * chore(deps): bump the common group with 6 updates (#7904)
      * fix(debian): infinite loop (#7928)
      * fix(redhat): don't return error if `root/buildinfo/content_manifests/` contains files that are not     `contentSets` files (#7912)
      * docs: add note about temporary podman socket (#7921)
      * docs: combine trivy.dev into trivy docs (#7884)
      * test: change branch in spdx schema link to check in integration tests (#7935)
      * docs: add Headlamp to the Trivy Ecosystem page (#7916)
      * fix(report): handle `git@github.com` schema for misconfigs in `sarif` report (#7898)
      * chore(k8s): enhance k8s scan log (#6997)
      * fix(terraform): set null value as fallback for missing variables (#7669)
      * fix(misconf): handle null properties in CloudFormation templates (#7813)
      * fix(fs): add missing defered Cleanup() call to post analyzer fs (#7882)
      * chore(deps): bump the common group across 1 directory with 20 updates (#7876)
      * chore: bump containerd to v2.0.0 (#7875)
      * fix: Improve version comparisons when build identifiers are present (#7873)
      * feat(k8s): add default commands for unknown platform (#7863)
      * chore(deps): bump github.com/golang-jwt/jwt/v4 from 4.5.0 to 4.5.1 (#7868)
      * refactor(secret): optimize performance by moving ToLower operation outside loop (#7862)
      * test: save `containerd` image into archive and use in tests (#7816)
      * chore(deps): bump the github-actions group across 1 directory with 2 updates (#7854)
      * chore: bump golangci-lint to v1.61.0 (#7853)

    - Update to version 0.57.1:
      * release: v0.57.1 [release/v0.57] (#7943)
      * feat: Update registry fallbacks [backport: release/v0.57] (#7944)
      * fix(redhat): don't return error if `root/buildinfo/content_manifests/` contains files that are not     `contentSets` files [backport: release/v0.57] (#7939)
      * test: change branch in spdx schema link to check in integration tests [backport: release/v0.57]     (#7940)
      * release: v0.57.0 [main] (#7710)
      * chore: lint `errors.Join` (#7845)
      * feat(db): append errors (#7843)
      * docs(java): add info about supported scopes (#7842)
      * docs: add example of creating whitelist of checks (#7821)
      * chore(deps): Bump trivy-checks (#7819)
      * fix(go): Do not trim v prefix from versions in Go Mod Analyzer (#7733)
      * fix(k8s): skip resources without misconfigs (#7797)
      * fix(sbom):  use `Annotation` instead of `AttributionTexts` for `SPDX` formats (#7811)
      * fix(cli): add config name to skip-policy-update alias (#7820)
      * fix(helm): properly handle multiple archived dependencies (#7782)
      * refactor(misconf): Deprecate `EXCEPTIONS` for misconfiguration scanning (#7776)
      * fix(k8s)!: support k8s multi container (#7444)
      * fix(k8s): support kubernetes v1.31 (#7810)
      * docs: add Windows install instructions (#7800)
      * ci(helm): auto public Helm chart after PR merged (#7526)
      * feat: add end of life date for Ubuntu 24.10 (#7787)
      * feat(report): update gitlab template to populate operating_system value (#7735)
      * feat(misconf): Show misconfig ID in output (#7762)
      * feat(misconf): export unresolvable field of IaC types to Rego (#7765)
      * refactor(k8s): scan config files as a folder (#7690)
      * fix(license): fix license normalization for Universal Permissive License (#7766)
      * fix: enable usestdlibvars linter (#7770)
      * fix(misconf): properly expand dynamic blocks (#7612)
      * feat(cyclonedx): add file checksums to `CycloneDX` reports (#7507)
      * fix(misconf): fix for Azure Storage Account network acls adaptation (#7602)
      * refactor(misconf): simplify k8s scanner (#7717)
      * feat(parser): ignore white space in pom.xml files (#7747)
      * test: use forked images (#7755)
      * fix(java): correctly inherit `version` and `scope` from upper/root `depManagement` and `dependencies`     into parents (#7541)
      * fix(misconf): check if property is not nil before conversion (#7578)
      * fix(misconf): change default ACL of digitalocean_spaces_bucket to private (#7577)
      * feat(misconf): ssl_mode support for GCP SQL DB instance (#7564)
      * test: define constants for test images (#7739)
      * docs: add note about disabled DS016 check (#7724)
      * feat(misconf): public network support for Azure Storage Account (#7601)
      * feat(cli): rename `trivy auth` to `trivy registry` (#7727)
      * docs: apt-transport-https is a transitional package (#7678)
      * refactor(misconf): introduce generic scanner (#7515)
      * fix(cli): `clean --all` deletes only relevant dirs (#7704)
      * feat(cli): add `trivy auth` (#7664)
      * fix(sbom): add options for DBs in private registries (#7660)
      * docs(report): fix reporting doc format (#7671)
      * fix(repo): `git clone` output to Stderr (#7561)
      * fix(redhat): include arch in PURL qualifiers (#7654)
      * fix(report): Fix invalid URI in SARIF report (#7645)
      * docs(report): Improve SARIF reporting doc (#7655)
      * fix(db): fix javadb downloading error handling (#7642)
      * feat(cli): error out when ignore file cannot be found (#7624)

    - Update to version 0.56.2:
      * release: v0.56.2 [release/v0.56] (#7694)
      * fix(redhat): include arch in PURL qualifiers [backport: release/v0.56] (#7702)
      * fix(sbom): add options for DBs in private registries [backport: release/v0.56] (#7691)

    - Update to version 0.56.1:
      * release: v0.56.1 [release/v0.56] (#7648)
      * fix(db): fix javadb downloading error handling [backport: release/v0.56] (#7646)
      * release: v0.56.0 [main] (#7447)
      * fix(misconf): not to warn about missing selectors of libraries (#7638)
      * feat: support RPM archives (#7628)
      * fix(secret): change grafana token regex to find them without unquoted (#7627)
      * fix(misconf): Disable deprecated checks by default (#7632)
      * chore: add prefixes to log messages (#7625)
      * feat(misconf): Support `--skip-*` for all included modules  (#7579)
      * feat: support multiple DB repositories for vulnerability and Java DB (#7605)
      * ci: don't use cache for `setup-go` (#7622)
      * test: use loaded image names (#7617)
      * feat(java): add empty versions if `pom.xml` dependency versions can't be detected (#7520)
      * feat(secret): enhance secret scanning for python binary files (#7223)
      * refactor: fix auth error handling (#7615)
      * ci: split `save` and `restore` cache actions (#7614)
      * fix(misconf): disable DS016 check for image history analyzer (#7540)
      * feat(suse): added SUSE Linux Enterprise Micro support (#7294)
      * feat(misconf): add ability to disable checks by ID (#7536)
      * fix(misconf): escape all special sequences (#7558)
      * test: use a local registry for remote scanning (#7607)
      * fix: allow access to '..' in mapfs (#7575)
      * fix(db): check `DownloadedAt` for `trivy-java-db` (#7592)
      * chore(deps): bump the common group across 1 directory with 20 updates (#7604)
      * ci: add `workflow_dispatch` trigger for test workflow. (#7606)
      * ci: cache test images for `integration`, `VM` and `module` tests (#7599)
      * chore(deps): remove broken replaces for opa and discovery (#7600)
      * docs(misconf): Add more info on how to use arbitrary JSON/YAML scan feat (#7458)
      * fix(misconf): Fixed scope for China Cloud (#7560)
      * perf(misconf): use port ranges instead of enumeration (#7549)
      * fix(sbom): export bom-ref when converting a package to a component (#7340)
      * refactor(misconf): pass options to Rego scanner as is (#7529)
      * fix(sbom): parse type `framework` as `library` when unmarshalling `CycloneDX` files (#7527)
      * chore(deps): bump go-ebs-file (#7513)
      * fix(misconf): Fix logging typo (#7473)
      * feat(misconf): Register checks only when needed (#7435)
      * refactor: split `.egg` and `packaging` analyzers (#7514)
      * fix(java): use `dependencyManagement` from root/child pom's for dependencies from parents (#7497)
      * chore(vex): add `CVE-2024-34155`, `CVE-2024-34156` and `CVE-2024-34158` in `trivy.openvex.json`     (#7510)
      * chore(deps): bump alpine from 3.20.0 to 3.20.3 (#7508)
      * chore(vex): suppress openssl vulnerabilities (#7500)
      * revert(java): stop supporting of `test` scope for `pom.xml` files (#7488)
      * docs(db): add a manifest example (#7485)
      * feat(license): improve license normalization (#7131)
      * docs(oci): Add a note About the expected Media Type for the Trivy-DB OCI Artifact (#7449)
      * fix(report): fix error with unmarshal of `ExperimentalModifiedFindings` (#7463)
      * fix(report): change a receiver of MarshalJSON (#7483)
      * fix(oracle): Update EOL date for Oracle 7 (#7480)
      * chore(deps): bump the aws group with 6 updates (#7468)
      * chore(deps): bump the common group across 1 directory with 19 updates (#7436)
      * chore(helm): bump up Trivy Helm chart (#7441)
      * refactor(java): add error/statusCode for logs when we can't get pom.xml/maven-metadata.xml from remote     repo (#7451)
      * fix(license): stop spliting a long license text (#7336)
      * release: v0.55.0 [main] (#7271)
      * feat(go): use `toolchain` as `stdlib` version for `go.mod` files (#7163)
      * fix(license): add license handling to JUnit template (#7409)
      * feat(java): add `test` scope support for `pom.xml` files (#7414)
      * chore(deps): Bump trivy-checks and pin OPA (#7427)
      * fix(helm): explicitly define `kind` and `apiVersion` of `volumeClaimTemplate` element (#7362)
      * feat(sbom): set User-Agent header on requests to Rekor (#7396)
      * test: add integration plugin tests (#7299)
      * fix(nodejs): check all `importers` to detect dev deps from pnpm-lock.yaml file (#7387)
      * fix: logger initialization before flags parsing (#7372)
      * fix(aws): handle ECR repositories in different regions (#6217)
      * fix(misconf): fix infer type for null value (#7424)
      * fix(secret): use `.eyJ` keyword for JWT secret (#7410)
      * fix(misconf): do not recreate filesystem map (#7416)
      * chore(deps): Bump trivy-checks (#7417)
      * fix(misconf): do not register Rego libs in checks registry (#7420)
      * fix(sbom): use `NOASSERTION` for licenses fields in SPDX formats (#7403)
      * feat(report): export modified findings in JSON (#7383)
      * feat(server): Make Trivy Server Multiplexer Exported (#7389)
      * chore: update CODEOWNERS (#7398)
      * fix(secret): use only line with secret for long secret lines (#7412)
      * chore: fix allow rule of ignoring test files to make it case insensitive (#7415)
      * feat(misconf): port and protocol support for EC2 networks (#7146)
      * fix(misconf): do not filter Terraform plan JSON by name (#7406)
      * feat(misconf): support for ignore by nested attributes (#7205)
      * fix(misconf): use module to log when metadata retrieval fails (#7405)
      * fix(report): escape `Message` field in `asff.tpl` template (#7401)
      * feat(misconf): Add support for using spec from on-disk bundle (#7179)
      * docs: add pkg flags to config file page (#7370)
      * feat(python): use minimum version for pip packages (#7348)
      * fix(misconf): support deprecating for Go checks (#7377)
      * fix(misconf): init frameworks before updating them (#7376)
      * feat(misconf): ignore duplicate checks (#7317)
      * refactor(misconf): use slog (#7295)
      * chore(deps): bump trivy-checks (#7350)
      * feat(server): add internal `--path-prefix` flag for client/server mode (#7321)
      * chore(deps): bump the aws group across 1 directory with 7 updates (#7358)
      * fix: safely check if the directory exists (#7353)
      * feat(misconf): variable support for Terraform Plan (#7228)
      * feat(misconf): scanning support for YAML and JSON (#7311)
      * fix(misconf): wrap Azure PortRange in iac types (#7357)
      * refactor(misconf): highlight only affected rows (#7310)
      * fix(misconf): change default TLS values for the Azure storage account (#7345)
      * chore(deps): bump the common group with 9 updates (#7333)
      * docs(misconf): Update callsites to use correct naming (#7335)
      * docs: update air-gapped docs (#7160)
      * refactor: replace ftypes.Gradle with packageurl.TypeGradle (#7323)
      * perf(misconf): optimize work with context (#6968)
      * docs: update links to packaging.python.org (#7318)
      * docs: update client/server docs for misconf and license scanning (#7277)
      * chore(deps): bump the common group across 1 directory with 7 updates (#7305)
      * feat(misconf): iterator argument support for dynamic blocks (#7236)
      * fix(misconf): do not set default value for default_cache_behavior (#7234)
      * feat(misconf): support for policy and bucket grants (#7284)
      * fix(misconf): load only submodule if it is specified in source (#7112)
      * perf(misconf): use json.Valid to check validity of JSON (#7308)
      * refactor(misconf): remove unused universal scanner (#7293)
      * perf(misconf): do not convert contents of a YAML file to string (#7292)
      * fix(terraform): add aws_region name to presets (#7184)
      * docs: add auto-generated config (#7261)
      * feat(vuln): Add `--detection-priority` flag for accuracy tuning (#7288)
      * refactor(misconf): remove file filtering from parsers (#7289)
      * fix(flag): incorrect behavior for deprected flag `--clear-cache` (#7281)
      * fix(java): Return error when trying to find a remote pom to avoid segfault (#7275)
      * fix(plugin): do not call GitHub content API for releases and tags (#7274)
      * feat(vm): support the Ext2/Ext3 filesystems (#6983)
      * feat(cli)!: delete deprecated SBOM flags (#7266)
      * feat(vm): Support direct filesystem (#7058)

    - Update to version 0.51.1 (boo#1227010, CVE-2024-3817):

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-833 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)

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

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 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 nerdctl installed on the remote host is prior to 2.0.3-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2-2025-2749 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)

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 containerd installed on the remote host is prior to 1.7.25-1. It is, therefore, affected by a vulnerability as referenced in the ALAS2NITRO-ENCLAVES-2025-049 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)

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

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

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 containerd installed on the remote host is prior to 1.7.25-1. It is, therefore, affected by a vulnerability as referenced in the ALAS2ECS-2025-046 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)

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

    - Update to 4.4.2:
      * Bump chroma to newest version
      * Remove plan9 support due to build failure
      * Upgrade to yaml.v3

    - Update to 4.4.1:
      * Update dependencies
      * Make minor changes to appease revive (linter)

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 Fedora 41 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2024-4f08c1a90a advisory.

    Update to 1.2.1 to fix https://github.com/FiloSottile/age/security/advisories/GHSA-32gq-x56h-299c security     issue.

Tenable has extracted the preceding description block directly from the Fedora 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 Fedora 41 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2024-0912cd3ad9 advisory.

    Update to 6.8 to get various features and fixes

Tenable has extracted the preceding description block directly from the Fedora 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 Fedora 41 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2024-8d1b3f4466 advisory.

    release v1.14.0


Tenable has extracted the preceding description block directly from the Fedora 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 Fedora 40 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2024-f2a4ffc1ff advisory.

    release v1.14.0


Tenable has extracted the preceding description block directly from the Fedora 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 cert-manager / cf-cli / docker-buildx / docker-compose / moby-compose / moby-engine / packer 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-45337 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)

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

The remote Fedora 41 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2024-c33c95804e advisory.

    Fix CVE-2024-45337

Tenable has extracted the preceding description block directly from the Fedora 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 Fedora 40 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2024-8f83d0ed92 advisory.

    Fix CVE-2024-45337

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

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

ID	Name	Product	Family	Severity
216640	SUSE SLES15 / openSUSE 15 Security Update : helm (SUSE-SU-2025:0602-1)	Nessus	SuSE Local Security Checks	critical
216633	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : brise (SUSE-SU-2025:0601-1)	Nessus	SuSE Local Security Checks	critical
216397	SUSE SLES15 / openSUSE 15 Security Update : grafana (SUSE-SU-2025:0545-1)	Nessus	SuSE Local Security Checks	medium
216389	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : SUSE Manager Client Tools (SUSE-SU-2025:0525-1)	Nessus	SuSE Local Security Checks	medium
215502	Azure Linux 3.0 Security Update: cert-manager / cf-cli / docker-buildx / docker-compose / moby-compose / moby-engine / packer (CVE-2024-45337)	Nessus	Azure Linux Local Security Checks	critical
215185	openSUSE 15 Security Update : trivy (openSUSE-SU-2025:0056-1)	Nessus	SuSE Local Security Checks	critical
215036	Amazon Linux 2023 : nerdctl (ALAS2023-2025-833)	Nessus	Amazon Linux Local Security Checks	critical
215032	Amazon Linux 2023 : containerd, containerd-stress (ALAS2023-2025-835)	Nessus	Amazon Linux Local Security Checks	critical
215029	Amazon Linux 2023 : runfinch-finch (ALAS2023-2025-834)	Nessus	Amazon Linux Local Security Checks	critical
214979	Amazon Linux 2 : nerdctl (ALAS-2025-2749)	Nessus	Amazon Linux Local Security Checks	critical
214928	Amazon Linux 2 : containerd (ALASNITRO-ENCLAVES-2025-049)	Nessus	Amazon Linux Local Security Checks	critical
214926	Amazon Linux 2 : runfinch-finch (ALASDOCKER-2025-050)	Nessus	Amazon Linux Local Security Checks	critical
214923	Amazon Linux 2 : containerd (ALASDOCKER-2025-049)	Nessus	Amazon Linux Local Security Checks	critical
214922	Amazon Linux 2 : containerd (ALASECS-2025-046)	Nessus	Amazon Linux Local Security Checks	critical
214571	openSUSE 15 Security Update : cheat (openSUSE-SU-2025:0025-1)	Nessus	SuSE Local Security Checks	critical
213401	Fedora 41 : age (2024-4f08c1a90a)	Nessus	Fedora Local Security Checks	critical
213396	Fedora 41 : incus (2024-0912cd3ad9)	Nessus	Fedora Local Security Checks	critical
213330	Fedora 41 : prometheus-podman-exporter (2024-8d1b3f4466)	Nessus	Fedora Local Security Checks	critical
213329	Fedora 40 : prometheus-podman-exporter (2024-f2a4ffc1ff)	Nessus	Fedora Local Security Checks	critical
213266	CBL Mariner 2.0 Security Update: cert-manager / cf-cli / docker-buildx / docker-compose / moby-compose / moby-engine / packer (CVE-2024-45337)	Nessus	MarinerOS Local Security Checks	critical
213037	Fedora 41 : golang-x-crypto (2024-c33c95804e)	Nessus	Fedora Local Security Checks	critical
213035	Fedora 40 : golang-x-crypto (2024-8f83d0ed92)	Nessus	Fedora Local Security Checks	critical

Detections

Analytics

CVE-2024-45337

critical

Tenable Plugins

critical

critical

medium

medium

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical