What we found

• AppSecAI Vulnerability ID: 69c734eb
• Vulnerability: CWE-78: OS Command Injection
• Severity: Medium
• File: src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java:63
• Detected By: OpenGrep
• Detection Rule: Tainted Cmd From Http Request

Description: User-controlled input from an HTTP request header flows directly into a command array passed to Runtime.exec(). While the array form of exec() prevents shell interpretation, unvalidated input can still inject additional arguments or pass malicious data to the executed command.

Why this matters

Risk if not fixed: An attacker could execute arbitrary operating system commands on the server by injecting additional process arguments, potentially gaining unauthorized access to system resources, reading sensitive files, or pivoting to other systems.

Attack surface: Any HTTP client can supply a malicious value in the BenchmarkTest01942 header. The header is URL-decoded before use, which expands encoded metacharacters and increases exploitability. No authentication or authorization check protects this endpoint.

Why this is exploitable: The doSomething() method returns the raw HTTP header value unchanged. This value is then embedded into a command array passed to Runtime.exec(). Although the array form of exec() avoids shell metacharacter interpretation, an attacker can still inject additional process arguments or pass specially crafted values that the target command will interpret as instructions.

Why we're changing it

Vulnerability confirmed: The data flow is direct and unobstructed:

1. Line 45: param = request.getHeader("BenchmarkTest01942") — attacker controls this value via HTTP header
2. Line 49: param = java.net.URLDecoder.decode(param, "UTF-8") — URL-encoded characters are decoded, expanding any encoded payloads
3. Lines 74–79: doSomething() returns param as bar with zero transformation or validation
4. Line 63: r.exec(cmdArray, argsEnv, ...) — bar is embedded into the command array without sanitization

No allowlist, regex validation, or sanitization is present at any point in the data flow from source to sink.

How we confirmed

Vulnerability Flow Diagram

%%{init: {'theme':'base','themeVariables':{'fontFamily':'ui-sans-serif, Inter, system-ui, sans-serif','primaryColor':'#EDE9FE','primaryTextColor':'#1A1A2E','primaryBorderColor':'#7C3AED','lineColor':'#5B21B6','secondaryColor':'#FEF3C7','tertiaryColor':'#DCFCE7'}}}%%
flowchart TD
    A["HTTP Header - BenchmarkTest01942"] --> B["URL Decode"]
    B --> C["doSomething() returns param unchanged"]
    C --> D["Embedded in cmdArray"]
    D --> E{"Input validation?"}
    E -->|No| F["❌ Runtime.exec with attacker-controlled argument"]
    E -->|Yes| G["✅ Rejected or safely executed"]
    
    style A fill:#EDE9FE,stroke:#7C3AED
    style B fill:#EDE9FE,stroke:#7C3AED
    style C fill:#FFE5E5,stroke:#F65A5A
    style D fill:#FFE5E5,stroke:#F65A5A
    style E fill:#FEF3C7,stroke:#F59E0B
    style F fill:#FEF3C7,stroke:#F59E0B
    style G fill:#DCFCE7,stroke:#16A34A

Manual Verification Steps

1. Locate the vulnerable code in src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java at line 63
2. Confirm that bar (the HTTP header value) is embedded into cmdArray without prior validation
3. Verify that the doSomething() method performs no transformation on the input parameter
4. Check that no allowlist or regex validation exists between the header read and the exec() call
5. Confirm the fix adds input validation before command construction

#!/bin/bash
# Verification script for CWE-78 fix in BenchmarkTest01942.java
set -e

echo "=== Verification: CWE-78 Command Injection Fix ==="

# Step 1: Check that the vulnerable file exists
echo "Step 1: Locating vulnerable file..."
if [ ! -f "src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java" ]; then
  echo "ERROR: File not found"
  exit 1
fi
echo "✓ File found"

# Step 2: Verify input validation is present before exec call
echo "Step 2: Checking for input validation gate..."
if grep -q "matches.*\[a-zA-Z0-9" src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java; then
  echo "✓ Allowlist validation pattern detected"
else
  echo "WARNING: Allowlist validation pattern not found"
fi

# Step 3: Verify that validation occurs before exec
echo "Step 3: Verifying validation placement..."
VALIDATION_LINE=$(grep -n "matches.*\[a-zA-Z0-9" src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java | cut -d: -f1 | head -1)
EXEC_LINE=$(grep -n "Runtime.getRuntime().exec" src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java | cut -d: -f1 | head -1)

if [ -n "$VALIDATION_LINE" ] && [ -n "$EXEC_LINE" ]; then
  if [ "$VALIDATION_LINE" -lt "$EXEC_LINE" ]; then
    echo "✓ Validation occurs before exec call (line $VALIDATION_LINE before line $EXEC_LINE)"
  else
    echo "ERROR: Validation occurs after exec call"
    exit 1
  fi
fi

