Use After Free in Express

Use After Free (UAF) vulnerabilities in Express applications typically occur when developers reference objects, database connections, or request-scoped resources after they've been released or destroyed. Unlike traditional memory corruption bugs, Express UAF vulnerabilities often stem from asynchronous control flow and callback mismanagement.

A common Express-specific pattern involves request objects being accessed after the response has been sent. Consider this anti-pattern:

app.get('/api/data', async (req, res) => {
  const data = await db.query('SELECT * FROM users');
  res.json(data);
  
  // DANGEROUS: req is now in an indeterminate state
  await processDataAsync(req.query.filter);
});

The request object may be partially cleaned up after res.json() completes, making subsequent access to req.params or req.session unreliable. This becomes especially problematic with Express middleware chains where multiple async operations can complete in unexpected orders.

Database connection pooling presents another Express-specific UAF scenario. When using connection pools with Express routes:

app.post('/api/update', async (req, res) => {
  const connection = await pool.getConnection();
  res.json({ status: 'processing' });
  
  // Connection might be returned to pool before this completes
  await updateDatabase(connection, req.body);
});

The connection could be recycled back to the pool immediately after res.json(), causing the subsequent database operation to fail or behave unpredictably.

File upload handling in Express creates UAF opportunities when developers attempt to access multipart form data after the upload stream has been destroyed:

app.post('/upload', (req, res) => {
  const form = formidable({ multiples: true });
  form.parse(req);
  
  form.on('file', (name, file) => {
    res.json({ filename: file.name });
    // UAF risk: file object may be destroyed after response
    processFileMetadata(file);
  });
});

Event-driven UAF vulnerabilities also occur when response objects are accessed after error handling has terminated the request lifecycle.

Detecting Use After Free vulnerabilities in Express requires both static analysis and runtime monitoring. Static analysis tools can identify patterns where response methods are called before asynchronous operations complete:

app.get('/risky', async (req, res) => {
  // Suspicious pattern: res.method called before await
  res.set('X-Processing', 'true');
  const result = await expensiveOperation();
  res.json(result);
});

middleBrick's Express-specific scanning identifies these patterns by analyzing the control flow graph of your route handlers. The scanner detects when response methods are invoked before async operations complete, flagging potential UAF scenarios.

Runtime monitoring in Express can be implemented using middleware that tracks request state:

function uafProtection(req, res, next) {
  const originalSend = res.send;
  const originalJson = res.json;
  
  res.send = function(...args) {
    req._responseSent = true;
    return originalSend.apply(res, args);
  };
  
  res.json = function(...args) {
    req._responseSent = true;
    return originalJson.apply(res, args);
  };
  
  res.on('finish', () => {
    req._completed = true;
  });
  
  next();
}

app.use(uafProtection);

app.get('/api/safe', async (req, res) => {
  if (req._responseSent) {
    console.warn('UAF detected: response already sent');
    return;
  }
  
  const data = await processAsync();
  res.json(data);
});

middleBrick's scanning also examines middleware chains to identify where request objects might be accessed after termination. The scanner specifically looks for patterns like:

• Accessing req.session after res.redirect()
• Reading req.body after res.end()
• Using req.params after error middleware has handled the request
• Accessing res.locals after response completion

The tool's OpenAPI analysis can also detect UAF vulnerabilities by comparing your API specification with actual implementation patterns, identifying endpoints where response handling doesn't align with documented behavior.

Express provides several patterns to prevent Use After Free vulnerabilities. The most robust approach is to use async/await consistently and ensure all response operations complete before sending:

app.get('/api/safe-pattern', async (req, res) => {
  try {
    const data = await processRequest(req);
    const result = await transformData(data);
    res.json(result);
  } catch (err) {
    console.error('Processing error:', err);
    res.status(500).json({ error: 'Processing failed' });
  }
});

This pattern ensures the response isn't sent until all async operations complete successfully or fail gracefully.

For middleware chains, use Express's built-in error handling and request lifecycle management:

function validateInput(req, res, next) {
  if (!req.body || !req.body.id) {
    return res.status(400).json({ error: 'Missing ID' });
  }
  next();
}

function processData(req, res, next) {
  try {
    const result = performProcessing(req.body);
    req.processedData = result;
    next();
  } catch (err) {
    next(err);
  }
}

app.post('/api/protected',
  validateInput,
  processData,
  async (req, res) => {
    try {
      const finalResult = await saveToDatabase(req.processedData);
      res.json(finalResult);
    } catch (err) {
      next(err);
    }
  }
);

Express's error-handling middleware provides a clean way to handle failures without leaving resources in indeterminate states:

app.use((err, req, res, next) => {
  console.error('Unhandled error:', err);
  if (!res.headersSent) {
    res.status(500).json({ error: 'Internal server error' });
  }
});

For database operations, use connection pools with proper lifecycle management:

const pool = mysql.createPool({
  connectionLimit: 10,
  waitForConnections: true,
  queueLimit: 0
});

app.get('/api/db-safe', async (req, res) => {
  let connection;
  try {
    connection = await pool.getConnection();
    const [rows] = await connection.execute('SELECT * FROM users');
    res.json(rows);
  } catch (err) {
    res.status(500).json({ error: 'Database error' });
  } finally {
    if (connection) connection.release();
  }
});

middleBrick's continuous monitoring in Pro tier can automatically scan your Express APIs on a schedule, alerting you when new UAF patterns emerge in your codebase as it evolves.