OpenSSH 10.3 Fixes Shell Injection and Multiple SSH Security Issues

The OpenSSH project released version 10.3 and 10.3p1 on April 2, 2026, addressing a shell injection vulnerability and introducing several security-hardening changes that administrators should review before upgrading.

The most notable security fix targets a shell injection vulnerability in the -J (ProxyJump) command-line option. Prior to this release, user and host names passed via -J or -oProxyJump="..." on the command line were not validated, creating an opportunity for shell injection if those values were directly sourced from adversarial input.

The flaw was reported by a researcher identified as “rabbit.” OpenSSH developers note that exposing these options to untrusted input “would have been a terrible idea to begin with,” but the fix ensures that malicious or malformed values are now rejected at the validation stage. Importantly, this validation applies only to command-line usage configuration file entries remain unvalidated.

A subtle but potentially risky behavior in sshd certificate handling has also been corrected. Previously, SSH certificates issued with an empty principals section were treated as a wildcard, effectively allowing authentication as any user who trusted the issuing Certificate Authority (CA) via authorized_keys.

This behavior was intentional by design, but created a dangerous edge case: if a CA accidentally issued a certificate with no principals defined, it could be exploited for broad unauthorized access.

OpenSSH 10.3 Release

OpenSSH 10.3 changes this behavior so that an empty principals section never matches any principal, eliminating the accidental wildcard risk.

Additionally, wildcard characters in certificate principals are now consistently enforced and supported for host certificates but explicitly not supported for user certificates, bringing clearer and more predictable access controls.

OpenSSH has also dropped backward compatibility for SSH implementations that do not support transport-layer rekeying. Any legacy SSH client or server that cannot handle rekeying will now eventually fail when interoperating with OpenSSH once the transport requires a rekey.

This change tightens protocol compliance and removes a longstanding workaround that could weaken security guarantees in long-lived sessions.

Security teams running SSH infrastructure should prioritize this update, particularly in environments where ProxyJump options are constructed programmatically or sourced from user input.

The certificate principal’s behavior change may also require a review of existing CA-issued certificates to ensure none carry empty principal fields.

OpenSSH 10.3 is available for download through the official mirrors listed at openssh.com. The project continues to be a cornerstone of secure remote access infrastructure, and this release reflects ongoing efforts to close subtle but impactful security gaps.

Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.