# GHSA-p4h8-56qp-hpgv: SSH/SCP option injection allowing local RCE in @aiondadotcom/mcp-ssh

> An attacker can achieve local remote code execution and read sensitive files by injecting SSH options via prompt injection into the MCP server's LLM.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 14 Apr 2026

## What is GHSA-p4h8-56qp-hpgv?

GHSA-p4h8-56qp-hpgv is a command injection vulnerability in @aiondadotcom/mcp-ssh, published on 14 Apr 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.

### Official description

## Impact

A crafted `hostAlias` argument such as `-oProxyCommand=...` was passed to `ssh`/`scp` without an argument terminator. SSH interprets arguments starting with `-` as options regardless of position, so the option-injection caused SSH to execute the attacker-supplied `ProxyCommand` **locally** on the machine running the MCP server — before any network connection. This bypassed the documented protection of `# @password:` annotations and exposed local SSH keys, browser cookies, other MCP server credentials, and anything else readable by the server process.

A second local-RCE vector existed on Windows: `spawn(..., { shell: true })` was used so that `ssh.exe`/`scp.exe` could be found via `PATH`. With `shell: true`, every argument is re-parsed by `cmd.exe`, so shell metacharacters (`&`, `|`, `^`, `>`, `"`, `;`, …) in `hostAlias`, `command`, `localPath` or `remotePath` would have been interpreted by `cmd.exe` and could have triggered arbitrary local command execution on Windows.

The MCP server runs locally over STDIO, but the LLM driving it is not trusted: its tool arguments can be steered by **prompt injection** from any untrusted text the LLM ingests (web pages, e-mails, repository files, output of other MCP servers). The attack does not require a malicious user — only that the LLM ingests attacker-controlled text at any point during the session.

## Patches

Fixed in **1.3.5**.

- Add `--` argument terminator to all `ssh`/`scp` invocations.
- Strict whitelist for `hostAlias` (rejects leading `-` and shell metacharacters).
- Known-host check: every `hostAlias` must be defined in `~/.ssh/config` (including `Include` directives) or present in `~/.ssh/known_hosts`.
- Resolve `ssh.exe`/`scp.exe` to absolute paths and use `shell: false` everywhere on Windows.

## Workarounds

None. Upgrade to 1.3.5.

## Credit

Reported by Pico (@piiiico) as part of an MCP server security audit.

## Which versions are affected by GHSA-p4h8-56qp-hpgv?

2 open source packages ship an affected version, including @aiondadotcom/mcp-ssh.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@aiondadotcom/mcp-ssh` | npm | All versions | 1.3.5 |
| `@aiondadotcom/mcp-ssh` | npm | All versions | 1.3.5 |

## How do I fix GHSA-p4h8-56qp-hpgv?

Upgrade @aiondadotcom/mcp-ssh to 1.3.5 or later.

## Is GHSA-p4h8-56qp-hpgv being exploited?

There is no known exploitation of GHSA-p4h8-56qp-hpgv in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-p4h8-56qp-hpgv and fix it if it is affected.

What it is: GHSA-p4h8-56qp-hpgv is a command injection vulnerability in @aiondadotcom/mcp-ssh, published on 14 Apr 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of GHSA-p4h8-56qp-hpgv in the wild and no public exploit code.

Affected packages and fixed versions:
- @aiondadotcom/mcp-ssh (npm): affected all versions; fixed in 1.3.5
- @aiondadotcom/mcp-ssh (npm): affected all versions; fixed in 1.3.5

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-p4h8-56qp-hpgv/ (Markdown: https://insights.sbomify.com/GHSA-p4h8-56qp-hpgv/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-p4h8-56qp-hpgv

---
From sbomify Insights: https://insights.sbomify.com/GHSA-p4h8-56qp-hpgv/
Summaries are generated and may contain mistakes; the official description above is the record.