Prompt Injection on Docker

Detecting prompt injection in Docker images requires looking at both the runtime API and the build‑time configuration. middleBrick performs unauthenticated black‑box scanning of the exposed API surface and includes dedicated LLM security probes that can reveal injection vulnerabilities.

When you submit a container’s exposed URL (e.g., http://host:8080/generate) to middleBrick, the scanner:

• Checks for the presence of an LLM endpoint by analysing response patterns (e.g., token usage fields, model identifiers).
• Runs five sequential prompt‑injection probes:
  • System prompt extraction – attempts to retrieve the internal system prompt.
  • Instruction override – tries to make the model ignore prior instructions.
  • DAN jailbreak – tests known jailbreak strings.
  • Data exfiltration – looks for leakage of sensitive data.
  • Cost exploitation – checks for attempts to cause excessive token usage.
• Scans the response for PII, API keys, or executable code that should not appear in model output.

In addition to API testing, middleBrick can inspect the Docker image layers (if provided via a registry URL) for risky patterns such as:

• Environment variables that are later used in eval, sh -c, or string concatenation that builds a prompt.
• Entrypoint or CMD scripts that contain unsanitized variable expansions.
• Open ports that expose LLM inference servers without authentication.

For example, scanning an image that contains the insecure entrypoint.sh shown earlier will trigger a finding under the “LLM/AI Security” category with severity high, referencing the specific line where eval "$USER_INPUT" occurs.

Because middleBrick does not require agents or credentials, you can integrate the check into a CI pipeline. Adding the GitHub Action:

# .github/workflows/docker-scan.yml
name: Docker API Security
on:
  push:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Build Docker image
        run: docker build -t my-llm-app .
      - name: Run middleBrick scan
        uses: middlebrick/github-action@v1
        with:
          image: my-llm-app
          fail-below: B   # fails the job if score drops below B

The action pulls the image, runs a temporary container, exposes its ports, and lets middleBrick perform the unauthenticated scan. If any prompt‑injection probe succeeds, the action returns a non‑zero exit code, causing the build to fail.

Fixing prompt injection in Docker‑based LLM services involves separating trusted system instructions from untrusted user input, avoiding shell interpolation, and limiting the container’s privileges.

1. **Separate system and user messages** – When using chat‑style APIs (e.g., OpenAI’s ChatCompletion), send the system prompt as a distinct role:"system" message and the user input as a role:"user" message. This prevents the model from treating user text as part of the instruction set.

# app.py (fixed)
from flask import Flask, request, jsonify
import os
import openai

app = Flask(__name__)
SYSTEM = os.getenv('SYSTEM_PROMPT', 'You are a helpful assistant.')

@app.route('/generate', methods=['POST'])
def generate():
    user_input = request.json.get('prompt', '')
    # Safe: separate roles
    response = openai.ChatCompletion.create(
        model='gpt-3.5-turbo',
        messages=[
            {"role": "system", "content": SYSTEM},
            {"role": "user", "content": user_input}
        ],
        temperature=0.7
    )
    return jsonify({'text': response.choices[0].message.content})

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

2. **Avoid shell evaluation of environment variables** – Replace eval or sh -c with explicit argument passing. If you need to pass user‑provided data to a subprocess, use an array form that does not invoke a shell.

# entrypoint.sh (fixed)
#!/bin/sh
# USER_INPUT is expected to be a plain text prompt, not shell code
# Pass it as an argument to the LLM server
/usr/local/bin/llama-server --prompt "$USER_INPUT"

Then run the container without relying on shell expansion:

docker run -e USER_INPUT="Hello world" my-llm-image

3. **Use Docker’s built‑in security options** – Run the container with a non‑root user, drop unnecessary capabilities, and make the filesystem read‑only where possible. This limits the impact if an attacker manages to escape the prompt context and attempts to execute arbitrary commands.

docker run \
  --user 1000:1000 \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  my-llm-image

4. **Validate and sanitize input** – Apply length limits, reject strings that contain known injection patterns (e.g., "Ignore previous instructions", "\n\nSystem:"), and consider using an allow‑list of characters if the domain permits.

By combining these practices—separating roles, avoiding unsafe shell interpolation, and hardening the container runtime—you significantly reduce the risk of prompt injection in Docker‑deployed LLM services. middleBrick’s LLM security checks will continue to verify that the mitigations are effective, reporting a finding only if a probe still succeeds.