Kopia unauthenticated RCE exposes backup servers to full compromise

At a glance

What this is: This is an analysis of a critical Kopia vulnerability that enables unauthenticated remote code execution through SSH command-line argument injection in exposed backup servers.

Why it matters: It matters because backup tools often hold high-value secrets and broad data access, so one unauthenticated flaw can become both an availability event and an identity control failure across machine access paths.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Orca Security's analysis of the Kopia unauthenticated RCE flaw

Context

Kopia is a backup and restore tool, but in practice it also becomes part of the identity and access surface because it can expose storage back ends, network listeners, and privileged command execution paths. This vulnerability matters because the issue is not a noisy exploit chain, it is a single request that can turn a backup service into a shell on the host when passwordless mode and external SSH are enabled.

For IAM and NHI teams, the lesson is simple: infrastructure that touches backup repositories, SFTP endpoints, and reverse proxies needs the same identity scrutiny as production application planes. A tool that is treated as internal-only can still be internet-reachable, and when that happens the boundary between operational convenience and exploitable trust disappears. That assumption failure is common in self-hosted backup estates.

Key questions

Q: What breaks when a backup server accepts unauthenticated requests and passes them into SSH arguments?

A: The trust boundary breaks first, then the service becomes a remote code execution path. If configuration fields are copied into shell or SSH arguments without strict parsing, an attacker can inject commands before any intended backup workflow runs. In practice, that turns a backup utility into privileged host access and a likely path to data exposure.

Q: Why do backup tools create high-impact exposure when they are reachable from the network?

A: Backup tools often hold broad storage and restore permissions, so their effective authority is larger than their user interface suggests. When network exposure combines with weak authentication or command injection, one flaw can disclose backup data, alter restore integrity, and create a pivot point into adjacent systems. The blast radius is the issue.

Q: How do security teams know whether a backup service is operating outside its intended boundary?

A: Look for routable listeners, passwordless modes, direct shell invocation, and SFTP or SSH settings that accept user-controlled fields. If the service can translate request data into execution primitives, it has crossed from a utility into a privileged control plane. That boundary should be visible in inventory, proxy design, and logging.

Q: Who is accountable when an exposed backup service is used for remote code execution?

A: Accountability sits with the team that owns the workload, the network exposure, and the authentication design, not just the patch cycle. Frameworks such as OWASP-NHI and Zero Trust Architecture are relevant because they require explicit trust boundaries and least privilege for non-human services. The owner must be able to explain why the service was reachable at all.

Technical breakdown

How SSH argument injection becomes remote code execution

The flaw sits in the path from Kopia's HTTP API to the SSH command line. User-supplied SFTP configuration fields are concatenated into an SSH invocation with insufficient validation, then split only on literal spaces rather than parsed with a safe tokenizer. That means attacker-controlled tokens such as ProxyCommand can be injected into OpenSSH arguments before any network connection is attempted. The problem is not SSH itself, but unsafe command construction around it. Once the server accepts the crafted request, command execution happens in the context of the Kopia process user without authentication.

Practical implication: treat any HTTP-to-shell handoff as a privileged boundary and remove direct command-line composition from exposed services.

Why passwordless mode makes a backup server externally exploitable

The exploit path requires the server to run with the without-password flag and be reachable on a non-loopback interface. In that configuration, a remote caller does not need credentials to reach the vulnerable endpoint, so the backup application becomes an unauthenticated control plane for the host. Reverse proxies do not automatically solve this if they simply forward requests without their own authentication layer. The real issue is that an administrative convenience setting removed the final barrier between the network and a command execution primitive.

Practical implication: do not expose passwordless administrative endpoints on routable interfaces unless an upstream authentication layer is enforced.

Why backup tooling creates high-impact identity blast radius

Backup systems often have broad read access to repositories, object storage, and file paths that normal application services never need. When an attacker gains code execution inside that context, the blast radius extends beyond the Kopia process to backup data exposure, restore tampering, and possible pivoting into adjacent infrastructure. That is why backup tooling should be modelled as a privileged NHI-like workload with strict ingress controls, explicit trust boundaries, and constrained downstream credentials. The vulnerability illustrates how a utility service can become a primary compromise path when identity controls are left implicit.

Practical implication: classify backup servers as high-trust non-human workloads and scope their access as tightly as production secrets handling infrastructure.

Threat narrative

Attacker objective: The attacker aims to turn a backup service into unauthenticated remote code execution, then use that foothold to access or exfiltrate stored backup data and pivot deeper into the environment.

