CVE-2026-39835

What it actually does

This vulnerability affects SSH server implementations that use the Go golang.org/x/crypto/ssh CertChecker as a public key authentication callback while leaving IsUserAuthority or IsHostAuthority unset. A remote unauthenticated client can present an SSH certificate during authentication and trigger a nil callback path that causes the server process to panic. The primary impact is availability: the SSH service, or the application embedding it, may crash or terminate depending on how panics are recovered and supervised. There is no indicated confidentiality or integrity impact, and exploitation does not require valid credentials.

Why it matters to the business

An exposed SSH service or Go application using the vulnerable CertChecker pattern could be remotely crashed, causing administrative access outages, automation failures, CI/CD or deployment interruptions, and degraded service availability. The CVSS score is moderate and EPSS is low and flat, with no known KEV or ransomware association, so broad active exploitation is not currently indicated; however, internet-facing SSH endpoints should still be patched because exploitation is simple and unauthenticated. Organizations with products or internal services built on golang.org/x/crypto/ssh should account for downstream dependency exposure even if OpenSSH itself is not affected.

How an attack unfolds

An attacker identifies an SSH server implemented in Go or an application embedding golang.org/x/crypto/ssh. During the SSH authentication exchange, the attacker presents a crafted or ordinary SSH certificate rather than a raw public key. If the server has configured CertChecker as the public key callback but has not set the relevant IsUserAuthority or IsHostAuthority callback, the certificate validation path attempts to use a nil authority callback and panics. If the application does not recover from the panic, the SSH server process exits or becomes unavailable until restarted. Repeating the connection attempt can cause recurring denial of service.

How to fix it

Upgrade golang.org/x/crypto/ssh to a version containing the fix once available through the project’s release channel or your language package manager. Because no exact fixed version was provided in the input, review upstream golang.org/x/crypto advisories, module release notes, and your dependency lock files to identify the corrected version where CertChecker returns an error instead of panicking. Rebuild and redeploy all applications statically linking the affected Go module. As a code-level mitigation, ensure CertChecker is not used with nil IsUserAuthority or IsHostAuthority callbacks when certificate authentication is possible; explicitly define the appropriate authority checks or reject certificate authentication safely. As operational mitigation, restrict network access to affected SSH services, place them behind trusted management networks or VPNs, and use process supervisors with backoff to reduce repeated crash loops, though supervision is not a substitute for patching.

How to confirm the fix worked

Confirm exposure by reviewing Go module manifests and lock files for use of golang.org/x/crypto/ssh and by inspecting SSH server code for CertChecker used as PublicKeyCallback without IsUserAuthority or IsHostAuthority being set. Confirm remediation by verifying the deployed binary was rebuilt with a fixed golang.org/x/crypto version and by reviewing code paths to ensure missing authority callbacks return authentication errors rather than panicking. In a controlled test environment, attempt SSH certificate authentication against the service and verify the connection is rejected cleanly, the process remains running, and logs show an authentication failure rather than a panic or crash. Also validate that service supervisors are not repeatedly restarting the process after certificate-authentication attempts.

Typical attack path

1. Scan for reachable SSH services, especially nonstandard Go-based SSH implementations or appliances embedding Go SSH libraries.
2. Initiate an SSH connection to the target service.
3. Offer an SSH certificate during public key authentication.
4. Trigger the vulnerable CertChecker certificate validation path where IsUserAuthority or IsHostAuthority is nil.
5. Cause the SSH server or parent application process to panic and terminate if the panic is not recovered.
6. Repeat the attempt to sustain service disruption after automatic restarts.

How to detect it

To determine whether exploitation already occurred, review application logs, stderr/stdout captures, systemd journal entries, container logs, crash dumps, and process supervisor logs for Go panic stack traces around SSH authentication. Focus on timestamps where SSH services restarted unexpectedly, exited with panic status, or entered crash loops after inbound SSH connection attempts. Search for log entries mentioning CertChecker, certificate authentication, nil pointer dereference, panic, and golang.org/x/crypto/ssh. Correlate crashes with network logs, firewall logs, load balancer logs, or SSH application logs showing unauthenticated inbound TCP connections to SSH ports, especially repeated attempts from the same source. If core dumps are enabled, inspect crash stacks for golang.org/x/crypto/ssh CertChecker certificate validation paths. Since no public exploit indicators or threat actors are identified, detection should emphasize behavioral evidence: unexpected SSH process termination during public key or certificate authentication.

• panic: runtime error: invalid memory address or nil pointer dereference
• golang.org/x/crypto/ssh.(*CertChecker)
• CertChecker
• IsUserAuthority
• IsHostAuthority
• ssh: cert is not signed by a recognized authority
• publickey callback
• certificate authentication
• Failed publickey
• systemd: Main process exited, code=exited, status=2
• systemd: Failed with result 'exit-code'
• panic serving
• runtime/debug.Stack

What your security team should do

• Inventory Go-based SSH servers and products that depend on golang.org/x/crypto/ssh, including statically linked binaries and vendor-supplied appliances.
• Prioritize internet-facing or business-critical SSH services for dependency review and remediation.
• Upgrade golang.org/x/crypto/ssh to the upstream fixed release when available and rebuild all affected applications.
• Review source code for CertChecker usage and ensure IsUserAuthority and IsHostAuthority are explicitly configured or certificate authentication is safely rejected.
• Restrict access to affected SSH services to trusted networks until remediation is complete.
• Monitor SSH service crashes, panic logs, and repeated certificate-authentication attempts as potential exploitation signals.
• Because EPSS is low, flat, and the issue is not in KEV, treat this as a moderate-priority availability fix unless the affected SSH service is externally exposed or operationally critical.