# Step 4: Verify that invalid input is rejected
echo "Step 4: Checking for error response on invalid input..."
if grep -q "response.sendError\|response.setStatus" src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java; then
  echo "✓ Error response mechanism present"
else
  echo "WARNING: Error response mechanism not explicitly found"
fi

# Step 5: Compile the fixed code
echo "Step 5: Compiling fixed code..."
if mvn -q compile -DskipTests 2>/dev/null; then
  echo "✓ Code compiles successfully"
else
  echo "ERROR: Compilation failed"
  exit 1
fi

echo ""
echo "=== All verification checks passed ==="

Vulnerable flow: src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java:63

Command Injection

%%{init: {'theme':'base','themeVariables':{'fontFamily':'ui-sans-serif, Inter, system-ui, sans-serif','primaryColor':'#EDE9FE','primaryTextColor':'#1A1A2E','primaryBorderColor':'#7C3AED','lineColor':'#5B21B6','secondaryColor':'#FEF3C7','tertiaryColor':'#DCFCE7'}}}%%
flowchart TD
    subgraph Vulnerable["❌ Vulnerable Flow"]
        direction LR
        A1["Project"] --> A2["OS command injection via user input"]
        A2 --> A3["💥 OS Command Executed"]
    end

    Vulnerable ~~~ Fixed

    subgraph Fixed["✅ Fixed Flow"]
        direction LR
        B1["Project"] --> B2["Command allowlist or subprocess array"]
        B3["🛡️ Attack Blocked"]
        B2 --> B3
    end

    style A2 fill:#FFE5E5,color:#000
    style A3 fill:#ffa94d,color:#000
    style B2 fill:#74c0fc,color:#000
    style B3 fill:#DCFCE7,color:#000

How we fixed it

Root Cause

The doSomething() method returns the raw HTTP header value unchanged. This value is then embedded into a command array passed to Runtime.exec(). Although the array form of exec() prevents shell metacharacter interpretation, the unvalidated input can still be used to inject additional process arguments or pass malicious data to the target command.

Fix Approach

An allowlist regex validation gate is inserted before command construction. Input that does not consist solely of alphanumeric characters, spaces, and a narrow set of safe punctuation ([a-zA-Z0-9 @._\-]) is rejected with an HTTP error response. This prevents any attacker-controlled metacharacters, path separators, or shell special characters from reaching the exec() call.

Why This Approach

Alternatives considered:

• Switch to ProcessBuilder with inherited environment: Rejected because Runtime.exec() array form already avoids shell interpretation; the remaining risk is argument injection, which requires input validation regardless of the execution method.
• Escape shell special characters: Rejected because escaping is error-prone and language/OS-dependent; allowlist validation is safer and simpler for this use case.
• Remove OS command execution entirely: Rejected because the benchmark test requires the exec call to be present for functional equivalence.

Why allowlist validation is the right choice:

• Simplicity: The allowlist pattern is easy to understand and audit.
• Safety: Only explicitly permitted characters can reach the exec call; all others are rejected.
• Maintainability: Future developers can easily see what input is considered safe.
• Performance: Regex matching is fast and adds minimal overhead.

Vulnerabilities Addressed

• Grouped findings in scope: 1
• Findings fixed in this PR: 1
• Primary CWE family: CWE-78
• Files covered: src/main/java/org/owasp/benchmark/testcode/BenchmarkTest01942.java

How we validated it

• Code review: The fix adds validation immediately after the HTTP header is resolved and before any command array is constructed.
• Functional testing: Valid echo payloads (alphanumeric text) continue to execute normally.
• Security testing: Inputs containing shell metacharacters (|, ;, $, backticks, newlines, path separators, etc.) are now rejected rather than executed.
• Regression testing: No side effects on other components; the fix is isolated to this servlet's response handling.

How to verify

Reviewers can verify the fix by:

1. Examining the diff to confirm the allowlist validation is present before the exec() call
2. Checking that the validation pattern matches only safe characters
3. Confirming that invalid input triggers an HTTP error response
4. Running the verification script above to confirm compilation and validation placement
5. Testing with sample payloads:
   • Valid: hello world → should execute
   • Invalid: hello; rm -rf / → should be rejected
   • Invalid: hello$(whoami) → should be rejected

Before you merge

• Fix addresses the root cause (unvalidated input to exec), not just the symptom
• No new security vulnerabilities introduced by the fix
• Code follows project conventions and style guidelines
• Edge cases handled (null input, empty strings, special characters)
• No functionality regression; valid payloads still execute
• No shell commands with user-controllable input that bypasses validation
• Verification script passes without errors

Learn more

• CWE-78: OS Command Injection
• OWASP Command Injection Defense Cheat Sheet
• OWASP Command Injection Attack Description
• Java Runtime.exec() Security Considerations

This fix was generated by AppSecAI. Please review before merging.