DEV Community: janardhan reddy

# JavaScript Finally Got Destructors, Sort Of, and Nobody Told Me For A Year

janardhan reddy — Tue, 04 Aug 2026 20:18:50 +0000

The Grafana alert said "connection pool: 100/100 in use." Nothing dramatic, no outage, just a slow climb over three days until a batch job started timing out waiting for a connection that was never coming. The culprit, once I actually went looking, was a helper function with an early return inside a try block, sitting above the finally that closed the connection. Somebody added that return six months earlier to handle an edge case, tested it, shipped it, and never noticed the finally two lines down had quietly stopped mattering for that one code path.

That bug is old as JavaScript itself. try/finally works fine until it doesn't, and it doesn't the moment your cleanup logic depends on every exit path being wired correctly by hand, forever, across every future edit. ES2026, ratified by ECMA International on June 30 this year, finally gives us a language-level answer: explicit resource management, via the using and await using declarations.

I'd seen the proposal floating around for a couple of years and mentally filed it under "neat, probably won't ship for a while." It shipped. Here's what it actually does.

The Problem It's Solving

Anything that needs cleanup, a database connection, a file handle, a lock, an event listener, a timer, has the same shape of risk. You open it, you use it, and somewhere along the way you need to close it, no matter how the function exits: normal return, early return, thrown error, whatever. try/finally is the tool for that today, and it works, but it's manual. Nest a few of these and the boilerplate multiplies:

async function processFile(path) {
  const file = await openFile(path);
  try {
    const conn = await pool.connect();
    try {
      const data = await file.read();
      await conn.query("INSERT INTO logs VALUES ($1)", [data]);
    } finally {
      conn.release();
    }
  } finally {
    await file.close();
  }
}

Every resource adds a nesting level. Every nesting level is a chance to close things in the wrong order, or forget one entirely when you're refactoring at 90 miles an hour.

What using Actually Does

The using declaration ties a value's lifetime to the scope it's declared in. When that scope exits, for any reason, the runtime automatically calls a disposal method on the value. No finally required.

class DbConnection {
  constructor(conn) {
    this.conn = conn;
  }

  query(sql, params) {
    return this.conn.query(sql, params);
  }

  [Symbol.dispose]() {
    this.conn.release();
    console.log("connection released");
  }
}

function run() {
  using conn = new DbConnection(pool.connect());
  conn.query("SELECT 1");
  // conn[Symbol.dispose]() runs automatically here,
  // even if an error was thrown above
}

Symbol.dispose is the new well-known symbol that makes an object "disposable." Anything implementing it can be declared with using, and the engine guarantees the dispose method runs when the block ends, whether it ends by falling through, returning, or throwing.

For anything where cleanup itself is asynchronous (closing a database pool that needs to flush, releasing a WebSocket that sends a close frame), there's await using, paired with Symbol.asyncDispose:

class FileHandle {
  constructor(handle) {
    this.handle = handle;
  }

  async read() {
    return this.handle.read();
  }

  async [Symbol.asyncDispose]() {
    await this.handle.close();
  }
}

async function processFile(path) {
  await using file = new FileHandle(await openFile(path));
  const data = await file.read();
  return data;
  // await file[Symbol.asyncDispose]() is awaited before this function
  // actually resolves
}

Rewriting the earlier nested example with both:

async function processFile(path) {
  await using file = new FileHandle(await openFile(path));
  using conn = new DbConnection(await pool.connect());
  const data = await file.read();
  await conn.query("INSERT INTO logs VALUES ($1)", [data]);
}

Two flat declarations instead of two nested try blocks. Disposal still happens in the right order too, reverse of declaration, so conn gets released before file gets closed, matching what the nested version did by hand.

One detail that trips people up the first time: using isn't a function call, it's a declaration keyword, sitting where const or let would go. The value on the right side of the assignment still has to actually implement Symbol.dispose or Symbol.asyncDispose. If it doesn't, you get a TypeError at the point of disposal, not at declaration, which is a slightly annoying place to discover a typo but at least it's loud about it. There's no ambiguity about ownership either. The variable declared with using owns the resource for the lifetime of that block, full stop, and nothing else needs to remember to release it.

DisposableStack, For When You Don't Know Up Front

Sometimes you're building up a set of resources conditionally and don't know at declaration time exactly what needs cleaning up. DisposableStack and its async counterpart exist for that:

