File Upload Security in MCP Servers

Path traversal via ../ in filenames

Path traversal occurs when a user-controlled filename argument contains sequences like ../, ../../etc/passwd, or URL-encoded equivalents (%2e%2e%2f) that escape the intended upload directory and write to arbitrary filesystem locations. For an MCP server, the "user" supplying the filename is the LLM — which in turn may be acting on user-supplied content or instructions injected through a prompt injection attack. The LLM is not a trusted input source for filesystem paths.

The canonical defense is to resolve the candidate path to its absolute form and verify it is still inside the allowed directory:

import path from 'path';
import fs from 'fs/promises';
import crypto from 'crypto';

const UPLOAD_DIR = path.resolve('/var/mcp-uploads');  // absolute, pre-resolved
const ALLOWED_EXTENSIONS = new Set(['.txt', '.csv', '.json', '.md', '.log']);
const MAX_FILE_BYTES = 10 * 1024 * 1024;  // 10 MB

async function safeWriteFile(
  userFilename: string,
  content: Buffer
): Promise {
  // 1. Strip directory components — keep only the basename
  const basename = path.basename(userFilename);
  if (!basename || basename === '.' || basename === '..') {
    throw new Error('Invalid filename');
  }

  // 2. Check extension against allowlist
  const ext = path.extname(basename).toLowerCase();
  if (!ALLOWED_EXTENSIONS.has(ext)) {
    throw new Error(`Extension not allowed: ${ext}`);
  }

  // 3. Enforce file size limit before writing
  if (content.length > MAX_FILE_BYTES) {
    throw new Error(`File too large: ${content.length} bytes (max ${MAX_FILE_BYTES})`);
  }

  // 4. Resolve to absolute path and verify it is inside UPLOAD_DIR
  // path.resolve joins UPLOAD_DIR + basename; since basename has no slashes,
  // the result is always UPLOAD_DIR/ — but we verify anyway.
  const resolvedPath = path.resolve(UPLOAD_DIR, basename);
  if (!resolvedPath.startsWith(UPLOAD_DIR + path.sep)) {
    // This would only trigger if UPLOAD_DIR itself ends in sep or basename
    // is somehow empty — belt-and-suspenders check.
    throw new Error('Path traversal detected');
  }

  // 5. Validate content via magic bytes (see next section)
  validateMagicBytes(content, ext);

  // 6. Write atomically: write to temp file, then rename
  const tmpPath = path.join(UPLOAD_DIR, `.tmp-${crypto.randomUUID()}`);
  try {
    await fs.writeFile(tmpPath, content, { mode: 0o640 });
    await fs.rename(tmpPath, resolvedPath);
  } catch (err) {
    // Clean up temp file on failure
    await fs.unlink(tmpPath).catch(() => {});
    throw err;
  }

  return resolvedPath;
}

Using path.basename() to strip directory components before joining is the key step. Do not attempt to sanitize ../ sequences yourself — URL decoding, unicode normalization, and null byte truncation make blocklist-based approaches fragile. path.basename() followed by path.resolve() + startsWith() is the complete, portable defense.

MIME type spoofing — Content-Type vs magic bytes

When a tool argument includes a declared file type (either via a mimeType argument or inferred from the filename extension), a malicious or prompt-injected payload can claim to be a .txt file while containing a PHP script or executable binary. The defense is to read the first few bytes of the file content — the "magic bytes" — and compare them against known signatures for executable formats.

// Magic byte signatures for formats that should never be in a text upload
const BLOCKED_SIGNATURES: Array<{ bytes: Buffer; label: string }> = [
  { bytes: Buffer.from([0x4d, 0x5a]), label: 'Windows PE executable (MZ)' },
  { bytes: Buffer.from([0x7f, 0x45, 0x4c, 0x46]), label: 'ELF executable' },
  { bytes: Buffer.from([0xca, 0xfe, 0xba, 0xbe]), label: 'Mach-O binary' },
  { bytes: Buffer.from([0x50, 0x4b, 0x03, 0x04]), label: 'ZIP archive (could contain executables)' },
  { bytes: Buffer.from('