Versions of step-security/harden-runner prior to v2.10.2 contain multiple command injection weaknesses via environment variables that could potentially be exploited under specific conditions. However, due to the current execution order of pre-steps in GitHub Actions and the placement of harden-runner as the first step in a job, the likelihood of exploitation is low as the Harden-Runner action reads the environment variable during the pre-step stage. There are no known exploits at this time.
setup.ts:169 [1] performs execSync
with a command that gets
invoked after interpretation by the shell. This command includes an
interpolated process.env.USER
variable, which an attacker could
modify (without actually creating a new user) to inject arbitrary
shell expressions into this execSync
. This may or may not be likely
in practice, but I believe the hygienic way to perform the underlying
operation is to use execFileSync
or similar and bypass the
underlying shell evaluation.
setup.ts:229 [2] has a nearly identical execSync
to (1) above,
but with $USER
for shell-level interpolation rather than string
interpolation. However, this is still injectable and would be best
replaced by an execFileSync
, per above.
arc-runner:40-44 [3] has an execSync
with multiple string
interpolations. Most of these do not appear immediately injectible
(since they appear to come from presumed trusted API responses), but
the expansion of getRunnerTempDir()
may be injectable due to its
dependence on potentially attacker-controllable environment variables
(e.g. RUNNER_TEMP
). The underlying operation appears to be a trivial
file copy, so this entire subprocess should in theory be replaceable
with ordinary NodeJS fs
API calls instead.
arc-runner:53 [4] demonstrates the same weakness, and has the same resolution as (3).
arc-runner:57 demonstrates the same weakness as (3) and (4), and has the same resolution.
arc-runner:61 demonstrates the same weakness as (3), (4), and (5), and has the same resolution.