CVE-2025-61984 Explained: The OpenSSH ProxyCommand Injection Vulnerability

A newline hidden inside a username is enough to turn a routine git clone into arbitrary code execution on the developer's own machine. CVE-2025-61984 shows how a narrow, one-character gap left behind by an earlier OpenSSH fix can still be widened into a working exploit chain. The flaw sits at the intersection of shell parsing quirks, SSH's token expansion, and version-control tooling, three components that were never designed with each other's edge cases in mind. This post breaks down exactly how the bug works, who it affects, and how to close it.

Overview

Field	Details
Vulnerability Name	OpenSSH ProxyCommand Control-Character Injection
CVE ID	CVE-2025-61984
Severity (CVSS Score)	CVSS v3.1: 3.6 (Low)  Vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N CVSS v2: 4.3 (Medium)
Affected Products / Versions	OpenSSH client, all versions prior to 10.1. The gap traces back to an incomplete fix for CVE-2023-51385, which blocked shell metacharacters in usernames but not control characters.
Discovered By	David Leadbeater, independent security researcher
Published Date	October 6, 2025

OpenSSH's ssh_config supports a ProxyCommand directive that tells the client to run an external command to reach the target host instead of connecting directly. That command string supports token expansion, and %r is expanded to the remote username at connection time.

The resulting string is executed using the shell's exec builtin, specifically so no lingering shell process is left behind once the proxy program takes over the connection.

The trouble is where that username comes from. In several real-world setups, particularly SSH connections initiated on behalf of a version-control client during a recursive submodule fetch, the "username" portion of the connection string is attacker-controlled, since it is read out of a repository's own configuration rather than typed by the victim.

CVE-2023-51385 already demonstrated that an attacker could inject shell metacharacters through this path to achieve code execution, and OpenSSH 9.6 responded by rejecting a defined set of dangerous characters, including quotes, parentheses, semicolons, and backticks, from usernames supplied through the command line or config expansion.

CVE-2025-61984 shows that this filter, implemented in the valid_ruser() function in ssh.c, never accounted for raw control characters such as the newline byte.

Technical Root Cause

Because the proxy command is invoked with exec, a naive assumption might be that nothing after the intended command line can ever run, since exec replaces the current shell process outright. That assumption holds only if the entire proxy command stays on a single line.

A newline character smuggled into the username expansion splits the generated command into two lines before the shell ever sees it. The first line, containing the exec invocation, is what the shell attempts to run; the second line is ordinarily unreachable, because a successful exec never returns control to the shell.

The exploit hinges on preventing that first line from succeeding, without triggering a fatal shell error that would abort execution entirely. Bash, fish, csh, and tcsh all have documented cases where a syntax error confined to a single command does not kill the shell script; parsing simply resumes on the next line, similar in spirit to legacy "resume next" error handling.

