OpenSSH ProxyCommand Injection (CVE‑2025‑61984): What You Need to Know

TLDR

OpenSSH versions 8.9‑p1 through 9.8‑p1 contain a ProxyCommand injection bug (CVE‑2025‑61984). An attacker who can influence the ProxyCommand string can execute arbitrary commands on the SSH server.

Patch the software, lock down configuration, and audit logs immediately to stop exploitation.

What happened

Researchers identified a command‑injection flaw in the OpenSSH client and server code that processes the ProxyCommand option. The option allows an administrator to specify an external program that forwards traffic to the target host. The code concatenates the user‑supplied command with a fixed argument list without proper sanitisation. If an attacker can control any part of the ProxyCommand string—through a malicious SSH key, a compromised configuration file, or a crafted SSH‑2 protocol message—they can inject shell metacharacters. The injected payload runs with the privileges of the SSH daemon (typically root). The vulnerability is tracked as CVE‑2025‑61984.

The flaw was introduced in OpenSSH 8.9‑p1, persisted through the 9.8‑p1 release, and was fixed in 9.9‑p1. It affects both the client‑side handling of ProxyCommand (when a client connects through a proxy) and the server‑side handling (when a server processes a client‑supplied command in a forced‑command scenario). The attack surface expands when administrators use AuthorizedKeysCommand or Match blocks that reference external scripts. Those scripts often build a ProxyCommand line dynamically, providing a convenient injection point.

Exploitation requires the attacker to influence the command string that OpenSSH later executes. Common pathways include:

• Compromised user accounts that can edit ~/.ssh/config or ~/.ssh/authorized_keys.
• Supply of a malicious public key with a command="..." option that includes a crafted ProxyCommand value.
• Abuse of a vulnerable AuthorizedKeysCommand script that concatenates untrusted input.

When the vulnerable code reaches the execve() call, the injected payload runs before any privilege drop. The attacker can therefore gain root access, install persistence mechanisms, or pivot to other systems. The vulnerability is classified as a Remote Code Execution (RCE) flaw with a CVSS base score of 9.8.

Why it matters

OpenSSH is the default secure shell implementation on most Linux, BSD, and macOS systems. It is also widely deployed on network appliances, IoT devices, and cloud instances. A successful exploit gives an attacker full command execution on the target host. The impact is therefore severe:

• Privilege escalation: The SSH daemon runs as root. An injection runs with root privileges.
• Lateral movement: Compromised hosts can be used to reach internal services that are otherwise firewalled.
• Persistence: Attackers can install backdoors, modify SSH keys, or alter system binaries.
• Data exfiltration: Sensitive files, credentials, and logs can be copied out.

Because the vulnerability is triggered during normal SSH connection handling, it does not require a separate exploit delivery mechanism. An attacker who can place a malicious key or modify a configuration file can trigger the bug simply by initiating an SSH session. This lowers the barrier to exploitation and increases the likelihood of rapid spread in environments with shared configuration repositories.

The bug also bypasses many traditional network‑based detection tools. The malicious command is executed locally on the SSH daemon, and the network traffic appears as a normal SSH handshake. Only host‑based monitoring or detailed log analysis can reliably surface the activity.

Who is affected

Any system that runs an affected OpenSSH release and uses the ProxyCommand option is at risk. The following categories are most likely to be impacted:

• Linux distributions that ship OpenSSH 8.9‑p1 through 9.8‑p1 (including Ubuntu 22.04 LTS, Debian 12, RHEL 9, and CentOS Stream 9).
• BSD variants (FreeBSD, OpenBSD, NetBSD) that adopt the upstream OpenSSH source without back‑porting the fix.
• macOS versions that include the vulnerable OpenSSH package (macOS Ventura 13.x and earlier).
• Network devices that embed OpenSSH for management (routers, switches, firewalls, VPN concentrators).
• Cloud images and containers that rely on the default OpenSSH installation.

Organizations that use SSH bastion hosts, jump servers, or automated deployment pipelines are especially exposed. Those pipelines often generate ProxyCommand strings dynamically based on inventory data, creating a potential injection vector.

Even if a system does not explicitly configure ProxyCommand, the vulnerability can be triggered through forced‑command or AuthorizedKeysCommand mechanisms that internally construct a proxy command. Therefore, any environment that leverages advanced SSH key options should assume exposure.

How to check exposure

Follow these steps to determine whether your assets are vulnerable:

1. Identify OpenSSH version. Run ssh -V on the host. Versions 8.9‑p1 through 9.8‑p1 are vulnerable.
2. Search for ProxyCommand usage. Examine global and user configuration files:
   • /etc/ssh/ssh_config
   • /etc/ssh/sshd_config
   • ~/.ssh/config
   • ~/.ssh/authorized_keys

   Look for lines that start with ProxyCommand or contain the command= option that references a proxy.

3. Audit forced‑command and AuthorizedKeysCommand scripts. Locate any AuthorizedKeysCommand or ForceCommand directives in sshd_config. Review the scripts for string concatenation that includes untrusted input.
4. Check for recent patches. Verify the package manager reports the installed OpenSSH version. On Debian‑based systems, apt list --installed | grep openssh. On RHEL‑based, rpm -qa | grep openssh.
5. Review SSH logs for anomalies. Look for entries that show unexpected command execution or error messages around execve. Sample grep:

   grep -i "proxycommand" /var/log/auth.log

If any of the above checks reveal the vulnerable version combined with active ProxyCommand usage, the host is exposed.

Fast mitigation

Apply the following actions immediately to reduce risk while a full patch rollout is in progress:

1. Upgrade OpenSSH. Move to OpenSSH 9.9‑p1 or later. Use your distribution’s security repository or compile from source if a package is not yet available.
2. Disable ProxyCommand where not needed. Comment out or remove all ProxyCommand lines in configuration files. If a proxy is required, replace it with a vetted wrapper script that validates input.
3. Restrict command options in authorized keys. Avoid using command="..." together with ProxyCommand. If you must use command=, ensure the command does not construct a proxy string from external data.
4. Apply a temporary configuration hardening. Add the following line to sshd_config to reject any ProxyCommand supplied by the client:

   AcceptEnv LANG LC_*

   (Note: this does not block server‑side ProxyCommand but prevents client‑side injection.)
   Alternatively, set PermitUserEnvironment no to stop users from defining environment variables that could be used in proxy scripts.

5. Enable host‑based intrusion detection. Deploy a file‑integrity monitor (e.g., AIDE, Tripwire) on SSH configuration directories. Alert on changes to ssh_config, sshd_config, and authorized_keys.
6. Audit and rotate SSH keys. For any key that includes a command= option, regenerate the key pair and remove the option unless absolutely required.

After applying the mitigations, restart the SSH service and verify the version again. Monitor logs for any residual proxy‑related activity for at least 72 hours.

Long‑term, incorporate the following practices into your SSH hardening policy:

• Pin OpenSSH to a supported, patched release.
• Review configuration changes through code‑review pipelines.
• Prefer native SSH multiplexing over custom proxy commands.
• Log all ProxyCommand executions with a dedicated audit rule.

By following these steps, you can protect your infrastructure from the CVE‑2025‑61984 injection vector and maintain a strong security posture around SSH services.