CVE-2026-46595

What it actually does

This vulnerability affects SSH servers implemented with the Go golang.org/x/crypto/ssh package. A source-address authorization restriction can be skipped when the server configuration uses authentication callbacks other than the public-key callback path. In practical terms, an SSH certificate or credential that should only be accepted from specific client IP ranges may be accepted from an unauthorized source address, allowing a remote attacker to bypass location-based access controls. The impact is most severe for custom SSH services that rely on SSH certificate critical options, source-address restrictions, bastion-only access models, or callback-based authentication logic for authorization decisions.

Why it matters to the business

An attacker may be able to access SSH-backed services from locations that should have been blocked, weakening network segmentation, bastion enforcement, and privileged access controls. For organizations using Go-based SSH servers in administrative planes, embedded products, developer platforms, or automation systems, this can lead to unauthorized access to sensitive systems, source code, deployment workflows, or operational tooling. Although this issue is not currently listed in CISA KEV and has a low EPSS score, the CVSS severity is critical because exploitation can be remote, low-complexity, and may compromise confidentiality and integrity where affected configurations are present.

How an attack unfolds

An attacker first identifies an SSH service implemented using the affected Go crypto SSH library. They then determine or obtain credentials, certificates, or authentication material that the service may accept but that should be constrained by source-address authorization rules. If the server uses an affected callback configuration, the source-address validation is not enforced on the vulnerable path. The attacker connects from an IP address that should not be authorized, completes the applicable SSH authentication flow, and gains access that policy intended to restrict to trusted networks or bastion hosts. After access is established, the attacker can interact with the exposed SSH service according to the privileges associated with the accepted identity, potentially issuing commands, accessing files, tunneling traffic, or pivoting depending on the application’s SSH functionality.

How to fix it

Upgrade affected applications and products to a version that includes the patched golang.org/x/crypto/ssh behavior as soon as a fixed package version is available from the Go project or the affected vendor. Because no exact fixed version was provided in the input, track upstream golang.org/x/crypto advisories and rebuild all applications that vendor or statically compile the vulnerable module. As a compensating control, do not rely solely on SSH certificate source-address restrictions in affected services. Enforce source IP restrictions at the network layer using firewalls, security groups, load balancers, reverse proxies, VPN policy, or bastion controls. Review custom SSH server code to ensure source-address validation is performed explicitly and consistently for every authentication callback path, including password, keyboard-interactive, certificate, and custom authentication flows. Rotate or reissue SSH certificates if there is evidence that source-address constraints were bypassed.

How to confirm the fix worked

Inventory Go applications and products that import golang.org/x/crypto/ssh, including statically linked binaries and vendored dependencies. Use dependency scanning, SBOMs, go.mod/go.sum review, and vendor manifests to identify affected versions. Confirm whether the application implements an SSH server and whether it uses source-address restrictions, SSH certificates, or non-public-key authentication callbacks. After upgrading, rebuild and redeploy the application, then verify the compiled binary includes the patched dependency version. Functionally test by attempting to authenticate with a source-address-constrained credential or SSH certificate from both an allowed and a disallowed client IP; the disallowed source must be rejected across every configured authentication method. Also confirm that network-layer source restrictions independently block unauthorized origins.

Typical attack path

1. Identify an exposed SSH service or product implemented with golang.org/x/crypto/ssh.
2. Determine whether the service uses SSH certificates, source-address restrictions, or callback-based authentication logic.
3. Obtain or reuse authentication material that is valid for the target identity but intended to be limited to specific source addresses.
4. Connect to the SSH service from an unauthorized network location.
5. Authenticate through an affected non-public-key callback path where source-address validation is skipped.
6. Use the resulting SSH session to access protected functionality, data, commands, or downstream systems.

How to detect it

To determine whether exploitation already occurred, review SSH server logs, application authentication logs, audit logs, bastion logs, firewall flow logs, VPN logs, and identity/certificate issuance records. Focus on successful SSH authentications where the client source IP was outside the permitted source-address range for the credential, certificate, user, service account, or administrative role. Compare accepted logins against expected bastion IPs, VPN egress ranges, corporate NAT ranges, and certificate critical options. Investigate successful sessions using password, keyboard-interactive, or custom callback-style authentication where source-address restrictions were expected to apply. Look for anomalous SSH activity following such logins, including command execution, file transfers, port forwarding, new authorized keys, privilege escalation, credential access, or lateral movement. There are no universal exploit strings for this vulnerability; detection depends on correlating successful SSH authentication events with policy-defined allowed source addresses.

What your security team should do

• Prioritize internet-facing or remotely reachable Go-based SSH services that use golang.org/x/crypto/ssh.
• Identify services that depend on SSH certificate source-address restrictions or bastion-only access assumptions, as these are highest risk.
• Upgrade or rebuild affected applications once a patched golang.org/x/crypto version is available; do not assume static binaries are fixed until rebuilt.
• Apply network-layer allowlisting for SSH access so authorization does not depend solely on application-level source-address checks.
• Review custom SSH authentication callback code for inconsistent authorization checks across public key, password, keyboard-interactive, and custom callbacks.
• Search historical SSH access logs for successful authentications from IP addresses outside expected source ranges.
• If suspicious access is found, revoke affected SSH certificates or credentials, rotate secrets, and investigate post-authentication activity.