function setupResources(options) {
  using stack = new DisposableStack();
  const conn = stack.use(new DbConnection(pool.connect()));

  if (options.needsCache) {
    const cache = stack.use(new CacheConnection());
  }

  return stack.move(); // hand off ownership, cleanup deferred
}

Everything pushed onto the stack gets disposed in reverse order when the stack itself is disposed, or you can call .move() to transfer ownership somewhere else without triggering cleanup yet. It's a small thing, but if you've ever written a setup function that had to manually track "which of these three things did I actually open before this one failed," you'll recognize the itch it's scratching.

Where This Actually Matters In A React/Next.js Codebase

Most day-to-day component code won't touch this directly, React's own cleanup model (the return function from useEffect) already handles the common case. Where using earns its keep is lower down: database clients in route handlers, file system operations in build scripts, worker threads, anything talking to Node's fs, net, or a database driver that exposes disposal hooks. A few libraries have started shipping Symbol.dispose support on their client objects already, and more will as this settles in. If you maintain an internal wrapper around a connection pool or a temp file utility, that's a reasonable place to add [Symbol.dispose] now and get the syntax for free later.

Browser support and Node support both landed before the June ratification (engines had been shipping it behind flags for a while, since TC39 proposals at Stage 3 are considered stable enough to implement early), so this isn't a "wait three years" situation. Check your target runtime version, but the practical answer for most Next.js apps on recent Node is: it already works.

One catch if your team runs a shared TypeScript config: you'll need a recent target and lib setting for the compiler to recognize using and the two new well-known symbols. Older tsconfig presets copied from a project started a couple of years back won't know what to do with the syntax and will just error out, which looks scarier than it is. Bump the lib target, and it resolves itself.

So Was It Worth The Wait

Kind of. It doesn't fix bugs that already shipped, my connection pool leak from three paragraphs ago is exactly as leaked whether or not using exists, because it was written before this landed and nobody's going back to rewrite working code just because a nicer syntax showed up. What it does is remove the specific failure mode where correctness depends on a human remembering to nest try/finally correctly across every edit forever. That's a real thing to fix. It's also, in the end, syntax sugar over a pattern good engineers already enforced by hand and via linters.

I added Symbol.dispose to our internal db client wrapper this week. It shaved about four lines off each call site. Not a revolution. Just fewer chances to leave a connection open at 3 AM.

Your Middleware Is Not a Security Boundary (59,000 Servers Just Found That Out)

janardhan reddy — Tue, 04 Aug 2026 20:05:32 +0000

