CVE-2026-45695: Unauthenticated RCE in Kopia via SSH ProxyCommand Injection
TL;DR - Critical unauthenticated RCE affects Kopia servers started with
--without-password. - Vulnerable versions are prior to0.23.0; upgrade immediately. - No KEV listing confirms in-the-wild abuse yet, but public technical details make this urgent.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-45695 |
| CVSS | 9.8 |
| Attack vector | Network |
| Privileges required | None in affected passwordless deployments |
| Patch available | Yes, fixed in 0.23.0 |
CVE-2026-45695 is a critical remote code execution vulnerability in Kopia, the open-source backup tool for Windows, macOS, and Linux. The issue is exposed through Kopia’s HTTP server when it is started with the --without-password option, allowing unauthenticated access to an API path involved in repository checks.
What makes this bug especially serious is that the vulnerable workflow can pass attacker-controlled SFTP settings into an external ssh invocation. In practice, this means a remote attacker may be able to execute arbitrary commands as the user running the Kopia process. A patch is available, and defenders should treat any passwordless exposed Kopia server as high priority.
What Is This Vulnerability?
At a technical level, the vulnerability is an unsafe command invocation problem in the code path behind /api/v1/repo/exists. According to the NVD description, affected Kopia versions accept unauthenticated requests to that endpoint when the server is started in passwordless mode. The attacker can provide crafted SFTP storage configuration that gets forwarded to blob.NewStorage.
The dangerous condition arises when the submitted storage configuration causes externalSSH: true to be used alongside attacker-controlled sshArguments. If those arguments include -oProxyCommand=<cmd>, Kopia eventually invokes exec.CommandContext("ssh"), and OpenSSH processes ProxyCommand as a legitimate option. That can cause arbitrary command execution on the local system before any real SSH session is established.
In other words, this is not just a generic input validation flaw. It is specifically an injection path into an external SSH client invocation. The issue hinges on Kopia trusting user-supplied SFTP connection parameters in a server mode that does not enforce authentication.
Technical Notes
The vulnerable path, as described by the public advisory material, includes these conditions:
- Kopia HTTP server started with
--without-password - Unauthenticated access to
/api/v1/repo/exists - SFTP configuration accepted from the request
externalSSH: true- Attacker-controlled
sshArgumentsincluding-oProxyCommand=<cmd>
Conceptually, the dangerous flow looks like this:
HTTP request -> /api/v1/repo/exists
-> attacker-controlled SFTP config
-> blob.NewStorage
-> external ssh invocation
-> OpenSSH interprets -oProxyCommand=<cmd>
-> local command execution as Kopia process user
Who Is Affected?
The affected product is Kopia, and the affected version range is all versions prior to 0.23.0. The fix is explicitly stated to be in 0.23.0. If you are running 0.22.x or any earlier release, you should assume the vulnerable code is present unless you have independently verified a backport from your own package maintainer.
The exposure is configuration-dependent. This is not automatically exploitable in every Kopia deployment. The public description specifically ties exploitation to Kopia’s HTTP server running with --without-password. The server must also be reachable by an attacker, and the vulnerable API path must accept the malicious SFTP configuration.
That means the most exposed population includes:
- Internet-exposed Kopia HTTP servers
- Internal Kopia servers reachable by untrusted users or shared networks
- Deployments started with
--without-password - Setups where SFTP storage probing is available through
/api/v1/repo/exists
If you do not know whether your deployment uses --without-password, defenders should assume risk until they confirm startup flags, service definitions, or container arguments. If you do not know whether externalSSH: true is in use, you should still prioritize patching because the vulnerable path involves attacker-supplied configuration reaching SSH execution logic.
Technical Notes
Check service startup configuration for risky flags:
ps aux | grep kopia
systemctl cat kopia
docker inspect <container_name_or_id>
kubectl get pods -A -o yaml | grep -i kopia -A 20
Look specifically for:
--without-password
And, where available, review config or request-handling patterns related to SFTP and external SSH:
externalSSH: true
sshArguments
/api/v1/repo/exists
CVSS Score Breakdown
The published CVSS base score is 9.8, which places this issue in the critical range. The full vector string was not returned in the sourced NVD tool output, so it should not be restated as authoritative here. Still, the score aligns with the observed characteristics: network reachability, lack of required authentication in the affected deployment mode, and the potential for arbitrary code execution.
A score this high generally indicates a bug with low attacker friction and high impact. In this case, the confidentiality, integrity, and availability implications are all severe. An attacker who can execute commands as the Kopia process user may be able to access backup data, tamper with backup jobs, modify retention settings, pivot into connected infrastructure, or disrupt restores.
Defenders should also remember that CVSS does not capture operational context well. Even if a deployment is not internet-facing, a critical unauthenticated RCE inside a backup environment is still dangerous. Backup servers often have access to sensitive data, repositories, credentials, and administrative network paths.
Because the vector string is not available from the source material used here, the safest operational interpretation is simple: treat this as a critical remote exploit path against exposed passwordless Kopia servers, and patch with urgency.
Exploitation Status
At the time of writing, CISA KEV does not list CVE-2026-45695, which means there is no KEV-confirmed evidence of exploitation in the wild. That is an important distinction. It does not mean the vulnerability is safe to defer; it only means there is no CISA catalog confirmation of active exploitation at this time.
Public technical details are available. The NVD entry links to the upstream security advisory, patch commit, pull request, and release. In addition, third-party security coverage discussing the exploit mechanics is publicly accessible. That means defenders should assume that capable attackers can reproduce the issue even if a standalone exploit repository is not yet validated.
So the current status can be summarized as follows:
- PoC public? No independently validated standalone PoC repository was confirmed from the available sources.
- Technical details public? Yes.
- Active exploitation confirmed in the wild? No confirmed KEV evidence at this time.
- Defender assumption: Exploit development is likely feasible from public material, so exposed systems should be treated as at risk.
This is a common pattern for high-severity open-source flaws: detailed advisories and code diffs can rapidly lower the barrier for attackers. If your Kopia server is reachable and uses --without-password, patching should not wait for formal in-the-wild confirmation.
How to Detect It
Detection should focus on two things: identifying exposed vulnerable configurations and spotting suspicious requests to /api/v1/repo/exists that contain SFTP-related parameters or SSH option abuse. If you have HTTP access logs, reverse proxy logs, WAF telemetry, or EDR command execution visibility on the Kopia host, use all of them together.
The strongest host-level signal is unexpected ssh process execution by the Kopia service account, especially if command-line arguments include ProxyCommand, -oProxyCommand=, or unusual child process behavior shortly after HTTP requests hit the repository existence endpoint. Even if exploitation fails, probing may leave recognizable request artifacts.
Technical Notes
Example suspicious strings to search for in logs or telemetry:
/api/v1/repo/exists
ProxyCommand
-oProxyCommand=
externalSSH
sshArguments
Example grep-based triage on Linux web or application logs:
grep -R -Ei '(/api/v1/repo/exists|ProxyCommand|-oProxyCommand=|sshArguments|externalSSH)' /var/log
Example process hunting on Linux with auditd, EDR, or shell history equivalents:
ps -ef | grep '[s]sh'
journalctl -u kopia --since "7 days ago" | grep -Ei 'repo/exists|ssh|sftp'
Example Sigma-style detection logic concept for command-line telemetry:
title: Suspicious SSH ProxyCommand Spawned by Kopia
logsource:
product: linux
category: process_creation
detection:
selection_parent:
ParentImage|contains: 'kopia'
selection_child:
Image|endswith: '/ssh'
CommandLine|contains:
- 'ProxyCommand'
- '-oProxyCommand='
condition: selection_parent and selection_child
level: high
Example network or proxy query idea for HTTP logs:
method=* AND uri_path="/api/v1/repo/exists" AND (request_body CONTAINS "sshArguments" OR request_body CONTAINS "ProxyCommand" OR request_body CONTAINS "externalSSH")
If you do not have request-body logging, you should still alert on repeated unauthenticated access to /api/v1/repo/exists, especially from untrusted IPs or when followed by local ssh execution.
Mitigation and Patching
The primary fix is to upgrade Kopia to 0.23.0 or later. The vulnerability is explicitly fixed in 0.23.0. If you are consuming Kopia from an OS package repository, verify that the package version actually includes the upstream 0.23.0 fix and is not lagging behind the project release.
If you cannot patch immediately, the most important workaround is to stop running the server in passwordless mode. Do not use --without-password on exposed systems. Configure authentication using --server-username and --server-password, and restrict network access to the HTTP server to only trusted administrative hosts. These are risk-reduction steps, not full substitutes for patching.
You should also review whether your deployment permits repository checks that accept arbitrary SFTP parameters and whether externalSSH: true is operationally necessary. If business requirements allow, reducing or isolating this functionality can shrink the attack surface until patching is complete.
Technical Notes
Upgrade examples should be adapted to your environment, but the operational goal is the same: run Kopia 0.23.0 or newer.
Example binary verification:
kopia version
Example replacement workflow for manually managed Linux binaries:
# Verify current version
kopia version
# Download and install version 0.23.0 from the official release source
# Exact package file name varies by platform and architecture
# After installation, confirm:
kopia version
Example systemd hardening by removing --without-password and enforcing credentials:
[Service]
ExecStart=/usr/local/bin/kopia server start \
--server-username=<admin_user> \
--server-password=<strong_password>
Then reload and restart:
sudo systemctl daemon-reload
sudo systemctl restart kopia
sudo systemctl status kopia
Example immediate network restriction with a host firewall on Linux:
sudo ufw allow from <trusted_admin_ip> to any port <kopia_port>
sudo ufw deny <kopia_port>/tcp
If you do not know the exact exposure, the minimum safe short-term action is:
- Remove
--without-password - Restrict inbound access to the Kopia HTTP server
- Upgrade to
0.23.0or later - Hunt for suspicious
sshinvocations and endpoint access
References
The primary upstream and vulnerability-tracking references are clear and sufficient for defenders to validate the issue, patch status, and code changes. The NVD entry provides the canonical vulnerability description and links to the vendor-side fix material. The GitHub advisory and release references provide the practical patch source.
Because this is a fresh critical vulnerability with public technical details, defenders should rely on the upstream release and advisory as the primary source of truth for remediation. If you maintain internal vulnerability records, preserve all of the following references for change control and incident response context.
- NVD entry for CVE-2026-45695
- GitHub Security Advisory:
GHSA-2q4c-3mrw-63c3 - Fix commit:
c26c6a1b9734c5089217986ffa5cd19f8a6b8900 - Pull request:
#5354 - Kopia release:
v0.23.0 - Project site:
https://kopia.io - Source repository:
https://github.com/kopia/kopia
Direct URLs:
- https://github.com/kopia/kopia/security/advisories/GHSA-2q4c-3mrw-63c3
- https://github.com/kopia/kopia/commit/c26c6a1b9734c5089217986ffa5cd19f8a6b8900
- https://github.com/kopia/kopia/pull/5354
- https://github.com/kopia/kopia/releases/tag/v0.23.0
- https://github.com/advisories/GHSA-2q4c-3mrw-63c3
- https://orca.security/resources/blog/kopia-backup-rce-vulnerability
- https://github.com/kopia/kopia
- https://kopia.io
For most teams, the practical takeaway is straightforward: if any Kopia server is running a version prior to 0.23.0 with --without-password, assume urgent exposure and remediate immediately.
For further reading on related vulnerabilities, you may explore our articles on what is pod security admission and container image vulnerability scanning.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.