CVE-2026-35387

What it actually does

OpenSSH before 10.3 incorrectly interprets ECDSA entries in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms. If an administrator intends to allow only a specific ECDSA signature algorithm, sshd may treat that configuration as allowing all ECDSA algorithms instead. The impact is an authentication policy bypass at the algorithm-selection layer: a user who already has some level of authentication opportunity may be able to authenticate using an ECDSA algorithm that the server operator intended to disallow. The CVSS impact is low because exploitation requires network access and a legitimate authentication context, and it affects integrity of access-control policy rather than directly exposing data or causing service disruption.

Why it matters to the business

Organizations relying on OpenSSH configuration to restrict approved cryptographic algorithms may have weaker-than-expected SSH authentication controls. This can undermine compliance requirements, cryptographic hardening standards, and host-access governance, especially in regulated environments where only specific algorithms are permitted. The current exploitation signal is low: EPSS is 0.00237 with no 30-day upward trend, it is not listed in CISA KEV, and there is no known ransomware association, so remediation should be planned through normal patch and configuration-management processes unless SSH cryptographic policy enforcement is business-critical.

How an attack unfolds

An attacker first needs a way to attempt SSH public-key or host-based authentication against a vulnerable OpenSSH server. The attacker identifies or assumes that the server configuration includes at least one ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms. Because vulnerable versions misinterpret the presence of any ECDSA entry as permitting all ECDSA algorithms, the attacker attempts authentication with an ECDSA algorithm that the organization intended to prohibit. If the attacker otherwise has a valid account/key relationship or valid host-based authentication material, the server may accept authentication under the unintended algorithm. This does not by itself grant access to arbitrary users; it weakens intended algorithm restrictions and may allow access paths that administrators believed were blocked.

How to fix it

Upgrade OpenSSH to version 10.3 or later when available from the operating system or appliance vendor. Where vendor backports are used, install the vendor security update that explicitly fixes this issue rather than relying only on the upstream version string. Until patched, review sshd_config and included configuration fragments for PubkeyAcceptedAlgorithms and HostbasedAcceptedAlgorithms entries containing ECDSA algorithms. If strict algorithm control is required, consider temporarily removing ECDSA entries from those directives and relying on non-ECDSA algorithms approved by policy, after validating compatibility with clients and automation. Restart or reload sshd only after testing configuration syntax with sshd -t to avoid locking out administrators.

How to confirm the fix worked

Confirm the installed OpenSSH package is 10.3 or later, or that the platform vendor documents a backported fix for this CVE. Check effective SSH daemon configuration using sshd -T and review PubkeyAcceptedAlgorithms and HostbasedAcceptedAlgorithms for ECDSA entries. Validate behavior from a test client by attempting authentication with ECDSA algorithms that policy intends to disallow; a fixed or mitigated server should reject those algorithms. Also verify that configuration-management baselines and host hardening profiles no longer depend on vulnerable ECDSA allow-list behavior.

Typical attack path

1. Locate SSH services running OpenSSH before 10.3.
2. Determine, infer, or test whether ECDSA algorithms are permitted in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms.
3. Prepare an authentication attempt using an ECDSA algorithm that should have been disallowed by local policy.
4. Authenticate using valid user-key or host-based credentials over the unintended ECDSA algorithm.
5. Use the resulting SSH session to perform actions allowed to that authenticated identity.

How to detect it

This weakness is difficult to confirm retrospectively because standard OpenSSH authentication logs usually record successful or failed public-key authentication but not always the exact public-key signature algorithm that was negotiated. Review sshd logs such as /var/log/auth.log, /var/log/secure, journald sshd units, and centralized SIEM records for successful public-key or host-based logins from unusual source IPs, unusual accounts, unusual times, or systems where ECDSA algorithms were intended to be prohibited. If verbose SSH logging was enabled, search for authentication events involving ECDSA keys or algorithms that are not approved by policy. Correlate any suspicious SSH sessions with shell history, sudo logs, process execution telemetry, file modification times, and network connections after login. For exposure detection, search SSH daemon configuration files and configuration-management repositories for PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms directives containing ECDSA algorithm names on hosts running OpenSSH before 10.3.

What your security team should do

• Inventory externally and internally reachable SSH services and identify OpenSSH versions before 10.3.
• Prioritize systems where SSH cryptographic algorithm restrictions are required for compliance, privileged administration, production access, or sensitive environments.
• Apply vendor OpenSSH updates that fix the issue, or upgrade to OpenSSH 10.3 or later.
• Audit sshd_config and included configuration files for PubkeyAcceptedAlgorithms and HostbasedAcceptedAlgorithms containing ECDSA entries.
• Where patching is delayed, remove or tighten ECDSA algorithm use in SSH authentication policy after compatibility testing.
• Enable more detailed SSH authentication logging temporarily on high-risk systems if investigation or validation is needed.
• Review recent successful SSH logins for unexpected users, sources, or host-based authentication patterns, recognizing that default logs may not record the negotiated public-key algorithm.