Container Escape in Sails (Javascript)

Container escapes occur when an application running inside a container can execute commands or access resources on the host system. In Sails.js applications that use JavaScript for server-side logic, this risk emerges when untrusted input is passed to system calls or when external libraries are used without proper isolation. Since Sails runs on Node.js, it inherits the same process-level privileges as the container runtime. If a Sails route processes user-controlled data with functions like child_process.exec or Buffer.from that can manipulate file descriptors, an attacker who can trigger such code may break out of the container boundary.

Because Sails does not enforce mandatory container restrictions by default, developers often expose host filesystem paths through configuration files or environment variables. When these are interpolated directly into commands without sanitization, the resulting string may be executed by the host kernel. For example, a route that evaluates a path supplied by an API client to load a view template can be abused if the path resolution logic trusts user input. This is especially dangerous in environments where the container shares a network namespace or mounts host directories as volumes.

Attackers can leverage these weaknesses to escape via namespace manipulation, mount points, or by triggering race conditions that expose host metadata. The vulnerability is not unique to Sails, but the framework’s convention-over-configuration model can obscure where user input enters privileged code paths. Without explicit validation of file system operations or system-level calls, a malicious request may result in arbitrary command execution on the underlying infrastructure.

This type of flaw is documented under CVE-2021-22242 in related Node.js container deployments where unescaped paths led to host file system traversal. While middleBrick does not analyze container configurations, it can identify runtime indicators such as unexpected process launches, elevated privilege usage, or anomalous file system access patterns in API responses that suggest a potential escape vector.

Remediation requires strict validation of any input used in system-level operations. In Sails.js, avoid using eval, exec, or spawn with interpolated user data. Instead, use parameterized libraries or static path resolution. For example, if a route uses fs.readFile with a path derived from request parameters, replace dynamic string concatenation with a whitelist-based approach:

// Safe path resolution in Sails.js

const path = require('path');
const allowedPaths = ['/views/layout', '/views/partials/header'];

app.get('/render', (req, res) => {
  const view = req.query.view;
  const safePath = allowedPaths.find(p => p === view);
  if (!safePath) {
    return res.status(400).send('Invalid view');
  }
  const fullPath = path.join('/app', safePath);
  // Proceed with safe rendering
});

Additionally, when interacting with system commands, always use argument arrays instead of string interpolation to prevent injection:

// Using spawn safely

const { spawn } = require('child_process');
const cmd = 'cat';
const args = [
  '/app/config/custom.js' // path must be pre-validated
];

const child = spawn(cmd, args);
child.stdout.on('data', data => {
  res.send(data.toString());
});

Never trust environment variables that reference host paths. If configuration requires host access, inject them at deployment time through secure secret management, not via user-controllable endpoints. Use Docker or orchestration platform sandboxing to enforce read-only file systems and memory limits. middleBrick can detect when such unsafe patterns are invoked through unauthenticated API tests, flagging them as high-risk findings with specific remediation steps.