CVE-2024-45337

What it actually does

Applications misusing ServerConfig.PublicKeyCallback may authorize connections based on a key that was offered but not used for authentication, allowing an attacker to supply multiple keys and authenticate with one while the callback state reflects another.

Why it matters to the business

Organizations running Go-based SSH servers risk unauthorized access to systems and data if custom authorization logic relies on callback order or stored keys instead of the official Permissions.Extensions mechanism; prevalence of golang/crypto increases exposure across many applications.

How an attack unfolds

An attacker connects to an affected SSH server, supplies multiple public keys in sequence to trigger repeated PublicKeyCallback invocations, then completes authentication with a key they control; vulnerable applications that record the final callback key for later authorization decisions incorrectly associate privileges with an uncontrolled key.

How to fix it

Upgrade golang.org/x/crypto to commit b4f1988a35dee11ec3e05d6bf3e90b695fbd8909 or later; refactor code to store authentication data exclusively in the Permissions.Extensions field returned by authentication callbacks and retrieve it via ServerConn.Permissions after connection establishment; avoid sharing Permissions objects across attempts.

How to confirm the fix worked

Confirm golang.org/x/crypto version is at or above the fixed commit; test SSH servers by sending multiple keys followed by authentication and verify that only the actual authenticating key influences authorization decisions.

Typical attack path

1. Initiate SSH connection and send multiple public keys to invoke PublicKeyCallback repeatedly
2. Complete authentication using a controlled private key while the final callback reflects an uncontrolled key
3. Exploit application logic that derives authorization from the last observed callback key or stored state

How to detect it

Review SSH server logs for connections that present multiple public keys before successful authentication; inspect application logs or audit trails for authorization decisions made immediately after PublicKeyCallback invocations; correlate with source code paths that store keys outside Permissions.Extensions.

What your security team should do

• Prioritize upgrade of golang.org/x/crypto to the fixed commit across all affected services
• Audit all code and third-party libraries that implement or wrap PublicKeyCallback for reliance on callback ordering or external state
• Migrate authorization logic to use Permissions.Extensions before connection establishment completes
• Monitor dependency graphs for downstream projects that consume vulnerable golang/crypto versions