Out Of Bounds Write in Express with Cockroachdb

An Out Of Bounds Write occurs when an application writes data to a memory location outside the intended buffer. In an Express API that uses CockroachDB, this typically manifests through unchecked user input used to size buffers, allocate arrays, or drive pagination/layout logic before values are sent to the database. Even though CockroachDB is a hardened distributed SQL database, the vulnerability arises in the application layer: Express routes parse and forward data, and if input length or numeric ranges are not strictly validated, crafted payloads can cause writes beyond allocated memory regions. This can corrupt in-memory structures, overwrite adjacent variables, or trigger undefined behavior that may lead to arbitrary code execution or information disclosure.

Consider an endpoint that accepts a page and size to stream records from a CockroachDB table. If size is taken directly from request query parameters and used to allocate an array or to compute offsets in a buffer, an attacker can supply a very large number, causing the application to allocate an excessively large buffer or compute an offset that exceeds intended boundaries. When data is then written into this buffer (for example, while constructing rows to insert or update), bytes may spill into adjacent memory. Because CockroachDB drivers typically stream results and enforce strict type handling, the database itself will not introduce such out-of-bounds behavior; the root cause is unchecked input shaping the in-memory layout before any SQL is issued.

Real-world patterns that can expose this include using user-controlled numeric fields to determine array lengths, string copying without length checks, or unsafe deserialization of payloads that later form SQL parameters. Attack chains might combine an Out Of Bounds Write with other issues—such as insufficient input validation—to manipulate execution flow. Since the scan categories include Input Validation and Unsafe Consumption, middleBrick can surface such risky patterns by correlating runtime behavior with the OpenAPI spec, highlighting missing constraints on numeric ranges or string lengths for parameters that feed into data-handling logic.

An example of a vulnerable Express route:

app.get('/export', (req, res) => {
  const page = parseInt(req.query.page) || 1;
  const size = parseInt(req.query.size) || 10;
  // Unsafe: size used to allocate an in-memory buffer
  const buffer = Buffer.alloc(size * 128); // 128 bytes per record
  let offset = 0;
  rows.forEach(row => {
    const payload = row.data.slice(0, 128);
    buffer.write(payload, offset);
    offset += 128;
  });
  res.set('Content-Type', 'application/octet-stream');
  res.send(buffer);
});

If an attacker sets size=1000000, Buffer.alloc may allocate far more memory than expected, and the loop can write beyond the intended region if row data exceeds 128 bytes or if offset miscalculations occur. Although CockroachDB will only return valid rows, the preceding memory corruption creates a security finding. middleBrick’s checks for Input Validation and Unsafe Consumption would flag missing validation on size and risky use of buffers derived from unchecked inputs.

Remediation centers on strict validation and safe handling of user input before it influences memory operations or data construction for CockroachDB interactions. Always treat numeric controls as untrusted and bound them to sensible ranges. Use explicit length checks on strings and avoid deriving buffer sizes directly from query parameters.

Fix the earlier example by validating and bounding size, and by not relying on unchecked offsets:

const MAX_SIZE = 1000;
app.get('/export', (req, res) => {
  let page = parseInt(req.query.page) || 1;
  let size = parseInt(req.query.size) || 10;
  if (!Number.isInteger(page) || !Number.isInteger(size) || size <= 0 || size > MAX_SIZE) {
    return res.status(400).send('Invalid pagination parameters');
  }
  // Safe: size is bounded before any buffer allocation
  const buffer = Buffer.alloc(size * 128);
  let offset = 0;
  rows.forEach(row => {
    const payload = row.data.slice(0, 128);
    if (offset + payload.length > buffer.length) {
      // Defensive check to ensure we never overflow the buffer
      return res.status(500).send('Internal data length mismatch');
    }
    buffer.write(payload, offset);
    offset += payload.length;
  });
  res.set('Content-Type', 'application/octet-stream');
  res.send(buffer.slice(0, offset));
});

When constructing SQL for CockroachDB, prefer parameterized queries and avoid concatenating user input into sizes or limits. Use placeholders for values and validate numeric inputs separately:

const { Pool } = require('pg');
const pool = new Pool({ connectionString: process.env.DATABASE_URL });
app.get('/users', async (req, res) =>
  try {
    const page = Math.max(1, parseInt(req.query.page) || 1);
    const limit = Math.min(100, Math.max(1, parseInt(req.query.limit) || 20));
    const result = await pool.query(
      'SELECT id, name FROM users ORDER BY id LIMIT $1 OFFSET $2',
      [limit, (page - 1) * limit]
    );
    res.json(result.rows);
  } catch (err) {
    res.status(500).send('Database error');
  }
);

For operations that involve constructing buffers or in-memory representations based on query parameters, enforce strict schema validation and length constraints. middleBrick’s scans can help identify endpoints where parameters flow unchecked into data handling logic, allowing you to align runtime behavior with documented specs and reduce the risk of memory corruption.