Summary
The backmeup npm package builds shell command strings by concatenating user-influenced option values and executes them through a system shell. If an attacker can control values such as a backup name, source, destination, or filter, shell metacharacters may be interpreted as commands on the local backup host or configured remote SSH target.
Affected context
The vulnerability occurs in backmeup workflows that construct backup commands from option values and execute those commands through a shell. Risk depends on whether an application passes attacker-influenced data into fields such as name, source, destination, or filter, and whether execution occurs locally or through a supplied SSH connection.
Exploit preconditions
- Attack surface: Backup command construction and execution in the backmeup npm package
- Required access: Ability to influence one or more command option values, directly or through an application using the package
- Trigger point: A backup operation that processes the attacker-influenced options
- Execution context: The local backup host, or a remote SSH target when an SSH handle is configured
- Why exploitation is possible: Values are concatenated into a shell command, while path normalization and joining do not remove shell metacharacters
Why this happens
The underlying bug is a failure to separate command arguments from command syntax. backmeup assembles a command string using option values and passes it to a shell-backed execution API instead of invoking a program with a fixed executable and an argument array.
Shell metacharacters embedded in untrusted values can therefore be interpreted as control operators or command substitutions. This behavior maps to CWE-78: Improper Neutralization of Special Elements used in an OS Command, commonly known as OS command injection.
Potential impact
- An attacker may execute arbitrary operating-system commands with the privileges of the backup process.
- Local files, credentials, or backup data could be read, modified, or deleted.
- A remote SSH target could be compromised when it is used for command execution.
- The vulnerable host could be used for persistence, lateral movement, or further network access.
General mitigation guidance
Mitigation generally focuses on preventing data from being interpreted as shell syntax and reducing the privileges available to backup operations.
Common defensive patterns include:
- Invoking fixed executables through
execFileorspawnwith argument arrays rather than shell command strings. - Avoiding shell evaluation for user-controlled paths, names, filters, and other option values.
- Applying allowlists and strict schemas for backup identifiers and path-like inputs.
- Separating user-controlled metadata from operational command parameters.
- Running local and remote backup processes with dedicated least-privilege accounts.
- Restricting SSH credentials, filesystem access, and network permissions to only what backups require.
- Treating remote command execution as an explicit trust boundary and applying equivalent validation there.
How teams detect issues like this
Organizations can identify this weakness through:
- Static analysis rules for string concatenation or interpolation passed to shell-backed execution APIs.
- Code review checks for
child_processor SSH execution calls that receive dynamically assembled command strings. - Searches for shell command construction involving path, filename, filter, or user-supplied option values.
- Policy enforcement requiring argument-array APIs for process execution unless shell use is explicitly reviewed.
- Runtime monitoring for unexpected child processes, command interpreters, or unusual activity from backup service identities.
Automated security and code-review tools may help flag command construction patterns, but findings should be validated against the actual trust boundaries and execution paths.
