cbcvebase.
CVE-2024-45337
published 2024-12-12

CVE-2024-45337: Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an…

PriorityP262critical9.1CVSS 3.1
AVNACLPRNUINSUCHIHAN
EPSS
3.09%
86.1th percentile
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 connectio

Affected

72 ranges· showing 25
VendorProductVersion rangeFixed in
advanced-cluster-securityrhacs-main-rhel8
assistedagent-preinstall-image-builder-rhel9
buildah_projectbuildah
cert-managerjetstack-cert-manager-rhel9
complianceopenshift-security-profiles-rhel8-operator
confidential-containerstrustee
container-tools_rhel8buildah
container-tools_rhel8podman
cryostatcryostat-storage-rhel9
debiangolang-go.crypto< golang-go.crypto 1:0.42.0-1 (forky)golang-go.crypto 1:0.42.0-1 (forky)
devspacestraefik-rhel9
devworkspacedevworkspace-rhel9-operator
external-secrets-operatorexternal-secrets-rhel9
go-toolset_rhel8golang
golang.orgx_crypto>= 0 < 0.31.00.31.0
golang.orgx_crypto_golang.org_x_crypto_ssh< 0.52.00.52.0
golang.orgx_crypto_ssh>= 0 < 0.52.00.52.0
golangcrypto< 0.52.00.52.0
kubernetescri-o
kubevirtkubevirt
msrcazl3_cert-manager_1.12.13-2
msrcazl3_cf-cli_8.7.11-3
msrcazl3_cf-cli_8.7.3-4
msrcazl3_docker-buildx_0.14.0-2
msrcazl3_docker-buildx_0.14.0-5

Detection & IOCsextracted from sources · hover to see the quote

  • Detect SSH clients sending multiple public keys during authentication (key A then key B) without proving control of the last key — a pattern indicative of CVE-2024-45337 exploitation attempts against vulnerable Go SSH servers using PublicKeyCallback.
  • Flag Go SSH server applications using ServerConfig.PublicKeyCallback that store keys or derived information from the callback and make authorization decisions after connection establishment — these are the vulnerable code patterns for CVE-2024-45337.
  • Monitor for SSH authentication sequences where the final key presented to PublicKeyCallback differs from the key actually used to complete authentication (e.g., connection authenticated via PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth after public key inquiry).
  • Audit Go binaries and container images linking golang.org/x/crypto/ssh versions prior to v0.31.0 — the partial mitigation enforcing last-key consistency was introduced at that version.
  • ·The fix in golang.org/x/[email protected] is only a PARTIAL mitigation. If the SSH connection is ultimately authenticated via a non-public-key method (PasswordCallback, KeyboardInteractiveCallback, NoClientAuth), the last key passed to PublicKeyCallback may still not be the one the client controls, leaving the bypass possible.
  • ·Applications must use the Extensions field of the Permissions return value from authentication callbacks to record authentication-attempt data, and retrieve final state via ServerConn.Permissions — relying on external state shared across attempts is the root vulnerable pattern.
  • ·Some third-party libraries misuse the Permissions type by sharing it across authentication attempts; consumers of such libraries remain vulnerable even after upgrading golang.org/x/crypto and must consult those upstream projects separately.
  • ·RHEL 8/9 packages (Podman, Buildah, containers-common, gvisor-tap-vsock) are assessed NOT affected because those projects do not call ServerConfig.PublicKeyCallback; do not conflate package presence with exploitability.
  • ·A related follow-on vulnerability (CVE-2026-46595) was identified where, even after the CVE-2024-45337 fix, passing a non-public-key callback type causes source-address validation to be skipped entirely — environments that applied the v0.31.0 patch should also track this successor issue.

CVSS provenance

nvdv3.19.1CRITICALCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
ghsa9.1CRITICAL
osv9.1CRITICAL
vendor_debian9.1CRITICAL
vendor_msrc9.1CRITICAL
vendor_redhat9.1CRITICAL
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.