Topic starter
09/06/2026 11:24 pm
TL;DR: A CVE-2026-45695 flaw in Kopia allows unauthenticated remote code execution through SSH argument injection when the server runs in passwordless mode and exposes an SFTP backend, according to Orca Security. Backup infrastructure that assumes internal reachability is enough to justify weak authentication now needs a stricter identity and exposure model.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Critical Unauthenticated RCE in Kopia Backup via SSH ProxyCommand Injection”.
By the numbers:
- Kopia vulnerability CVE-2026-45695 carries a CVSS score of 9.8.
- The issue affects Kopia HTTP server versions 0.22.3 and earlier.
Key questions
A: The trust boundary breaks first, then the service becomes a remote code execution path.
Q: Why does a passwordless backup server create such high compromise risk?
A: Because passwordless mode removes the control that blocks unauthorised callers from reaching the parser and its downstream command execution path.
Q: How do security teams know whether backup tooling is safe to expose on a network?
A: They should test whether the service can be reached without an external authentication gate, whether it passes user input into shell-like tooling, and whether insecure startup flags are permitted in production.
Practitioner guidance
- Audit exposed backup services Inventory backup and restore systems that are reachable beyond localhost and identify any deployment that relies on passwordless operation for convenience.
- Remove command-line trust from configuration input Review any backup workflow that passes storage or repository fields into SSH or other external binaries, and replace free-form parsing with strict allowlists and safe argument handling.
- Enforce authentication before network exposure Place externally reachable backup services behind an authenticating reverse proxy or equivalent access gate, and do not rely on internal network placement as a control.
Bottom line: The Kopia flaw shows that a backup server can become a remote code-execution surface when configuration fields are allowed to shape SSH commands.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
11/06/2026 12:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kopia unauthenticated RCE exposes backup servers to full compromise
12/06/2026 2:21 am
Unauthenticated backup-server access is a governance failure, not just a vulnerability class. The article shows that when a backup service is bound to the network without a compensating authentication layer, the service itself becomes the access path. That is an identity boundary problem because the server is trusted to act on storage and SSH instructions before proving who is calling it. Practitioners should treat exposed backup controls as privileged control planes, not passive infrastructure.
A question worth separating out:
Q: Should organisations prefer localhost binding or an authenticating reverse proxy for backup servers?
A: Use both as layered controls, but if a backup service must remain network accessible, an authenticating reverse proxy is the stronger compensating gate. Localhost binding is the safest default for administration-only use, while network exposure should be reserved for cases where strong authentication and tight configuration control are already in place.
👉 Read our full editorial: Kopia unauthenticated RCE exposes backup servers to full compromise
This post was modified 1 day ago by NHI Mgmt Group