The OpenSSH project released version 10.4, also tagged 10.4p1, on July 6, 2026, introducing stricter transport protocol enforcement along with configuration changes that administrators should review before upgrading production systems.
The release is available from the official mirror and continues OpenSSH’s position as a complete implementation of SSH protocol 2.0, including full SFTP client and server support.
The most significant change addresses a protocol-level weakness in how ssh(1) and sshd(8) handle post-authentication key re-exchange. Previously, a malicious peer could send non-KEX messages during this phase without penalty, and they would simply be buffered on the receiving side.
OpenSSH 10.4 Released With Security Fixes
Over time, this could waste significant memory, continuing until the connection terminated or the server or client hit an internal memory limit, effectively creating a resource-exhaustion vector.
With OpenSSH 10.4, both client and server now enforce stricter compliance with RFC 4253 Section 7.1, disconnecting any peer that sends non-key-exchange messages during a key re-exchange event.
Implementations that fail to properly restrict message types during key exchange, in violation of the RFC, now risk being disconnected by updated OpenSSH installations.
Security researcher Marko Jevtic is credited with reporting the underlying issue that prompted this fix. Beyond transport protocol hardening, this release introduces changes that could subtly affect existing deployments.
The sshd -G configuration dump mode now outputs directives in mixed case, such as “PubkeyAuthentication,” rather than the all-lowercase format used earlier, which may disrupt scripts or automation pipelines that parse this output.
Separately, on Linux systems running with the seccomp sandbox enabled, any failure to enable SECCOMP or NO_NEW_PRIVS is now treated as a fatal error rather than being logged as a warning and allowing the daemon to continue running.
Systems lacking support for these kernel features must now explicitly disable the sandbox at configure time instead of relying on the previous graceful fallback.
OpenSSH release notes do not assign a CVE identifier to the transport protocol fix; it closes a denial-of-service class vulnerability that could be exploited by malicious or misbehaving peers against both SSH clients and servers.
This reflects OpenSSH’s continued pattern of narrowing protocol-level assumptions to eliminate subtle abuse vectors. The seccomp enforcement change is especially relevant for hardened Linux environments, since it converts previously silent failures into hard stops.
Security teams should test the new mixed-case configuration output against existing automation before deploying sshd -G in production, and confirm that seccomp and NO_NEW_PRIVS are supported on Linux hosts prior to upgrading, particularly on older kernels or in containerized environments.
Auditing third-party SSH implementations for compliance with RFC 4253 Section 7.1 is also advisable, since non-compliant peers may begin experiencing unexpected disconnections.
Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.
