OpenSSH 10.4: Eight Security Fixes and Post-Quantum SSH

OpenSSH 10.4 dropped on July 6 with eight security patches and something developers haven’t seen in a mainstream SSH release before: experimental post-quantum signatures. The headliner is CVE-2026-60002, a use-after-free on the SSH client side rated 9.4 CRITICAL by NIST. A malicious server can trigger it during a key re-exchange without any authentication from you. If you’re running any OpenSSH version before 10.4, upgrade now.

The Three CVEs Worth Patching Today

Not all eight fixes carry the same urgency. Three of them affect workflows that most developers run every day.

CVE-2026-60002 is the one that demands immediate action. The bug lives in the SSH client: if a server changes its host key during a key re-exchange mid-session, you hit a use-after-free condition (CWE-416). NIST scores it 9.4 CRITICAL; the OpenSSH maintainers’ own CVSS assessment puts it at 7.7 HIGH. Either way, no authentication is required, no user interaction is needed, and the attack vector is the network. A compromised or attacker-controlled SSH server can crash your client or, depending on memory layout, do worse. Researcher Zhenpeng Leo Lin discovered it.

CVE-2026-59995 and CVE-2026-59996 are paired path manipulation bugs in SFTP and SCP respectively. The SFTP one: when you run sftp server:/path . against an attacker-controlled server, the server can redirect the downloaded file to a location you didn’t intend. The SCP one: during remote-to-remote copies, a malicious intermediate server can write files one level above your target directory. Both are rated MEDIUM individually, but think about the real attack surface — CI/CD pipelines fetching build artifacts, deployment scripts pulling configs from external hosts, developers transferring files from third-party systems. The trust assumptions matter here.

The Other Five Fixes

The remaining five patches are infrastructure-level issues most developers can treat as lower urgency, unless your environment matches the conditions.

• SSHD argument truncation: internal-sftp silently dropped all command-line options beyond the ninth argument. Security-relevant flags in position 10+ were being ignored without any error.
• GSSAPI pre-auth DoS: A pre-authentication denial-of-service when GSSAPIAuthentication is enabled. Off by default, but common in enterprise environments with Active Directory.
• Brute-force delay gap: Minimum authentication delays weren’t being enforced across all code paths. The fix tightens those enforcement points, reported by Orange Cyberdefense Vulnerability Team.
• DisableForwarding bypass: DisableForwarding=yes failed to override PermitTunnel=yes. Tunnel forwarding happened even when explicitly prohibited.
• SSH agent username cap: The agent now enforces a length limit on usernames to prevent local denial of service.

Three Breaking Changes to Check Before You Upgrade

OpenSSH 10.4 ships three backward-incompatible changes. None should block upgrading, but they can break automation if you’re not prepared.

• sshd -G now outputs directives in mixed case (PubkeyAuthentication, not pubkeyauthentication). Scripts parsing that output will break.
• Linux seccomp sandbox initialization failures are now fatal rather than silent warnings. If your environment was degrading gracefully, it will now crash.
• Non-key-exchange messages during post-authentication rekeying now trigger disconnection. This is the correct behavior; if anything relied on the old buffering behavior, it will disconnect instead.

How to Upgrade to OpenSSH 10.4

# Check what you're running
ssh -V

# Ubuntu / Debian
sudo apt update && sudo apt upgrade openssh-client openssh-server

# RHEL, AlmaLinux, Rocky Linux (Red Hat issued RHSA-2026:13381)
sudo dnf update openssh openssh-clients openssh-server

# macOS via Homebrew (Apple's built-in SSH lags behind)
brew update && brew upgrade openssh

# Confirm you're on 10.4p1
ssh -V

If your distro hasn’t packaged 10.4 yet, the source tarball is available on the OpenSSH mirrors. Red Hat enterprise users should apply RHSA-2026:13381.

Post-Quantum SSH Is Here—Experimentally

The genuinely new part of this release is experimental support for a composite post-quantum signature scheme that pairs ML-DSA 44 with Ed25519. ML-DSA 44 is NIST’s standardized post-quantum signature algorithm (FIPS 204). Combining it with Ed25519 gives you defense in depth: if quantum computers break classical elliptic curve crypto, ML-DSA covers you. If ML-DSA has an undiscovered flaw, Ed25519 holds.

To generate a key and explore what you’re working with:

ssh-keygen -t mldsa44-ed25519

To enable it on a test server (lab environments only for now):

HostKeyAlgorithms +mldsa44-ed25519@openssh.com
PubkeyAcceptedAlgorithms +mldsa44-ed25519@openssh.com

Do not deploy this in production yet. The implementation follows draft-miller-sshm-mldsa44-ed25519-composite-sigs, an IETF draft that has not been finalized. Most SSH clients, jump hosts, and CI runners will reject the 1,344-byte composite key. This is the right time to start experimenting in a lab, not the right time to push it to your fleet.

The larger point: “harvest now, decrypt later” attacks — where threat actors collect encrypted SSH sessions today to decrypt once quantum computers mature — are already happening at the nation-state level. The fact that OpenSSH is shipping a PQ option signals the maintainers take the timeline seriously. CVE-2026-59995 and today’s sftp fixes are table stakes; the post-quantum track is where the long game is being played. Start auditing which systems in your infrastructure would need new key types, and in what order. The transition will not be a weekend upgrade.