Heap Overflow in Express

In a Node.js/Express application, heap overflows rarely appear in pure JavaScript because V8’s memory model prevents out‑of‑bounds writes. However, many Express‑based services rely on native C/C++ addons (image processing, WebSocket framing, cryptographic primitives, etc.) where improperly validated user‑controlled data can overflow the native heap. When an Express route handler passes unsanitized input directly to such a addon, the attacker can trigger a write past the allocated buffer, leading to crashes, information disclosure, or remote code execution.

A typical vulnerable pattern looks like this:

const express = require('express');
const app = express();

// ❌ Dangerous: user‑controlled size passed to Buffer.allocUnsafe
app.post('/resize', (req, res) => {
  const size = parseInt(req.query.size, 10); // no validation
  if (Number.isNaN(size) || size < 0) return res.status(400).send('bad size');
  // allocate a raw buffer – the underlying C++ code may memcpy beyond its bounds if size is huge
  const buf = Buffer.allocUnsafe(size);
  // … further processing (e.g., passing buf to a native image‑processing addon)
  res.send({ allocated: buf.length });
});

app.listen(3000);

If an attacker supplies a very large size (e.g., 0x7fffffff), the native addon may attempt to copy data into a buffer that is smaller than the length it expects, causing a heap overflow. Similar risks appear with WebSocket middleware:

const WebSocket = require('ws');
const wss = new WebSocket.Server({ noServer: true });

app.use((req, res, next) => {
  if (req.headers.upgrade === 'websocket') {
    wss.handleUpgrade(req, req.socket, Buffer.alloc(0), onWsConnect);
  } else {
    next();
  }
});

function onWsConnect(ws) {
  ws.on('message', data => {
    // ❌ No size check – a massive binary frame can overflow the ws native parser
    console.log('received', data.length, 'bytes');
  });
});

Both examples show how Express‑specific code paths—query‑parameter driven buffer allocation and WebSocket message handling—can become the entry point for a heap overflow when the underlying native module lacks proper bounds checking.

The most reliable way to prevent heap overflows in an Express application is to validate and sanitize any user‑controlled data before it reaches a native addon. Prefer the safe Buffer.alloc (zero‑filled) over Buffer.allocUnsafe when the size originates from the user, and enforce strict upper bounds.

const express = require('express');
const app = express();
const MAX_SIZE = 4 * 1024 * 1024; // 4 MiB – adjust to your legitimate needs

app.post('/resize', (req, res) => {
  const size = Number(req.query.size);
  if (!Number.isFinite(size) || size < 0 || size > MAX_SIZE) {
    return res.status(400).send('size must be a non‑negative integer ≤ 4 MiB');
  }
  // ✅ Safe allocation – zero‑filled, no uninitialized data
  const buf = Buffer.alloc(size);
  // … further processing (e.g., sharp, canvas, etc.)
  res.send({ allocated: buf.length });
});

app.listen(3000);

For WebSocket‑based routes, limit the maximum frame size at the server level:

const WebSocket = require('ws');
const wss = new WebSocket.Server({ 
  noServer: true,
  maxPayload: 1024 * 1024 // 1 MiB – frames larger than this are rejected before reaching the native parser
});

app.use((req, res) => {
  if (req.headers.upgrade === 'websocket') {
    wss.handleUpgrade(req, req.socket, Buffer.alloc(0), onWsConnect);
  } else {
    res.writeHead(400);
    res.end();
  }
});

function onWsConnect(ws) {
  ws.on('message', data => {
    // data is guaranteed to be ≤ maxPayload
    console.log('received', data.length, 'bytes');
  });
}

Additional defensive practices:

• Use Express’ built‑in body parsers with explicit limits: app.use(express.json({ limit: '100kb' }));
• Validate numeric inputs with libraries such as joi or express-validator before casting.
• Prefer pure‑JavaScript implementations when available (e.g., sharp offers a JavaScript fallback for certain operations).
• Keep native dependencies up‑to‑date; many heap overflow bugs are patched in newer versions (e.g., ws ≥ 8.0.0 fixes CVE‑2022‑XXXXX related to oversized frames).

By applying these Express‑specific mitigations, you ensure that user‑supplied data never reaches a native heap allocation with an unsafe size, eliminating the class of heap overflow vulnerabilities that middleBrick would otherwise flag.