In Bash specifically, an invalid arithmetic expansion, such as an expression missing an operand inside $[ ], produces exactly this kind of recoverable syntax error. Neither $ nor [ appear in the character blocklist added for CVE-2023-51385, so they pass through unfiltered.

The result: the crafted exec line fails to parse cleanly, execution falls through to the second line, and that second line, entirely under attacker control, runs as an ordinary shell command.

Zsh is a notable exception. Its documented behavior treats the same class of parsing failure as fatal, aborting the script rather than continuing to the next line, which is why the technique does not reproduce there.

That said, Zsh's own manual describes this strict-abort behavior as a deliberate departure from older, more permissive versions, underscoring how much of this vulnerability class depends on shell-specific error recovery semantics rather than anything unique to OpenSSH itself.

The most realistic exploitation path runs through recursive repository cloning. A malicious repository can define a submodule whose remote URL embeds a crafted "username" containing a newline, a deliberately malformed expression, and an attacker's command, followed by the real target host.

When a victim clones that repository recursively, and their local SSH configuration happens to route the submodule's host through a ProxyCommand that expands %r without quoting it, the client silently builds and executes the poisoned command line during what looks like an ordinary clone operation. No unusual prompts, warnings, or user interaction are required beyond the clone itself.

Exploit Maturity Assessment

Attribute	Assessment
Exploit Status	PoC Available
Exploit Availability	Public, published by the discovering researcher alongside the technical write-up
Exploit Reliability	Medium. Reliable across Bash, fish, csh, and tcsh, but does not function in Zsh, and depends entirely on the victim having a ProxyCommand configuration that expands %r without single-quoting it.

Proof of Concept

Publicly Available: Yes

Purpose: Demonstrate that a control character embedded in a username expanded via %r can fracture the exec line OpenSSH builds for ProxyCommand, allowing a second, attacker-supplied line to run in its place.

Prerequisites: A victim running OpenSSH client prior to 10.1, a local SSH configuration containing a ProxyCommand directive that expands %r without quoting, and a login shell that continues past the specific class of syntax error described above.

Expected Outcome: Arbitrary command execution on the victim's client machine, running with the privileges of the user who initiated the SSH connection, typically surfacing during what appears to be a routine recursive repository clone.

The underlying shell behavior driving this is a recoverable syntax error: an invalid arithmetic expansion causes the exec line to fail parsing without terminating the shell, so execution continues on to the next line rather than stopping. In a real attack chain, that first line corresponds to the proxy command OpenSSH generated by substituting the malicious username into ProxyCommand, and the second line is the attacker's payload, disguised as a plausible continuation such as a hostname reference.

PoC Reproducibility

Can a PoC be built from available information? Yes.

Required tools and dependencies: a vulnerable OpenSSH client build (prior to 10.1), a Bash, fish, csh, or tcsh login shell, and an SSH client configuration file containing an unquoted %r expansion inside a ProxyCommand directive.

High-level execution steps:

1. Prepare a repository whose submodule configuration specifies a remote URL where the username portion contains a newline, a deliberately malformed shell expression, and the attacker's intended command, followed by the actual target hostname.
2. Ensure the target's SSH configuration has a host pattern matching that hostname, routed through a ProxyCommand that expands %r unquoted.
3. Have the victim perform a recursive clone of the repository, which triggers the submodule fetch and the corresponding SSH connection attempt.
4. During token expansion, the crafted username is substituted directly into the generated exec command line.
5. The deliberately malformed expression forces a non-fatal syntax error in the victim's shell, and execution falls through to the injected line, running the attacker's command with the victim's privileges.

Time-to-Exploit Analysis

Interval	Duration
Disclosure to PoC Release	Same day. The PoC was published alongside the initial technical disclosure on October 6-7, 2025.
Disclosure to Active Exploitation	Not available. No public evidence of in-the-wild exploitation has been reported.
Patch to Exploit in Wild	Not available. No public evidence of in-the-wild exploitation has been reported.

Risk Interpretation: Immediate (0-2 days) for PoC availability following disclosure. No data currently supports a risk interpretation for active exploitation.

Active Exploitation and Threat Actors

Exploitation Observed in the Wild: No known evidence at the time of writing. No threat actors, campaigns, target sectors, or geographic patterns have been publicly attributed to this CVE.

Given the CVSS base score of 3.6, the specific victim-side configuration required, and the shell-dependent nature of the technique, this vulnerability is a poor candidate for opportunistic, mass-scale exploitation, and more plausible as a targeted supply-chain style technique against organizations known to rely on the affected configuration pattern.

Vulnerability Timeline

Event	Date
Vendor Notified	Not publicly disclosed
Public Disclosure	October 6, 2025
PoC Released	October 7, 2025
Exploitation in Wild Began	Not observed
Patch Released	OpenSSH 10.1 (October 2025)

Patch and Mitigation

Patch Available: Yes, in OpenSSH 10.1p1.

The upstream fix adds a single iscntrl() check inside valid_ruser() in ssh.c, rejecting any username containing a byte in the control-character range (0x00 through 0x1F, and 0x7F) before it can ever reach the ProxyCommand expansion. This closes the exact gap left open by the 9.6 metacharacter blocklist, which enumerated specific printable characters but never accounted for control bytes.

Mitigation steps where immediate patching is not possible:

• Single-quote every %r token used inside ProxyCommand directives. Double-quoting is not sufficient, since the malformed expression that triggers the parsing failure still executes inside double quotes.
• Avoid constructing SSH command lines, hostnames, or usernames from untrusted or externally-supplied input of any kind.
• Restrict SSH-based recursive submodule fetching so it requires explicit user action rather than running automatically and unattended, particularly in CI and build environments.
• Review and disable any custom SSH URL handlers that pass raw, unsanitized username strings through to the SSH client without validation.

Detection tips:

• Audit SSH client configuration files across the fleet for ProxyCommand entries that expand %r without surrounding single quotes.
• Scan repository configuration files for unusually long, multi-line, or control-character-laden values in username or URL fields.
• Watch for SSH client processes spawning unexpected child processes immediately after invocation, which is the process-tree signature of successful exploitation.

Indicators of Compromise

IOCs Available: No. This is a client-side logic flaw dependent entirely on local configuration state rather than a payload delivered over the network, so there is no standardized set of IP addresses, domains, or file hashes associated with it. The most reliable indicator is behavioral: an SSH process spawning an unplanned child process during a repository clone operation.

Post-Exploitation Details

Category	Assessment
Privilege Escalation	No. Any injected command executes with the same privileges as the user who initiated the SSH connection; the flaw does not itself grant elevated rights.
Lateral Movement	Not documented in the wild. Theoretically possible depending on the attacker's payload and the victim's network position, but no real-world instance has been reported.
Persistence Mechanisms	Not available. No persistence technique has been documented for this specific vulnerability.
Data Exfiltration	Possible, not observed. Since arbitrary command execution is achievable, an attacker payload could in theory attempt exfiltration, but no documented incident demonstrates this.

MITRE ATT&CK Mapping

Tactic	Technique	ID
Initial Access	Supply Chain Compromise: Compromise Software Dependencies and Development Tools	T1195.001
Execution	Command and Scripting Interpreter: Unix Shell	T1059.004
Execution	User Execution: Malicious File	T1204.002
Privilege Escalation	Not applicable. No privilege escalation is achieved by this vulnerability.	-
Persistence	Not applicable. No persistence technique is documented for this vulnerability.	-
Command and Control	Not applicable. No C2 channel is inherent to this vulnerability; any such activity would depend entirely on the attacker's chosen payload.	-

Vulnerability Chaining Opportunities

Can this be chained with other issues? Yes.

Related CVEs: CVE-2023-51385, the original OpenSSH ProxyCommand username-injection issue. CVE-2025-61984 exists specifically because the metacharacter filtering introduced to fix that earlier CVE never accounted for control characters, making this less a new attack surface and more a bypass of a prior remediation.

Misconfigurations that increase exposure:

• SSH client configurations that expand %r inside ProxyCommand without single-quoting the token.
• Internally built tooling that auto-generates SSH configuration fragments referencing %r, which can silently propagate the unsafe pattern across an entire fleet of developer machines or build agents.

Example attack chain: An attacker publishes a repository containing a submodule reference where the username field embeds a newline, a deliberately malformed shell expression, and a payload command, followed by the real target host.

A victim performs a recursive clone. Their SSH configuration matches the malicious host and expands the crafted username into the ProxyCommand exec line.

The malformed expression forces a recoverable shell syntax error. Execution falls through to the injected line. The attacker's command runs on the victim's machine with the victim's own privileges.

Detection and Monitoring

• Log sources: SSH client debug and verbose connection logs, shell history, EDR process-tree telemetry, and configuration management change logs.
• Behavioral indicators: An SSH client process spawning an unexpected child process immediately following invocation; configuration files containing multi-line or control-character-laden username or URL fields.
• Search guidance: Query source repositories and configuration management systems for the pattern of a ProxyCommand directive that expands %r without surrounding single quotes.
• EDR detections: Alert on anomalous parent-child process relationships where an SSH client unexpectedly spawns shell commands outside the connection it was expected to establish.

Risk Assessment

Factor	Assessment
Impact	Low to Moderate. Successful exploitation results in arbitrary command execution on the client, but only within the reach of a victim-side configuration that must already be in place.
Likelihood	Low. Requires a non-default ProxyCommand setup with an unquoted %r token and a shell exhibiting the continue-past-error behavior described above.
Exploit Maturity Influence	A working, publicly documented PoC raises practical feasibility for a targeted, supply-chain-style attack even though the formal CVSS score is Low.
Overall Risk Level	Low to Medium, and heavily dependent on the specific SSH configuration in use.

Remediation Recommendations

Immediate actions:

• Upgrade OpenSSH clients to 10.1p1 or later across all endpoints, build agents, and CI/CD runners.
• Where an immediate upgrade is not possible, single-quote every %r token in existing ProxyCommand directives as a stopgap.

Long-term fixes:

• Restrict SSH-based recursive submodule fetching so it cannot execute unattended without explicit user confirmation, particularly in automated build pipelines.
• Audit any internally maintained tooling that auto-generates SSH configuration fragments for unquoted token expansions before they propagate fleet-wide.

Security best practices:

• Never construct SSH command lines, usernames, or hostnames from untrusted or externally-supplied input.
• Incorporate a periodic review of SSH client configurations across the environment into standard configuration hygiene, specifically checking for risky ProxyCommand patterns.