3:47 AM, and a pager alert for unusual traffic on /api/admin/*. Routes that should have been sealed off behind middleware.ts, returning a clean 401 to anyone without a session cookie. Except the logs showed 200s. Hundreds of them, from IPs that had never touched the app before, all hitting the same handful of admin endpoints within a ten minute window.

That's roughly how a lot of security teams spent a night in early December 2025, when a campaign researchers later named Operation PCPcat started chewing through Next.js deployments. In under 48 hours it compromised more than 59,000 servers, stealing somewhere between 300,000 and 590,000 credential sets out of environment files, SSH keys, and cloud service tokens. A success rate over 64 percent. Each infected box scanning for new targets every 45 minutes, which is the kind of detail that makes you close your laptop and stare at the wall for a minute.

The vulnerability at the center of it, CVE-2025-29927, wasn't exotic. It came down to a single internal header, x-middleware-subrequest, that Next.js used to avoid infinite loops when middleware triggers its own rewrites. The framework trusted that header completely. It never checked whether the header actually came from Next.js itself or from a random curl command on the internet. Send the right value, and the runtime would skip your entire middleware chain, auth checks included, like they were never there.

If you're the kind of developer who put all your access control logic in middleware.ts because it felt clean and centralized (and, hand up, that used to be me), this is the part that stings.

Why Middleware-Only Auth Was Always A Bit Fragile

Middleware in Next.js runs at the edge, before a request ever reaches your route handler or page. That's exactly why it's tempting as an auth gate: one file, one place to check the session, and every downstream route inherits the protection. It looks like a security boundary. It behaves like a security boundary, most of the time.

But middleware is still application code, executing inside the same runtime as everything else, reachable by the same request that everything else sees. It isn't a firewall rule sitting outside your app's blast radius. It's a function that runs early. And any function that runs early can, in principle, be convinced not to run at all, whether through a header trust issue like this one, a misconfigured matcher pattern, or just a route added later that nobody remembered to protect.

The patched versions (12.3.5, 13.5.9, 14.2.25, 15.2.3, and later) fixed the header trust problem specifically. Good. Update your dependencies, obviously. But patching one bug in the gate doesn't change the fact that you built a single gate.

What Actually Held Up

The apps that shrugged this off weren't the ones with the fanciest middleware. They were the ones that treated middleware as a UX optimization (redirect unauthenticated users before they waste a full render) and kept the real authorization check inside the code path that actually touches sensitive data.

Something like this, in a route handler:

// app/api/admin/users/route.ts
import { getSession } from "@/lib/auth";

export async function GET(req: Request) {
  const session = await getSession(req);

  if (!session || session.role !== "admin") {
    return new Response("Unauthorized", { status: 401 });
  }

  const users = await db.user.findMany();
  return Response.json(users);
}

That check runs regardless of whether middleware executed, got bypassed, got skipped by a header nobody asked for, or simply wasn't matched because of a routing quirk. It's redundant with the middleware check, on purpose. Redundant is the point. Defense in depth is a cliche because it keeps being true, not because anyone enjoys writing the same if statement twice.

None of this is theoretical hand waving about "best practices," by the way. The teams that got hit hardest by PCPcat were, almost without exception, running the exact self-hosted, standalone-output configuration this CVE targets, with nothing checking authorization below the middleware layer. Once the header trick worked, the request landed directly on a route handler that assumed, wrongly, that it would never be reached by anyone who hadn't already cleared the gate upstream. The handler itself had no opinion about who was asking. That's the actual failure, not "someone forgot to patch," though that mattered too. The architecture had exactly one checkpoint, and the checkpoint had exactly one weakness.

Same idea applies one layer down, at the data access function itself:

export async function getUsersForAdmin(session: Session | null) {
  if (session?.role !== "admin") {
    throw new Error("Forbidden");
  }
  return db.user.findMany();
}

Now even if some new route handler forgets to check the session (it happens, someone's always in a hurry to ship a dashboard widget), the data layer still refuses to hand out rows it shouldn't. You end up with three places doing the "are you allowed to see this" check: middleware for the fast redirect, the handler for the request-level gate, and the query function for the last line of defense. Slower to write. Much harder to accidentally leave a hole in.

The Part Where I Admit The Old Way Was Convenient

I get why middleware-only auth spread. It's less code. Fewer places to remember to add a check when you're cranking out a new admin route at 6 PM on a Thursday because product wants it demoed Friday morning. Centralizing the logic in one file felt like good engineering, and honestly it read well in code review. "Look, one middleware function, protects everything under /admin." Nobody asks the follow-up question of what happens if that one function gets bypassed, because until December 2025 that wasn't really a live scenario most teams had internalized.

It is now. The attackers behind PCPcat weren't picking apart bespoke logic, they were running the exact same header trick against every vulnerable Next.js app they could find, automatically, at scale. If your only defense was "middleware checks the cookie," and middleware could be told to sit this one out, there was nothing behind it.

A Short List Of Things Worth Checking This Week

If you're running self-hosted Next.js with output: standalone (the Vercel-hosted deployments were not affected by this particular CVE, for what it's worth), confirm you're on a patched minor version. Then go look at whatever routes matter most, the ones touching PII, admin actions, billing, and ask whether the authorization check would still fire if middleware silently didn't run. If the honest answer is "no, it's middleware or nothing," that's worth an afternoon of refactoring before it's worth an incident review.

None of this is a knock on middleware as a tool. It's genuinely great for redirects, locale detection, feature flag routing, all the stuff that's annoying without it. It's just not a wall. It's a hallway monitor. Useful, but you still want a lock on the actual door.

There's also a quieter lesson buried in here about how we talk about architecture in code review. "Centralized" got treated as a synonym for "secure" for a long time, and those aren't the same property. A single checkpoint is easier to reason about, easier to test, easier to point to in a design doc. It is also, definitionally, a single point of failure. Sometimes the right tradeoff really is one central gate, especially for low-stakes routes. For anything touching money, PII, or admin capability at a payments company, the tradeoff isn't close. You want the boring, repetitive, slightly annoying version where three layers each independently refuse to hand over data to someone who shouldn't have it.

I patched our stuff, added the redundant checks, and went back to arguing about whether we needed another loading skeleton component. Turns out most weeks are still mostly that.