Misuse of connection.serverAuthenticate may cause authorization bypass in golang.org/x/crypto
cve-program · CVE-2024-45337
PublishedApplications 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/[email protected] 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.
Read the publisher's advisoryeuvd · EUVD-2024-3508
PublishedApplications 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/[email protected] 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.
Read the publisher's advisorynvd · CVE-2024-45337
PublishedApplications 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/[email protected] 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.
Read the publisher's advisoryosv · GHSA-v778-237x-gjrc
PublishedApplications 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/[email protected] 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.
Read the publisher's advisoryosv · GO-2024-3321
PublishedApplications 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/[email protected] 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.
Read the publisher's advisoryAffected versions, risk and source history
Exploitation and risk
Source statusCISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.
Which CVEs have scores here?
This view includes predictions for CVE identifiers explicitly listed in public NuGet advisories. Microsoft release pages have their own prediction coverage. Check source status for the scope and latest checks.
No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.
cve-program · CVE-2024-45337
PublishedMisuse of connection.serverAuthenticate may cause authorization bypass in golang.org/x/crypto
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/[email protected] 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.
- Source published
- 11 Dec 2024 18:55:58 UTC
- Source modified
- 18 Feb 2025 20:48:40 UTC
- Saved here
- 23 Oct 2026 15:48:27 UTC
- Source terms
- CVE Program Terms of Use
Original source record · Cite this exact observation · Complete original publisher JSON
Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
euvd · EUVD-2024-3508
PublishedApplications 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 …
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/[email protected] 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.
Additional publisher context
EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.
Original publisher date fields
datePublished: Dec 11, 2024, 6:55:58 PM
dateUpdated: Feb 18, 2025, 8:48:40 PM
151 related source bulletins · separate from aliases
SUSE-SU-2026:2581-1: Security update for google-guest-agent
CVE-2023-45288 · CVE-2024-45337 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-58181 · CVE-2026-33186 · CVE-2026-33814 · CVE-2026-34986 · CVE-2026-39821 · CVE-2026-39827 · CVE-2026-39828 · CVE-2026-39829 · CVE-2026-39830 · CVE-2026-39831 · CVE-2026-39832 · CVE-2026-39833 · CVE-2026-39834 · CVE-2026-39835 · CVE-2026-42508 · CVE-2026-46595 · CVE-2026-46597 · CVE-2026-46598
RHSA-2025:1448: Red Hat Security Advisory: RHOAI 2.17.0 - Red Hat OpenShift AI
CVE-2024-21538 · CVE-2024-45337 · CVE-2024-45338 · CVE-2024-45339 · CVE-2024-49767 · CVE-2024-52798 · CVE-2024-55565
SUSE-SU-2025:1143-1: Security update for google-guest-agent
CVE-2024-45337
openSUSE-SU-2025:14641-1: rclone-1.69.0-1.1 on GA media
CVE-2024-45337 · CVE-2024-45338
RHBA-2025:1076: Red Hat Bug Fix Advisory: Red Hat Quay v3.11.8 bug fix release
CVE-2024-45337 · CVE-2024-56201 · CVE-2024-56326
RHSA-2025:17232: Red Hat Security Advisory: OpenShift Container Platform 4.17.41 bug fix and security update
CVE-2024-45337
RHSA-2024:11037: Red Hat Security Advisory: OpenShift Container Platform 4.19.0 security and extras update
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22868 · CVE-2025-22869
openSUSE-SU-2025:20117-1: Security update for trivy
CVE-2024-3817 · CVE-2024-45337 · CVE-2024-45338 · CVE-2024-51744 · CVE-2025-11065 · CVE-2025-21613 · CVE-2025-21614 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-22872 · CVE-2025-27144 · CVE-2025-30204 · CVE-2025-46569 · CVE-2025-47291 · CVE-2025-53547 · CVE-2025-58058
RHSA-2025:8244: Red Hat Security Advisory: Red Hat OpenShift Dev Spaces 3.21.0 release
CVE-2024-12905 · CVE-2024-45337 · CVE-2024-45410 · CVE-2025-22869 · CVE-2025-30204
openSUSE-SU-2025:15463-1: docker-machine-driver-kvm2-1.36.0-2.1 on GA media
CVE-2024-45337
openSUSE-SU-2024:14585-1: cloudflared-2024.12.1-1.1 on GA media
CVE-2024-45337
RHBA-2025:0301: Red Hat Bug Fix Advisory: Red Hat Quay v3.13.3 bug fix release
CVE-2024-45337 · CVE-2024-55565 · CVE-2024-56201 · CVE-2024-56326
SUSE-SU-2025:03278-1: Security update for kubevirt, virt-api-container, virt-controller-container, virt-exportproxy-container, virt-exportserver-container, virt-handler-container, virt-launcher-container, virt-libguestfs-tools-container, virt-operator-container, virt-pr-helper-container
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22872
RHSA-2026:2681: Red Hat Security Advisory: Red Hat Quay 3.16.2
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-15284 · CVE-2025-31133 · CVE-2025-52881 · CVE-2025-61726 · CVE-2025-61729 · CVE-2025-65945 · CVE-2025-66418 · CVE-2025-66471 · CVE-2026-21441 · CVE-2026-24049
openSUSE-SU-2024:14604-1: logcli-3.3.2-1.1 on GA media
CVE-2024-45337
openSUSE-SU-2024:14593-1: helm-3.16.4-1.1 on GA media
CVE-2024-45337
RHSA-2025:0778: Red Hat Security Advisory: Multicluster Engine for Kubernetes 2.6.5 security updates and bug fixes
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-55565
RHSA-2025:23203: Red Hat Security Advisory: Red Hat OpenShift GitOps v1.18.2 security update
CVE-2024-45337 · CVE-2025-13888 · CVE-2025-49844
RHBA-2025:1077: Red Hat Bug Fix Advisory: Red Hat Quay v3.10.8 bug fix release
CVE-2024-45337 · CVE-2024-56201 · CVE-2024-56326
openSUSE-SU-2024:14599-1: govulncheck-vulndb-0.0.20241213T205935-1.1 on GA media
CVE-2020-10696 · CVE-2020-8912 · CVE-2022-31668 · CVE-2023-26248 · CVE-2023-3676 · CVE-2023-3955 · CVE-2024-12401 · CVE-2024-37032 · CVE-2024-44337 · CVE-2024-45039 · CVE-2024-45337 · CVE-2024-45436 · CVE-2024-46455 · CVE-2024-46528 · CVE-2024-53257 · CVE-2024-53859 · CVE-2024-55601 · CVE-2024-55657 · CVE-2024-55658 · CVE-2024-55659 · CVE-2024-55660
openSUSE-SU-2025:14920-1: gitleaks-8.24.2-1.1 on GA media
CVE-2024-45337
RHSA-2025:0679: Red Hat Security Advisory: Red Hat Advanced Cluster Management 2.10.7 bug fixes and container updates
CVE-2024-45337 · CVE-2024-45338
RHEA-2025:12284: Red Hat Enhancement Advisory: OpenShift Virtualization 4.17.22 Images
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869
RHSA-2025:15680: Red Hat Security Advisory: OpenShift Container Platform 4.16.48 bug fix and security update
CVE-2024-45337
RHSA-2025:0649: Red Hat Security Advisory: OpenShift Container Platform 4.16.32 security and extras update
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:0536: Red Hat Security Advisory: cert-manager Operator for Red Hat OpenShift 1.15.0
CVE-2023-45288 · CVE-2024-6104 · CVE-2024-24783 · CVE-2024-28180 · CVE-2024-35255 · CVE-2024-45337 · CVE-2024-45338
RHSA-2025:0485: Red Hat Security Advisory: cert-manager Operator for Red Hat OpenShift 1.15.0
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:0385: Red Hat Security Advisory: VolSync 0.11.1 for RHEL 9
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-53259
SUSE-SU-2025:0770-1: Security update for govulncheck-vulndb
CVE-2024-45337 · CVE-2025-22868 · CVE-2025-22869
RHSA-2025:0723: Red Hat Security Advisory: Multicluster Engine for Kubernetes 2.7.3 security updates and bug fixes
CVE-2024-45337 · CVE-2024-55565
RHSA-2025:0892: Red Hat Security Advisory: Red Hat OpenShift Dev Spaces 3.18.0 release
CVE-2023-44270 · CVE-2024-21538 · CVE-2024-45337 · CVE-2024-45338 · CVE-2024-45801 · CVE-2024-53899 · CVE-2024-55565
openSUSE-SU-2025:14660-1: golang-github-prometheus-prometheus-3.1.0-1.1 on GA media
CVE-2024-45337
RHSA-2025:0535: Red Hat Security Advisory: cert-manager Operator for Red Hat OpenShift 1.15.0
CVE-2024-45337 · CVE-2024-45338
openSUSE-SU-2026:20620-1: Security update for rclone
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-51744 · CVE-2024-52522 · CVE-2025-22869 · CVE-2025-22870 · CVE-2025-30204 · CVE-2025-58181 · CVE-2025-68121 · CVE-2026-1229 · CVE-2026-27141 · CVE-2026-33186 · CVE-2026-41176 · CVE-2026-41179
openSUSE-SU-2026:12299-1: kubeseal-0.41.1-1.1 on GA media
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-47911 · CVE-2025-58181
RHSA-2025:16165: Red Hat Security Advisory: OpenShift Container Platform 4.14.57 bug fix and security update
CVE-2024-45337 · CVE-2025-22869
RHSA-2025:1841: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337 · CVE-2024-45338
openSUSE-SU-2025:0025-1: Security update for cheat
CVE-2024-45337
openSUSE-SU-2024:14573-1: teleport-17.0.5-1.1 on GA media
CVE-2024-45337
RHSA-2025:10771: Red Hat Security Advisory: OpenShift Container Platform 4.19.4 bug fix and security update
CVE-2024-45337 · CVE-2025-32462
RHSA-2025:0386: Red Hat Security Advisory: VolSync 0.10.2 for RHEL 9
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-53259
RHSA-2025:0653: Red Hat Security Advisory: OpenShift Container Platform 4.17.14 security and extras update
CVE-2024-45337 · CVE-2024-45338
openSUSE-SU-2025:15779-1: helm3-3.19.2-1.1 on GA media
CVE-2018-16873 · CVE-2018-16874 · CVE-2018-16875 · CVE-2021-21272 · CVE-2022-1996 · CVE-2022-23524 · CVE-2022-23525 · CVE-2022-23526 · CVE-2022-36055 · CVE-2023-25165 · CVE-2023-25173 · CVE-2024-25620 · CVE-2024-26147 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22870 · CVE-2025-22872 · CVE-2025-47911 · CVE-2025-53547 · CVE-2025-58190
RHSA-2025:1332: Red Hat Security Advisory: Gatekeeper v3.15.3
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:0445: Red Hat Security Advisory: Red Hat Trusted Profile Analyzer 1.2.2
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613 · CVE-2025-21614
SUSE-SU-2025:20278-1: Security update for helm
CVE-2024-25620 · CVE-2024-26147 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22870
openSUSE-SU-2025-20117-1: Security update for trivy
CVE-2024-3817 · CVE-2024-45337 · CVE-2024-45338 · CVE-2024-51744 · CVE-2025-11065 · CVE-2025-21613 · CVE-2025-21614 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-22872 · CVE-2025-27144 · CVE-2025-30204 · CVE-2025-46569 · CVE-2025-47291 · CVE-2025-53547 · CVE-2025-58058
openSUSE-SU-2024:14595-1: traefik2-2.11.16-1.1 on GA media
CVE-2024-45337
openSUSE-SU-2026:21603-1: Security update for gitea-tea
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869 · CVE-2025-22872 · CVE-2025-47911 · CVE-2025-47913 · CVE-2025-58190
RHSA-2025:2903: Red Hat Security Advisory: Red Hat OpenShift Pipelines Release 1.18.0
CVE-2024-45337 · CVE-2024-45338
SUSE-SU-2025:0524-1: Security update for SUSE Manager Client Tools
CVE-2023-3128 · CVE-2023-6152 · CVE-2024-22037 · CVE-2024-45337 · CVE-2024-51744 · CVE-2024-6837 · CVE-2024-8118
RHSA-2025:1287: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
RHSA-2025:22287: Red Hat Security Advisory: Red Hat Quay 3.9
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-59420 · CVE-2025-61920
RHSA-2025:19306: Red Hat Security Advisory: OpenShift Container Platform 4.15.59 bug fix and security update
CVE-2024-45337 · CVE-2024-48910 · CVE-2025-22871
RHSA-2025:0370: Red Hat Security Advisory: Red Hat build of OpenTelemetry 3.4 release
CVE-2024-45337 · CVE-2024-45338
RHEA-2025:10586: Red Hat Enhancement Advisory: OpenShift Virtualization 4.16.14 Images
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869
RHSA-2025:1849: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
openSUSE-SU-2025:14613-1: velero-1.15.1-1.1 on GA media
CVE-2024-45337 · CVE-2024-45338
openSUSE-SU-2025:14969-1: google-guest-agent-20250327.01-1.1 on GA media
CVE-2024-45337
openSUSE-SU-2025:0056-1: Security update for trivy
CVE-2024-34155 · CVE-2024-34156 · CVE-2024-34158 · CVE-2024-3817 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613 · CVE-2025-21614
SUSE-SU-2025:20196-1: Security update for helm
CVE-2024-25620 · CVE-2024-26147 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22870
openSUSE-SU-2025:0094-1: Security update for gitea-tea
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869
RHSA-2025:0676: Red Hat Security Advisory: Multicluster Engine for Kubernetes 2.5.8 security updates and bug fixes
CVE-2024-45337
RHSA-2025:1334: Red Hat Security Advisory: ACS 4.5 enhancement and security update
CVE-2024-11831 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613 · CVE-2025-21614
openSUSE-SU-2026:12295-1: k3sup-0.13.14-1.1 on GA media
CVE-2024-45337 · CVE-2025-22869 · CVE-2025-47913 · CVE-2025-47914 · CVE-2025-58181
RHSA-2026:6568: Red Hat Security Advisory: Red Hat Quay 3.15.4
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-61726 · CVE-2025-61728 · CVE-2025-61729 · CVE-2025-68121 · CVE-2025-68158 · CVE-2025-69873 · CVE-2026-4598 · CVE-2026-4599 · CVE-2026-4600 · CVE-2026-4601 · CVE-2026-4602 · CVE-2026-25639 · CVE-2026-25990 · CVE-2026-26007 · CVE-2026-26996 · CVE-2026-27628 · CVE-2026-27904 · CVE-2026-28498 · CVE-2026-28802 · CVE-2026-29063 · CVE-2026-29074 · CVE-2026-30922 · CVE-2026-32597
openSUSE-SU-2025:14633-1: grafana-11.3.0-4.1 on GA media
CVE-2024-45337
RHSA-2025:1322: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
RHSA-2025:3820: Red Hat Security Advisory: RHTAS 1.1.2 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-27144 · CVE-2025-30204
RHSA-2025:17690: Red Hat Security Advisory: OpenShift Container Platform 4.16.50 bug fix and security update
CVE-2024-45337
SUSE-SU-2026:0592-1: Security update for vexctl
CVE-2024-45337 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-22870 · CVE-2025-27144 · CVE-2025-30204 · CVE-2025-58181 · CVE-2026-22772 · CVE-2026-24137
SUSE-SU-2025:0980-1: Security update for apptainer
CVE-2024-41110 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869 · CVE-2025-22870 · CVE-2025-27144
SUSE-SU-2025:0545-1: Security update for grafana
CVE-2023-3128 · CVE-2023-6152 · CVE-2024-45337 · CVE-2024-6837 · CVE-2024-8118
openSUSE-SU-2024:14590-1: traefik-3.2.3-1.1 on GA media
CVE-2024-45337
RHSA-2025:23064: Red Hat Security Advisory: Red Hat Quay 3.10.17
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-47913 · CVE-2025-59420 · CVE-2025-61920
SUSE-SU-2025:0601-1: Security update for brise
CVE-2024-45337 · CVE-2025-21613
RHSA-2025:0851: Red Hat Security Advisory: Red Hat Advanced Cluster Management 2.12.2 security and bug fix updates
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-55565
RHSA-2025:3069: Red Hat Security Advisory: Errata Advisory for Red Hat OpenShift GitOps v1.14.3 security update
CVE-2023-44270 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613 · CVE-2025-21614 · CVE-2025-23216
RHSA-2025:0444: Red Hat Security Advisory: Red Hat Trusted Profile Analyzer 1.2.2
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613 · CVE-2025-21614
RHSA-2025:1331: Red Hat Security Advisory: Gatekeeper v3.17.1
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:3542: Red Hat Security Advisory: RHODF-4.15-RHEL-9 security update
CVE-2024-45337 · CVE-2024-45338
openSUSE-SU-2024:14602-1: tailscale-1.78.3-2.1 on GA media
CVE-2024-45337
openSUSE-SU-2025:14713-1: trivy-0.58.2-1.1 on GA media
CVE-2024-3817 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613
RHSA-2024:6121: Red Hat Security Advisory: OpenShift Container Platform 4.18.1 security and extras update
CVE-2019-25210 · CVE-2023-44270 · CVE-2024-21538 · CVE-2024-45337 · CVE-2024-45338 · CVE-2024-45590 · CVE-2024-48910 · CVE-2024-52798 · CVE-2024-55565 · CVE-2024-56201 · CVE-2024-56326 · CVE-2025-21613 · CVE-2025-21614
RHSA-2025:1451: Red Hat Security Advisory: OpenShift Container Platform 4.14.48 security update
CVE-2024-12085 · CVE-2024-45337 · CVE-2024-45338 · CVE-2024-53104
RHSA-2025:11396: Red Hat Security Advisory: OpenShift API for Data Protection (OADP) 1.4.5 security and bug fix update
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-22871 · CVE-2025-27144 · CVE-2025-30204
openSUSE-SU-2026:10230-1: vexctl-0.4.1+git78.f951e3a-1.1 on GA media
CVE-2024-45337 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-22870 · CVE-2025-27144 · CVE-2025-30204 · CVE-2025-58181 · CVE-2026-22772 · CVE-2026-24137
RHSA-2025:0552: Red Hat Security Advisory: Multicluster Engine for Kubernetes 2.4.7 security updates and bug fixes
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:2588: Red Hat Security Advisory: RHOAI 2.18.0 - Red Hat OpenShift AI
CVE-2024-11187 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22150 · CVE-2025-24970
RHSA-2025:1845: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
RHSA-2025:23206: Red Hat Security Advisory: Red Hat OpenShift GitOps v1.17.3 security update
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-13888 · CVE-2025-49844
RHSA-2025:1325: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
openSUSE-SU-2026:12300-1: kumactl-3.0.0-1.1 on GA media
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-51744 · CVE-2025-22869 · CVE-2025-22872 · CVE-2025-30204 · CVE-2025-47911 · CVE-2025-47913 · CVE-2025-47914 · CVE-2025-58181 · CVE-2025-58190 · CVE-2026-26958 · CVE-2026-33186 · CVE-2026-41178
openSUSE-SU-2026:20730-1: Security update for apptainer
CVE-2023-45288 · CVE-2024-28180 · CVE-2024-3727 · CVE-2024-41110 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869 · CVE-2025-22870 · CVE-2025-22872 · CVE-2025-27144 · CVE-2025-47911 · CVE-2025-47913 · CVE-2025-47914 · CVE-2025-58181 · CVE-2025-58190 · CVE-2025-65105 · CVE-2025-8556 · CVE-2026-24137 · CVE-2026-33186 · CVE-2026-34986
SUSE-SU-2025:1142-1: Security update for google-guest-agent
CVE-2024-45337
SUSE-SU-2025:01985-1: Security update 4.3.15 for Multi-Linux Manager Server
CVE-2023-45288 · CVE-2024-11741 · CVE-2024-45337 · CVE-2024-45339 · CVE-2024-47535 · 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
RHSA-2025:0577: Red Hat Security Advisory: Red Hat multicluster global hub 1.3.2 enhancements and container updates
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:1829: Red Hat Security Advisory: RHODF-4.16-RHEL-9 security update
CVE-2023-44270 · CVE-2024-6104 · CVE-2024-21528 · CVE-2024-45337 · CVE-2024-45338
RHSA-2026:2762: Red Hat Security Advisory: Red Hat Quay 3.10.18
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-12816 · CVE-2025-15284 · CVE-2025-52881 · CVE-2025-61729 · CVE-2025-65945 · CVE-2025-66031 · CVE-2025-66418 · CVE-2025-66471 · CVE-2025-66506 · CVE-2026-21441 · CVE-2026-24049
RHSA-2025:1327: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
RHSA-2025:16160: Red Hat Security Advisory: OpenShift Container Platform 4.15.58 bug fix and security update
CVE-2024-45337 · CVE-2024-45339 · CVE-2025-22869
RHSA-2025:1289: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:0839: Red Hat Security Advisory: OpenShift Container Platform 4.14.46 security update
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:1468: Red Hat Security Advisory: ACS 4.4 enhancement and security update
CVE-2024-11831 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613 · CVE-2025-21614
RHSA-2025:0560: Red Hat Security Advisory: Red Hat Multicluster GlobalHub 1.2.1 bug fixes and container updates
CVE-2024-45337 · CVE-2024-45338
openSUSE-SU-2026:20609-1: Security update for google-guest-agent
CVE-2023-45288 · CVE-2024-45337
RHSA-2025:1324: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:23207: Red Hat Security Advisory: Red Hat OpenShift GitOps v1.16.5 security update
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-13888 · CVE-2025-49844
openSUSE-SU-2025:14902-1: rime-plum-1.0.3-1.1 on GA media
CVE-2024-45337 · CVE-2025-2161 · CVE-2025-21613
RHSA-2025:1824: Red Hat Security Advisory: RHODF-4.17-RHEL-9 security update
CVE-2023-44270 · CVE-2024-21528 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-0426
RHSA-2025:0645: Red Hat Security Advisory: OpenShift Container Platform 4.15.44 security update
CVE-2024-45337 · CVE-2024-45338
RHSA-2025:17657: Red Hat Security Advisory: OpenShift Container Platform 4.18.26 bug fix and security update
CVE-2024-45337
RHBA-2025:1597: Red Hat Bug Fix Advisory: Red Hat Quay v3.9.10 bug fix release
CVE-2020-11023 · CVE-2024-45337 · CVE-2024-56201 · CVE-2024-56326
RHSA-2025:0522: Red Hat Security Advisory: Red Hat OpenShift distributed tracing platform (Jaeger) 3.4 release
CVE-2024-45337 · CVE-2024-45338
openSUSE-SU-2025:20143-1: Security update for git-bug
CVE-2024-45337 · CVE-2025-22869 · CVE-2025-47911 · CVE-2025-47913 · CVE-2025-47914 · CVE-2025-58181 · CVE-2025-58190
RHSA-2025:0576: Red Hat Security Advisory: Red Hat Advanced Cluster Management 2.9.6 bug fixes and container updates
CVE-2024-45337 · CVE-2024-45338
openSUSE-SU-2026:21481-1: Security update for vexctl
CVE-2024-45337 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-22870 · CVE-2025-27144 · CVE-2025-30204 · CVE-2025-58181 · CVE-2026-22772 · CVE-2026-24137
RHSA-2025:1285: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
openSUSE-SU-2025:15013-1: gopass-1.15.16-1.1 on GA media
CVE-2024-45337
openSUSE-SU-2026:20893-1: Security update for cloudflared
CVE-2024-45337 · CVE-2025-22869 · CVE-2025-58181 · CVE-2026-33814 · CVE-2026-39821
RHSA-2025:22182: Red Hat Security Advisory: Red Hat Quay 3.10.16
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-59420 · CVE-2025-61920
RHSA-2025:1333: Red Hat Security Advisory: Gatekeeper v3.14.3
CVE-2024-45337 · CVE-2024-45338
msrc_CVE-2024-45337: Misuse of connection.serverAuthenticate may cause authorization bypass in golang.org/x/crypto
CVE-2024-45337
RHSA-2025:3560: Red Hat Security Advisory: RHODF-4.14-RHEL-9 security update
CVE-2024-45337 · CVE-2024-45338
RHEA-2025:3152: Red Hat Enhancement Advisory: OpenShift Virtualization 4.18.1 Images
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-21613 · CVE-2025-21614 · CVE-2025-27144
SUSE-SU-2026:21319-1: Security update for google-guest-agent
CVE-2023-45288 · CVE-2024-45337
SUSE-SU-2025:0602-1: Security update for helm
CVE-2024-45337 · CVE-2024-45338
RHBA-2025:0250: Red Hat Bug Fix Advisory: Red Hat Quay v3.12.7 bug fix release
CVE-2024-45337 · CVE-2024-56201 · CVE-2024-56326
RHSA-2025:0785: Red Hat Security Advisory: Red Hat Advanced Cluster Management 2.11.5 bug fixes and container updates
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-55565
RHSA-2026:1730: Red Hat Security Advisory: Red Hat Quay 3.12.13
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-12816 · CVE-2025-15284 · CVE-2025-52881 · CVE-2025-65945 · CVE-2025-66031 · CVE-2025-66418 · CVE-2025-66471 · CVE-2025-66506 · CVE-2026-21441
openSUSE-SU-2026:20798-1: Security update for trivy
CVE-2024-3817 · CVE-2024-45337 · CVE-2024-45338 · CVE-2024-51744 · CVE-2025-11065 · CVE-2025-21613 · CVE-2025-21614 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-22872 · CVE-2025-27144 · CVE-2025-30204 · CVE-2025-46569 · CVE-2025-47291 · CVE-2025-47911 · CVE-2025-47913 · CVE-2025-47914 · CVE-2025-53547 · CVE-2025-58058 · CVE-2025-58181 · CVE-2025-58190
RHSA-2025:2652: Red Hat Security Advisory: RHODF-4.18-RHEL-9 enhancement, bug fix and security update
CVE-2023-44270 · CVE-2024-21528 · CVE-2024-21538 · CVE-2024-45337 · CVE-2024-45338 · CVE-2024-55565 · CVE-2025-0426
openSUSE-SU-2024:14592-1: git-bug-0.8.0+git.1733745604.d499b6e-1.1 on GA media
CVE-2024-45337
RHSA-2025:0390: Red Hat Security Advisory: Red Hat OpenShift distributed tracing platform (Tempo) 3.4 release
CVE-2024-45337 · CVE-2024-45338
RHSA-2026:2754: Red Hat Security Advisory: Red Hat Quay 3.9.18
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-12816 · CVE-2025-52881 · CVE-2025-61726 · CVE-2025-61729 · CVE-2025-65945 · CVE-2025-66031 · CVE-2025-66418 · CVE-2025-66506 · CVE-2026-24049
RHSA-2025:23061: Red Hat Security Advisory: Red Hat Quay 3.9.17
CVE-2024-34156 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-47913 · CVE-2025-59420 · CVE-2025-61920
RHSA-2025:1847: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
WID-SEC-W-2025-0226: Red Hat Enterprise Linux (Advanced Cluster Management): Mehrere Schwachstellen
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-55565
RHSA-2025:1848: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
WID-SEC-W-2024-3690: Gitea: Schwachstelle ermöglicht Umgehen von Sicherheitsvorkehrungen
CVE-2024-45337
openSUSE-SU-2025:14909-1: apptainer-1.3.6-5.1 on GA media
CVE-2024-41110 · CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869 · CVE-2025-22870 · CVE-2025-27144
RHSA-2025:2933: Red Hat Security Advisory: Red Hat OpenShift Pipelines Release 1.18.0
CVE-2024-45337 · CVE-2024-45338
RHEA-2025:4438: Red Hat Enhancement Advisory: Red Hat OpenShift Service on AWS 1.0 enhancements
CVE-2024-45337 · CVE-2025-30204
RHSA-2025:1710: Red Hat Security Advisory: OpenShift Container Platform 4.15.46 security and extras update
CVE-2024-45337 · CVE-2024-45338 · CVE-2024-56326
RHSA-2025:1326: Red Hat Security Advisory: RHTAS 1.1.1 - Red Hat Trusted Artifact Signer Release
CVE-2024-45337
RHEA-2025:15037: Red Hat Enhancement Advisory: OpenShift Virtualization 4.14.14 Images
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869
RHEA-2025:13172: Red Hat Enhancement Advisory: OpenShift Virtualization 4.18.12 Images
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22869
SUSE-SU-2025:0525-1: Security update for SUSE Manager Client Tools
CVE-2023-3128 · CVE-2023-6152 · CVE-2024-22037 · CVE-2024-45337 · CVE-2024-51744 · CVE-2024-6837 · CVE-2024-8118
SUSE-SU-2025:02581-1: Security update for kubevirt, virt-api-container, virt-controller-container, virt-exportproxy-container, virt-exportserver-container, virt-handler-container, virt-launcher-container, virt-libguestfs-tools-container, virt-operator-container, virt-pr-helper-container
CVE-2024-45337 · CVE-2024-45338
SUSE-SU-2026:21376-1: Security update for google-guest-agent
CVE-2023-45288 · CVE-2024-45337
RHSA-2024:11038: Red Hat Security Advisory: OpenShift Container Platform 4.19.0 bug fix and security update
CVE-2024-45337 · CVE-2024-45338 · CVE-2025-22868 · CVE-2025-22869 · CVE-2025-27144 · CVE-2025-29781
- Source published
- Dec 11, 2024, 6:55:58 PM (timezone not stated)
- Source modified
- Feb 18, 2025, 8:48:40 PM (timezone not stated)
- Saved here
- 15 Nov 2026 03:42:12 UTC
- Source terms
- ENISA EUVD · source terms and attribution apply
Original source record · Cite this exact observation · Complete original publisher JSON
Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
EUVD CVSS 3.1 · 9.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
nvd · CVE-2024-45337
PublishedApplications 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 …
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/[email protected] 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.
Additional publisher context
NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.
Source analysis status: Deferred
Original publisher date fields
published: 2024-12-12T02:02:07.970
lastModified: 2026-06-17T07:54:03.360
- Source published
- 12 Dec 2024 02:02:07 UTC
- Source modified
- 17 Jun 2026 07:54:03 UTC
- Saved here
- 25 Oct 2026 00:17:28 UTC
- Source terms
- NIST NVD usage terms; underlying source attribution retained
Original source record · Cite this exact observation · Complete original publisher JSON
Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS 3.1 · 134c704f-9b21-4f2e-91b3-4a467353bcc0 · Secondary · 9.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
osv · GHSA-v778-237x-gjrc
PublishedMisuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
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/[email protected] 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.
- Source published
- 11 Dec 2024 22:03:04 UTC
- Source modified
- 10 Sep 2026 03:50:56 UTC
- Saved here
- 24 Oct 2026 13:19:41 UTC
- Source terms
- GitHub Advisory Database · CC-BY-4.0
Original source record · Cite this exact observation · Complete original publisher JSON
Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Publisher rating · CRITICAL
osv · GO-2024-3321
PublishedMisuse of connection.serverAuthenticate may cause authorization bypass in golang.org/x/crypto
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/[email protected] 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.
- Source published
- 11 Dec 2024 18:40:19 UTC
- Source modified
- 14 Nov 2026 13:12:14 UTC
- Saved here
- 14 Nov 2026 13:57:00 UTC
- Source terms
- OSV · upstream source license applies
Original source record · Cite this exact observation · Complete original publisher JSON
Source: osv · OSV · upstream source license applies. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.