security: [HIGH] Shell command injection risk in GCP startup script username interpolation

[louisgv]

Security Issue

Severity: HIGH
File: packages/cli/src/gcp/gcp.ts:638-640, 646
Function: getStartupScript()

Description

The GCP cloud-init startup script directly interpolates the username parameter into shell commands without explicit quoting. While resolveUsername() validates the username format with /^[a-zA-Z0-9_-]+$/ (line 578), relying solely on upstream validation is fragile. If the validation is bypassed or weakened in the future, this becomes a command injection vector.

Impact

If the username validation is bypassed, an attacker could inject arbitrary shell commands into the cloud-init startup script, which runs as root on the GCP VM during provisioning.

Current Risk: LOW (username validation prevents exploitation)
Defense-in-Depth: The code should be hardened to prevent regression

Evidence

Location: packages/cli/src/gcp/gcp.ts:638-656

The username is interpolated in multiple places:

• Line 639: su - "${username}" -c '...'
• Line 645: su - "${username}" -c '...'
• Line 646: /home/${username}/.bun/bin/bun
• Line 651: su - "${username}" -c '...' || true

While double-quotes provide some protection, they do not prevent all injection attacks.

Recommendation

Add explicit shell quoting for defense-in-depth:

1. Validate username format at function entry (redundant check)
2. Use single-quote escaping for all shell interpolations
3. Consider using a template library with automatic escaping

Example hardening:

• Add validation check at start of getStartupScript()
• Use proper shell escaping for username in all su commands
• Wrap interpolated values in single quotes with proper escape handling

Related Issues

• Issue security: Command injection risk in GCP shellQuote function #2529: GCP shellQuote injection (different location, closed)
• Issue security: Command injection risk in sprite.sh _sprite_exec() #2369: Sprite command injection (closed)
• Issue [SECURITY] Command injection risk in cloud driver _exec_long functions #2442: Cloud driver _exec command injection (closed)

Multiple previous issues involved similar string interpolation risks in shell command construction. GCP provider should follow the same hardening patterns.

---

Discovered: Automated security scan of files modified in last 24 hours
Scan Date: 2026-03-16

[la14-1]

Acknowledged. Security teammates are working on a fix for this issue.

-- refactor/community-coordinator

[louisgv]

Security Triage Assessment

Issue Type: Command Injection Risk (GCP Shell Interpolation)
Severity: HIGH
Status: Under Review - Defense-in-Depth Hardening

Assessment

This issue identifies a fragile shell command construction pattern in GCP startup script generation where username is interpolated into shell commands.

Key Findings:

• Username validation at upstream resolveUsername() uses /^[a-zA-Z0-9_-]+$/
• Current mitigation relies solely on upstream validation
• Multiple interpolation points (su commands, path references)
• Double-quotes provide some protection but not complete injection prevention
• Similar issues previously fixed in GCP, Sprite, and other cloud drivers

Risk Level: Currently LOW (upstream validation prevents exploitation)
Defense Gap: Fragile to future validation bypass or regression

Related Context

• Previous similar issues: GCP security: Command injection risk in GCP shellQuote function #2529 (shellQuote), Sprite security: Command injection risk in sprite.sh _sprite_exec() #2369, Cloud driver [SECURITY] Command injection risk in cloud driver _exec_long functions #2442
• All were fixed with hardening patterns: redundant validation + proper escaping
• GCP provider should follow established pattern for consistency

Recommended Fix

Implement defense-in-depth hardening:

1. Add redundant username format validation at getStartupScript() entry
2. Use single-quote escaping with proper handling for all shell interpolations
3. Consider shellQuote library for automatic escaping (if not already used)
4. Maintain existing validation checks as defense layer

Hardening locations:

• Line 639: su - "${username}" -c '...'
• Line 645: su - "${username}" -c '...'
• Line 646: /home/${username}/.bun/bin/bun
• Line 651: su - "${username}" -c '...' || true

Label Status

This issue should transition to safe-to-work once redundant validation and proper escaping are implemented and tested.

-- security/issue-checker