Email Injection on Docker

Email injection in Docker environments typically occurs when containerized applications improperly handle email headers or parameters, allowing attackers to inject additional email commands. This vulnerability is particularly dangerous in Docker because containerized applications often process user input for email functionality without proper validation.

The most common Docker-specific scenario involves applications that accept email addresses or message content as parameters and construct email commands dynamically. For example, a Node.js application in a Docker container might use the child_process module to execute mail commands:

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

app.get('/send-email', (req, res) => {
  const to = req.query.to; // User-controlled input
  const subject = req.query.subject;
  const body = req.query.body;
  
  // Vulnerable: no validation of email parameters
  exec(`sendmail -t <<EOF
To: ${to}
Subject: ${subject}

${body}
EOF`);
  res.send('Email sent');
});

An attacker could exploit this by injecting additional email headers:

curl "http://localhost:3000/send-email?to=victim@example.com%0ABcc: attacker@example.com%0A%0A&subject=test&body=message"

This would create an email with a Bcc header, sending a copy to the attacker. In Docker environments, this becomes more dangerous because containers often have network access to internal services, and email injection can be used to exfiltrate data or spam internal systems.

Another Docker-specific pattern involves containerized mail servers that process incoming requests. If a containerized Postfix or Sendmail instance accepts unvalidated input from other containers or the host, it can be exploited for email injection attacks. The isolation provided by Docker can actually make detection harder, as the attack traffic might be contained within the Docker network.

Detecting email injection in Docker environments requires a multi-layered approach. The first step is runtime monitoring of container network traffic. Docker's built-in logging can be enhanced with tools like Falco to detect suspicious email command patterns:

- rule: Email Injection Attempt
  desc: Detect potential email injection in Docker containers
  condition: |
    spawned_process and 
    container and 
    proc.name in ("sendmail", "mail", "sendEmail") and 
    proc.cmdline contains "\n" or proc.cmdline contains "%0A"
  output: "Email injection attempt in container (user=%user.name container=%container.name command=%proc.cmdline)"
  priority: WARNING

For static analysis, scanning Docker images for vulnerable email handling patterns is crucial. Tools like middleBrick can analyze containerized applications without requiring credentials or internal access. The scanner examines the runtime behavior of the container, testing for email injection vulnerabilities by sending crafted payloads to email-related endpoints.

middleBrick's Docker-specific detection includes:

• Testing email endpoints with header injection payloads
• Scanning for improper use of system mail commands
• Checking for vulnerable email libraries in the container's package dependencies
• Analyzing OpenAPI specifications for email-related endpoints
• Runtime testing of email functionality without requiring credentials
• LLM security checks if the container includes AI/ML components that might process email content

The scanner provides a security score (A–F) with specific findings about email injection vulnerabilities, including severity levels and remediation guidance. For Docker environments, it can scan multiple containers in a compose setup and provide consolidated reports.

Network-level detection is also important. Tools like Docker's built-in network inspection can reveal unusual email traffic patterns between containers. Monitoring tools should look for:

• Unexpected outbound email connections
• Unusual email header patterns in network traffic
• High volumes of email from specific containers
• Connections to unauthorized mail servers

Remediating email injection in Docker requires both code fixes and Docker-specific configurations. At the application level, input validation is critical. Here's a secure Node.js example using proper validation:

const { exec } = require('child_process');
const express = require('express');
const app = express();
const validator = require('email-validator');

function sanitizeEmailInput(to, subject, body) {
  if (!validator.validate(to)) {
    throw new Error('Invalid email address');
  }
  
  // Remove any newline characters that could inject headers
  const safeSubject = subject.replace(/\n/g, ' ').trim();
  const safeBody = body.replace(/\n/g, ' ').trim();
  
  return { to, subject: safeSubject, body: safeBody };
}

app.get('/send-email', (req, res) => {
  try {
    const { to, subject, body } = sanitizeEmailInput(
      req.query.to, 
      req.query.subject, 
      req.query.body
    );
    
    // Use a proper email library instead of exec
    const emailCommand = `sendmail -f noreply@yourdomain.com -t ${to} -s "${subject}" <<< "${body}"`;
    exec(emailCommand);
    res.send('Email sent');
  } catch (error) {
    res.status(400).send('Invalid input: ' + error.message);
  }
});

For Docker-specific hardening, use a multi-stage build to minimize attack surface:

FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:18-alpine AS runner
WORKDIR /app

# Install only necessary packages
RUN apk add --no-cache ca-certificates mailcap

# Create non-root user
RUN addgroup -g 1001 -S nodejs
RUN adduser -S nodejs -u 1001

# Copy built application
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules

# Switch to non-root user
USER nodejs

# Expose only necessary ports
EXPOSE 3000

# Health check
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD node dist/health.js || exit 1

CMD ["node", "dist/index.js"]

Additional Docker-specific mitigations include:

• Network segmentation: isolate email-sending containers from other services
• Resource limits: prevent abuse by limiting CPU and memory for email services
• Read-only filesystems: mount volumes as read-only where possible
• Secrets management: use Docker secrets for email credentials instead of environment variables
• Runtime protection: use Docker's seccomp profiles to restrict dangerous system calls

For containerized mail servers, configure strict access controls and validate all incoming requests. Use Docker Compose to define network policies that restrict which containers can communicate with mail services.