Double Free in Express with Dynamodb

Double free is a memory safety class issue that can manifest in native addons rather than in JavaScript itself. When an Express application uses the AWS SDK for JavaScript (v2 or v3) to interact with DynamoDB, the runtime may ultimately invoke native C++ bindings. If an application or one of its dependencies improperly manages references to request or response objects across asynchronous boundaries, the same native object can be freed more than once, leading to crashes or undefined behavior that may be observable as inconsistent responses or process termination.

In the Express + DynamoDB context, this exposure typically arises from misuse of callbacks, promises, or event handlers that keep references to request-scoped objects. For example, attaching the same DynamoDB document client instance or request object to multiple response callbacks without ensuring proper lifecycle management can create conditions where cleanup routines attempt to release the same native memory more than once. A common pattern that increases risk is creating a DynamoDB client once at the module level and reusing it across many requests while also attaching multiple asynchronous listeners to the same request or response objects. If an error path and a success path both trigger a finalization routine on the same native object, the double free becomes reachable.

Consider an Express route that initiates a DynamoDB get operation and also attaches a listener to the response object. If an early validation error triggers a synchronous cleanup and the asynchronous DynamoDB call also attempts to clean up the same native structures, the runtime may attempt to free the same memory twice. This is particularly relevant when integrating third-party middleware that manipulates response objects or when using libraries that assume exclusive ownership of native resources. The AWS SDK for DynamoDB does not manage JavaScript memory for you; it relies on the underlying runtime and your code to avoid retaining or reusing objects after they are logically complete.

An illustrative risky pattern involves creating a shared DynamoDB document client and attaching multiple hooks to the same response, where one hook sends the result and another attempts to modify or finalize the response in the event of an error. If both hooks eventually trigger native cleanup on the same request context, the conditions for a double free are present. Real-world triggers include unhandled promise rejections combined with custom error handlers that attempt to clean up resources already released by the SDK, or middleware that calls next() after having already written and ended the response.

To detect such issues, middleBrick scans unauthenticated endpoints that use DynamoDB and flags inconsistencies in authentication, authorization, and input validation that can amplify memory safety risks. While middleBrick does not perform source or memory analysis, it correlates findings such as missing validation on DynamoDB inputs, missing rate limiting, and improper error handling that can lead to complex lifecycle interactions increasing the chance of double free conditions in native dependencies.

Remediation focuses on ensuring each native resource is finalized at most once by controlling object lifetimes and avoiding shared mutable state across asynchronous boundaries. Use locally scoped clients where appropriate, ensure a single code path handles both success and error cleanup, and avoid attaching multiple asynchronous listeners to the same response object.

Instead of a long-lived DynamoDB DocumentClient attached to the module scope, create a client scoped to the request or ensure that callbacks are not invoked multiple times. Below is a safer pattern for Express routes using the AWS SDK v3 DynamoDB client, which avoids shared mutable state and ensures a single resolution path per request.

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb";
import express from "express";

const client = new DynamoDBClient({ region: "us-east-1" });
const ddbDocClient = DynamoDBDocumentClient.from(client);

const app = express();

app.get("/item/:id", async (req, res, next) => {
  const { id } = req.params;
  if (!id || typeof id !== "string") {
    return res.status(400).json({ error: "Invalid id" });
  }

  const command = new GetCommand({
    TableName: process.env.DYNAMO_TABLE,
    Key: { id: { S: id } },
  });

  try {
    const response = await ddbDocClient.send(command);
    if (!response.Item) {
      return res.status(404).json({ error: "Not found" });
    }
    // Map DynamoDB JSON format to plain JS if needed
    const item = response.Item;
    res.json({ id: item.id?.S, value: item.value?.S });
  } catch (err) {
    next(err);
  }
});

app.use((err, req, res, next) => {
  // Single error handling path; avoid sending or ending response multiple times
  if (res.headersSent) {
    return next(err);
  }
  console.error(err);
  res.status(500).json({ error: "Internal server error" });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => console.log(`Server running on port ${PORT}`));

This pattern ensures that the DynamoDB client is reused safely at the module level while each request performs its own send operation with a fresh command. Validation occurs before the DynamoDB call, and a single error handler prevents multiple responses. Avoid patterns where both the DynamoDB callback and an explicit response end call are attached to the same request.

Additionally, prefer promises or async/await over legacy callback APIs to reduce the risk of multiple invocations. If you must use callbacks, ensure you nullify references after completion and avoid storing the same request object in multiple places. middleBrick’s scans can highlight missing validation and error handling patterns that may contribute to lifecycle issues, helping you identify risky integrations before deployment.

For teams using the GitHub Action, you can add API security checks to your CI/CD pipeline to flag risky validation and error-handling configurations. The CLI allows you to scan endpoints from the terminal and output JSON for scripting, while the Web Dashboard helps track scores over time. The MCP Server enables scanning APIs directly from your AI coding assistant, supporting safer development workflows when integrating DynamoDB with Express.