1. Entry occurs when an attacker sends a single crafted HTTP request to Kopia's /api/v1/repo/exists endpoint on a server exposed with passwordless mode enabled.
2. Credential access or abuse is unnecessary because the flaw lets attacker-controlled SFTP fields reach an SSH command line and inject ProxyCommand arguments before any network connection is attempted.
3. Impact follows as arbitrary commands execute as the Kopia process user, enabling backup data theft, service disruption, and potential lateral movement into adjacent systems.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unauthenticated backup administration is a control failure, not a convenience choice. The vulnerability works because the backup server was allowed to accept network traffic without a compensating authentication boundary while still holding a command execution path. That is a governance decision about trust, not just a patching issue. For identity teams, the lesson is that backup services with external reach must be governed like privileged infrastructure, not treated as background utilities.

Command-line injection in an identity-adjacent service is an identity problem because the service is acting on behalf of the environment. Kopia is not a human account, but it performs privileged actions against storage and restore workflows, which makes it an NHI governance subject. OWASP-NHI and ZT-NIST-207 both point to the same issue: the service's effective authority exceeded the trust assumptions around its input channels. Practitioners should classify backup orchestration as a non-human identity with a defined blast radius.

Backup systems need explicit ingress trust boundaries because reachable APIs and shell access collapse into the same risk surface. The flaw demonstrates that network exposure, parser safety, and execution privilege cannot be managed independently when a service can translate request parameters into host commands. That means exposure review, proxy placement, and privilege scoping must be assessed together. Security teams should stop assuming that internal-use backup tools are low-risk simply because they are not user-facing.

Identity blast radius is the right named concept for this failure mode. A backup tool often has broader data reach than its outward function suggests, so one unauthenticated bug can open file access, repository access, and downstream pivot opportunities in a single move. The practical implication is that governance should be based on what the service can touch, not on the operational label attached to it. If a backup workload can execute commands, it already has enough identity power to justify stricter control.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For practitioners: Use 52 NHI Breaches Analysis to compare this failure mode with other cases where exposed non-human access became the first stage of compromise.

What this signals

Identity blast radius is the concept teams should apply here: if a backup workload can execute commands, its trust level is already above what most operators assume. The practical programme response is to classify backup and restore services as privileged non-human identities, then review where they are network-reachable and what they can modify.

The broader pattern is familiar in NHI security. Only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot see the full set of machine identities that can reach storage, SSH, or backup workflows. That visibility gap makes exposed utilities harder to prioritise until a vulnerability forces the issue.

Practitioners should expect more findings where operational tools behave like hidden control planes. When a service can turn request fields into execution, the boundary between infrastructure administration and identity governance disappears, so the right next step is to align exposure review with workload privilege review rather than treat them as separate exercises.

For practitioners

• Remove passwordless exposure from routable interfaces Bind Kopia servers to localhost where possible, and place any externally reachable instance behind an authenticating reverse proxy before exposing it to non-loopback traffic.
• Treat backup services as privileged non-human identities Inventory each Kopia deployment as a high-trust workload, then document its repository access, SSH dependencies, and the systems it can modify or restore.
• Block unsafe request-to-command paths Review any configuration fields that flow into shell or SSH arguments, then require allowlists, strict tokenisation, and rejection of unsupported ProxyCommand-style input.
• Prioritise exposure plus criticality, not CVSS alone Use runtime reachability, internet exposure, and asset criticality to rank remediation so the most reachable backup servers are patched first.

Key takeaways

• Kopia's flaw shows how a backup server can become a remote code execution path when request data is allowed to reach SSH arguments without safe parsing.
• The risk is amplified by broad non-human privilege, because backup systems often have access to repositories and restore paths that increase blast radius far beyond the application itself.
• The control that would have limited the impact is not a generic alert, but a strict trust boundary around exposure, authentication, and request-to-command handling.

Key terms

• Non-Human Identity: A non-human identity is any machine or workload credential used by software to authenticate, access data, or perform actions. In practice, it includes service accounts, API keys, tokens, certificates, and automation that operates with privileges the business must govern explicitly.
• Identity Blast Radius: Identity blast radius is the amount of system access and data exposure that results when a credential or workload is compromised. For non-human systems, it is determined by repository reach, network reachability, downstream permissions, and whether the workload can invoke privileged actions.
• Privilege Boundary: A privilege boundary is the point where a system should stop accepting untrusted input and start enforcing access control. In backup tooling, that boundary separates web requests, storage configuration, and shell or SSH execution, and it must be designed so that one layer cannot silently control the next.

Deepen your knowledge

Kopia exposure, backup server trust boundaries, and privileged workload governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are hardening exposed backup infrastructure, it is a practical place to start.

This post draws on content published by Orca Security covering the Kopia vulnerability: unauthenticated remote code execution through SSH argument injection. Read the original.