OpenSSH 10.3 fixes shell injection issue and tightens certificate handling
4 min. read 
Published on
OpenSSH 10.3 and 10.3p1 are now out, and the release includes a fix for a shell injection issue in the ssh client plus several security-related behavior changes that admins should review before upgrading. The project published the release on April 2, 2026, through its official mirrors.
The headline fix is not a general OpenSSH remote code execution flaw, and it is not limited to ProxyJump alone. OpenSSH says the risk appears when an ssh command line is built using usernames or URIs from an untrusted source and a ProxyCommand that uses %r expansion is configured. In that case, an attacker may be able to inject shell expressions that run when the proxy command starts.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
OpenSSH also makes its stance clear in the release notes. The developers strongly recommend against using untrusted input to construct ssh command lines in the first place. The new release adds validation for command-line supplied values, while usernames supplied as trusted literals in configuration files are treated differently.
The security changes go beyond the shell injection fix
Another important change affects certificate principals. Before this release, sshd could treat a certificate with an empty principals section as matching any principal when used through the authorized_keys principals="" option. OpenSSH says that behavior was intentional, but also surprising and potentially risky because a CA that accidentally issued such a certificate could create a far more powerful credential than expected.
OpenSSH 10.3 changes that behavior. A certificate with an empty principals section now matches no principal at all. The project also says wildcard handling in certificate principals now works consistently for host certificates and is not supported for user certificates.
The release also removes compatibility code for older SSH implementations that do not support transport-layer rekeying. OpenSSH says those implementations will now eventually fail once the transport needs rekeying, which could affect older or non-standard clients and servers in long-lived sessions.
Why this OpenSSH update matters for admins
Admins should pay close attention if they generate ssh commands programmatically. The shell injection fix matters most in setups where usernames, hosts, or URIs come from user-controlled input and get passed into ssh with proxy-related options. That kind of workflow already carried risk, but OpenSSH 10.3 now hardens the client against one such unsafe pattern.
Certificate-based environments also need a second look. Teams that rely on trusted CAs for SSH access should review whether any workflows assumed empty principals behaved like a wildcard, because that no longer applies in OpenSSH 10.3. The new behavior is safer, but it may expose brittle legacy assumptions.
The rekeying change may cause the most operational surprises. Environments that still talk to older SSH software could see connections fail after rekeying becomes necessary, so it makes sense to test older clients, appliances, and embedded systems before broad rollout.
What changed in OpenSSH 10.3
| Change | What it means |
|---|---|
Shell injection fix in ssh(1) | Hardens command-line handling when untrusted usernames or URIs interact with ProxyCommand and %r expansion |
| Empty certificate principals no longer match anything | Prevents accidental wildcard-style authentication from empty principals sections |
| Wildcards clarified for certificate principals | Supported for host certificates, not supported for user certificates |
| Legacy non-rekeying compatibility removed | Older SSH implementations may fail once rekeying becomes necessary |
What admins should do next
- Review any scripts or tools that build
sshcommand lines from external input. - Check whether any
ProxyCommandsetup uses%rexpansion with user-controlled values. - Audit certificate-based SSH access for assumptions around empty principals.
- Test older clients and servers for rekeying support before rolling out 10.3 widely.
- Update from official OpenSSH mirrors only.
FAQ
No. The official release notes describe a client-side shell injection risk tied to unsafe construction of ssh command lines using untrusted input and a ProxyCommand that uses %r.
Not exactly. Some early summaries framed it around -J or ProxyJump, but the OpenSSH release notes specifically describe the dangerous case as one involving untrusted usernames or URIs plus a ProxyCommand that uses %r expansion.
It can. OpenSSH removed compatibility for implementations that do not support rekeying, and those connections will now fail once rekeying becomes necessary.
Because an empty principals section used to behave like a wildcard in one path, which could create broader access than intended if a CA made a mistake. OpenSSH 10.3 now treats empty principals as matching nothing.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages