Container Escape in Nestjs (Typescript)

In Nestjs applications built with Typescript, container escape vulnerabilities arise when an attacker exploits misconfigured runtime environments to break out of the container and gain unauthorized access to the host system. While Nestjs itself does not introduce container-specific risks, its common deployment patterns — such as running as root inside containers, mounting host directories, or exposing privileged sockets — combined with unvalidated user input in APIs can create pathways for escape. For example, a Nestjs endpoint that accepts file uploads without proper path validation might allow an attacker to write a malicious binary to a mounted host volume (e.g., /host via -v /host:/app/host in Docker). If the container runs with CAP_SYS_ADMIN or privileged: true, the attacker could then execute that binary to exploit kernel vulnerabilities like CVE-2022-0847 (Dirty Pipe) or CVE-2021-3156 (Heap Overflow in sudo) to escape the container.

Typescript’s static typing does not prevent these runtime misconfigurations, but it can help catch certain classes of bugs during development — such as unintentional use of any types that bypass validation. However, if developers rely on runtime checks that are missing or flawed (e.g., using path.join() without sanitizing user input), an attacker can still traverse directories and write to host-mounted paths. The real risk emerges when Nestjs applications expose APIs that interact with the filesystem or execute processes based on user input, especially in environments where the container is not properly isolated (no user namespace, no seccomp profile, or excessive capabilities). middleBrick detects such risks by scanning for indicators of excessive privileges, exposed Docker sockets, or unsafe file operations in API endpoints — even without credentials or agents — by analyzing runtime behavior during its black-box scan.

To mitigate container escape risks in a Nestjs Typescript application, enforce strict input validation, avoid running as root, and never trust user input for filesystem or process operations. Use Nestjs’s built-in validation pipes with class-validator and class-transformer to sanitize inputs at the API layer. For example, when handling file uploads, validate the filename to prevent path traversal:

import { Controller, Post, UploadedFile, UseInterceptors } from '@nestjs/common';
import { FileInterceptor } from '@nestjs/platform-express';
import { diskStorage } from 'multer';
import { extname, resolve } from 'path';
import { BadRequestException } from '@nestjs/common';

@Controller('upload')
export class UploadController {
  @Post()
  @UseInterceptors(
    FileInterceptor('file', {
      storage: diskStorage({
        destination: './uploads',
        filename: (req, file, callback) => {
          const randomName = Array(32)
            .fill(null)
            .map(() => Math.round(Math.random() * 16).toString(16))
            .join('');
          return callback(null, `${randomName}${extname(file.originalname)}`);
        },
      }),
      fileFilter: (req, file, callback) => {
        if (file.mimetype.match(/\/(jpg|jpeg|png|gif)$/)) {
          callback(null, true);
        } else {
          callback(new BadRequestException('Only image files are allowed!'), false);
        }
      },
    }),
  )
  uploadFile(@UploadedFile() file: Express.Multer.File) {
    return { filename: file.filename };
  }
}

This code prevents attackers from controlling the filename, eliminating path traversal risks. Additionally, always run your Nestjs container as a non-root user:

FROM node:18-alpine
WORKDIR /app
COPY package*.json .
RUN npm ci --only=production
COPY . .
RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
USER nextjs
EXPOSE 3000
CMD ["npm", "run", "start:prod"]

Never mount the Docker socket (/var/run/docker.sock) into the container unless absolutely necessary, and if you do, restrict it with read-only mode and SELinux/AppArmor profiles. Use Docker’s --cap-drop ALL and --security-opt no-new-privileges to minimize privileges. middleBrick helps by detecting exposed privileged endpoints or unsafe file operations during its scan, guiding you to fix these issues before deployment.