OpenSSH Vulnerability Exploited Via ProxyCommand to Execute Remote Code \u2013 PoC Released
\n \t
\n
<\/BR>
\n
\n \t
\n
<\/BR><\/p>\n
A new command injection vulnerability in OpenSSH, tracked as CVE-2025-61984, has been disclosed, which could allow an attacker to achieve remote code execution on a victim\u2019s machine.<\/p>\n
The vulnerability is a bypass of a previous fix for a similar issue (CVE-2023-51385<\/a>) and exploits how the The core of the vulnerability lies in OpenSSH\u2019s failure to properly sanitize control characters, such as newlines, within usernames. An attacker can create a username that includes a newline character followed by a malicious command.<\/p>\n This username is then passed to the shell via SSH\u2019s When a shell like Bash, Fish, or csh processes the Instead, it proceeds to execute the command on the next line, which is the malicious payload supplied by the attacker. This behavior effectively bypasses security measures intended to prevent command execution, opening the door for an RCE.<\/p>\n The most practical exploitation scenario for CVE-2025-61984<\/a> involves a malicious Git repository. An attacker can configure a submodule within their repository to use a URL containing the malicious, multi-line username.<\/p>\n If a victim clones this repository recursively ( The exploit requires two conditions on the victim\u2019s machine: a shell that continues execution after a syntax error (like Bash) and an SSH configuration file ( Notably, the secure shell Zsh is not vulnerable to this technique as it terminates upon encountering such errors. Tools like Teleport have been found to generate SSH configurations that use this vulnerable pattern, potentially increasing the attack surface.<\/p>\n The OpenSSH project has released a patch<\/a> in version 10.1 that fully addresses this vulnerability<\/a> by disallowing control characters in usernames. All users are strongly urged to upgrade to this version or newer.<\/p>\n For systems that cannot be immediately updated, several mitigations can be implemented.<\/p>\n Users can edit their SSH configurations to enclose the Another effective defense-in-depth measure is to configure Git to restrict the automatic use of SSH for submodules.<\/p>\n This vulnerability serves as a critical reminder of the complex security risks that can emerge from the interactions between trusted developer tools.<\/p>\n Follow us on Google News<\/a>, LinkedIn<\/a>, and X<\/a> for daily cybersecurity updates. Contact us<\/a> to feature your stories.<\/strong><\/p>\n The post OpenSSH Vulnerability Exploited Via ProxyCommand to Execute Remote Code \u2013 PoC Released<\/a> appeared first on Cyber Security News<\/a>.<\/p>\n<\/div>\nProxyCommand<\/code> feature interacts with the underlying system shell when handling specially crafted usernames.<\/p>\nProxyCommand<\/code>. While OpenSSH<\/a> filters many dangerous shell metacharacters, it does not filter characters that could force a syntax error in certain shells. <\/p>\nProxyCommand<\/code>, the crafted syntax error on the first line, the command fails, but the shell does not exit.<\/p>\nThe Git Submodule Attack Vector<\/strong><\/h2>\n
git clone --recursive<\/code>), Git will attempt to connect via SSH to fetch the submodule. This triggers the vulnerability ProxyCommand<\/code> if the user has a specific configuration.<\/p>\n~\/.ssh\/config<\/code>) with a ProxyCommand<\/code> that uses the %r<\/code> token to include the remote username.<\/p>\nMitigations<\/strong><\/h2>\n
%r<\/code> token in single quotes ('%r'<\/code>) within any ProxyCommand<\/code> directive, which prevents the shell from interpreting the special characters.<\/p>\n