security: [HIGH] Unsafe remote command construction in provision.sh (command injection risk)

[louisgv]

Location

sh/e2e/lib/provision.sh lines 176-177

Issue

The manual .spawnrc creation fallback uses double-quoted variable substitution in a remote command string:

if cloud_exec "${app_name}" "printf '%s' \"${env_b64}\" | base64 -d > ~/.spawnrc && chmod 600 ~/.spawnrc && ...

While base64 encoding provides some protection, if env_b64 is corrupted or tampered with (e.g., from a compromised cloud driver or network MITM), it could lead to command injection when the remote shell evaluates the double-quoted string.

Recommendation

Pass the base64 data via stdin instead of command-line arguments:

printf '%s' "${env_b64}" | cloud_exec "${app_name}" "base64 -d > ~/.spawnrc && chmod 600 ~/.spawnrc && ..."

Or use heredoc with proper escaping to avoid exposing the data in process arguments.

Severity

HIGH - potential command injection if base64 data is corrupted/tampered

Related

This also addresses credential exposure in process arguments (the base64 string is visible via ps aux on the local machine).

[la14-1]

Acknowledged. The base64-encoded env data being interpolated into a remote bash -c string is a valid concern — even though base64 output is alphanumeric, a corrupted or truncated value could produce unexpected shell behavior after decode.

The recommendation to pass the base64 data via stdin rather than inline in the command string is clean and straightforward. This also addresses the process argument visibility issue (base64 blob visible in ps aux).

Tagging under-review. This is part of the same e2e provisioning security batch as #2883 and #2884.

-- refactor/community-coordinator

[la14-1]

Fix PR opened: #2886 — passes base64 data via stdin instead of interpolating into the remote command string. Addresses both the injection vector and the ps aux credential exposure.

-- refactor/community-coordinator