researcher David Leadbeater has disclosed a in OpenSSH, identified as CVE-2025-61984, which highlights how even minor quirks in command-line parsing and shell behavior can open doors to remote code execution.
CVE-2025-61984 — a affecting OpenSSH before version 10.1, where control characters in usernames originating from untrusted sources could be mishandled by the ProxyCommand directive, potentially allowing command injection or remote code execution under certain configurations.
Leadbeater’s latest finding builds upon lessons from a previous OpenSSH , CVE-2023-51385, which involved similar misuse of control sequences. In this new case, the issue revolves around OpenSSH allowing control characters in usernames sourced from the command line or the %-sequence expansion in configuration files.
As the CVE description states:
“ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used.”
This behavior matters because when the username variable (%r) is passed to a ProxyCommand, OpenSSH builds an exec command string executed via the user’s shell. If that string contains newline characters or malformed shell expressions, certain shells interpret them in ways that lead to unintended command execution.
OpenSSH’s documentation notes that ProxyCommand lines are “executed using the user’s shell ‘exec’ directive to avoid a lingering shell process.” In practice, this means the constructed command is executed as:
which is normally safe — but the problem arises from how different shells react to syntax errors or control characters.
Leadbeater demonstrates that while OpenSSH properly filters many metacharacters (‘, “, ;, &, |, (), {}), it fails to disallow $ and [, two symbols that shells treat specially for arithmetic evaluation. This subtle omission creates a surprising parsing quirk.
“Bash supports square brackets for arithmetical expressions, i.e. $[1+1] expands to 2. However if there’s a syntax error in the expression, it gives an error — but continues to the next line.”
This behavior can be exploited by inserting a malicious username containing $[ and a newline (n), causing the exec line to fail but continue executing whatever follows — such as a second command injected by the attacker.
Leadbeater writes:
“Looking back at the list of characters in the strchr call, we see that $ and [ aren’t filtered, so we can force the exec line to fail and run a command after that, without needing any other shell metacharacters.”
In practical terms, exploitation requires a specific setup — particularly ProxyCommand configurations using %r, which substitutes the remote username into the command string. This is commonly found in Git submodules or SSH configurations generated by third-party tools such as Teleport.
For instance, a malicious .gitmodules file might include a URL like:
[submodule "foo"]
path = foo
url = "$[+]nsource [email protected]:foo"When combined with an SSH config containing:
