Summary
A command-injection vulnerability in @runnerty/executor-decompress allows shell commands to be interpreted from crafted archive file names processed by the compress_file workflow. An attacker who can control the name of a file placed in a watched directory may execute commands with the privileges of the Runnerty process.
A command-injection vulnerability in @runnerty/executor-decompress allows shell commands to be interpreted from crafted archive file names processed by the compress_file workflow. An attacker who can control the name of a file placed in a watched directory may execute commands with the privileges of the Runnerty process.
Affected context
The vulnerability occurs in deployments using @runnerty/executor-decompress through version 3.1.1 when archive or file names from a watched directory are incorporated into shell commands through shelljs.exec(). Risk depends on whether an attacker can create or rename files in the watched location and whether those names reach the command-building logic without strict validation or safe argument handling.
The vulnerability occurs in deployments using @runnerty/executor-decompress through version 3.1.1 when archive or file names from a watched directory are incorporated into shell commands through shelljs.exec(). Risk depends on whether an attacker can create or rename files in the watched location and whether those names reach the command-building logic without strict validation or safe argument handling.
Exploit preconditions
- Attack surface: File-processing workflow associated with a watched directory
- Required access: Ability to create, upload, or rename a file so its name is processed by the executor
- Trigger point: The
compress_fileoperation when it invokes a shell command using the supplied file name - Why exploitation is possible: File-name data is passed into a shell-interpreted command without reliably separating data from command syntax
- Privilege boundary: Commands execute with the permissions available to the Runnerty process
- Attack surface: File-processing workflow associated with a watched directory
- Required access: Ability to create, upload, or rename a file so its name is processed by the executor
- Trigger point: The
compress_fileoperation when it invokes a shell command using the supplied file name - Why exploitation is possible: File-name data is passed into a shell-interpreted command without reliably separating data from command syntax
- Privilege boundary: Commands execute with the permissions available to the Runnerty process
Why this happens
The underlying bug is OS command injection, mapped to CWE-78. User-influenced file-name data is incorporated into a command string and executed through a shell interface, allowing shell metacharacters or command substitutions to alter the intended operation. The insecure pattern is treating externally controlled names as trusted command text instead of passing them as isolated arguments through a non-shell API or enforcing a strict filename policy.
The underlying bug is OS command injection, mapped to CWE-78. User-influenced file-name data is incorporated into a command string and executed through a shell interface, allowing shell metacharacters or command substitutions to alter the intended operation. The insecure pattern is treating externally controlled names as trusted command text instead of passing them as isolated arguments through a non-shell API or enforcing a strict filename policy.
Potential impact
- An attacker may execute arbitrary operating-system commands
- The Runnerty process and its accessible data may be compromised
- Credentials, configuration data, or stored secrets could be exposed
- Files may be modified, deleted, or replaced
- The host or surrounding services could be affected if excessive privileges are available
- The vulnerability could support lateral movement or persistence
- An attacker may execute arbitrary operating-system commands
- The Runnerty process and its accessible data may be compromised
- Credentials, configuration data, or stored secrets could be exposed
- Files may be modified, deleted, or replaced
- The host or surrounding services could be affected if excessive privileges are available
- The vulnerability could support lateral movement or persistence
General mitigation guidance
Mitigation generally focuses on removing shell interpretation from file-processing operations and reducing trust in file names.
Common defensive patterns include:
- Prefer direct process and filesystem APIs that pass arguments separately rather than constructing shell command strings
- Apply strict allowlisting for permitted file-name characters, extensions, and path formats
- Reject path separators, control characters, shell syntax, and unexpected encodings
- Resolve and constrain paths to an approved directory before processing
- Treat watched-directory contents as untrusted input, regardless of their source
- Run the Runnerty process with the minimum filesystem, network, and operating-system privileges required
- Use isolation boundaries and read-only access where compatible with the workflow
- Preserve safe defaults so command execution is disabled unless explicitly required
Mitigation generally focuses on removing shell interpretation from file-processing operations and reducing trust in file names.
Common defensive patterns include:
- Prefer direct process and filesystem APIs that pass arguments separately rather than constructing shell command strings
- Apply strict allowlisting for permitted file-name characters, extensions, and path formats
- Reject path separators, control characters, shell syntax, and unexpected encodings
- Resolve and constrain paths to an approved directory before processing
- Treat watched-directory contents as untrusted input, regardless of their source
- Run the Runnerty process with the minimum filesystem, network, and operating-system privileges required
- Use isolation boundaries and read-only access where compatible with the workflow
- Preserve safe defaults so command execution is disabled unless explicitly required
How teams detect issues like this
Detection can include static analysis and code review checks for shell execution APIs receiving values derived from file names, directory events, uploads, or other external inputs. Reviewers can look for string concatenation or interpolation used to construct commands, missing argument quoting, and path validation performed after command construction.
Runtime monitoring may alert on unexpected child processes spawned by Runnerty, unusual command interpreters, or file-processing jobs accessing paths outside their designated workspace. CI and policy enforcement can block shell execution with untrusted data and require approved argument-safe process APIs. Automated code review and SAST tools may help identify these patterns.
Detection can include static analysis and code review checks for shell execution APIs receiving values derived from file names, directory events, uploads, or other external inputs. Reviewers can look for string concatenation or interpolation used to construct commands, missing argument quoting, and path validation performed after command construction.
Runtime monitoring may alert on unexpected child processes spawned by Runnerty, unusual command interpreters, or file-processing jobs accessing paths outside their designated workspace. CI and policy enforcement can block shell execution with untrusted data and require approved argument-safe process APIs. Automated code review and SAST tools may help identify these patterns.
