Node.js 24.22.2 closes a crash hole left by a stack-trace speed bump
A routine LTS patch that repairs a crash hiding behind enormous stack-trace limits.
Node.js published version 24.22.2 of its "Krypton" LTS branch on October 28, 2026, and the one change that matters most repairs a crash triggered by very large stack-trace limits. Core contributor Antoine du Hamel assembled the release with just six commits: five V8 backports and a single streaming fix. It looks like exactly the kind of routine weekly patch you'd scroll past. It's the patch you absolutely do not want to scroll past if your observability stack sets Error.stackTraceLimit to Infinity.
The regression traces back to an optimization Node.js shipped earlier this month to make stack-trace capture cheaper. The trimming logic multiplies the frame limit by a constant using signed 32-bit integer arithmetic. Set the limit high enough and the multiplication overflows. The result wraps negative, an internal assertion trips, and the process dies.
It only bites under specific conditions. You need to be capturing uncaught-exception traces, either with the --trace-uncaught flag or an attached inspector. That narrow window is probably why it slipped through testing in the first place.
The fix's author laid out the failure windows precisely. Anything up to about 358 million frames works fine. The crash window runs from 357,913,942 up through 715,827,882. A thin sliver just above that silently drops frames instead. Push past 1,789,569,707, which includes Infinity, and you crash again.
A speed bump that briefly broke the thing it sped up
The fix lives in the very same release as the optimization that caused the problem. The performance patch, PR #65764, was written by Marja Hölttä and Jakob Linke of Google's V8 team and pulled into Node by du Hamel. It arrived in response to an oddly transparent request filed under issue #64879, whose title was essentially a mission statement: "Backport v8 'Reduce stack frame summarization costs' patch for React development speedup."
The reasoning is sound. Building stack traces is a hot path, and frameworks like React throw and catch errors constantly, so anything that makes that path cheaper lands well. But that same change introduced the overflow. This release carries both the optimization and the fix, which makes it a handy illustration of how tightly bundled performance and correctness are inside V8.
The actual repair, in PR #66249, changes the math. Rather than multiplying first, V8 now compares the limit against the real number of captured frames and only multiplies once it's certain the limit is smaller. Overflow becomes impossible. The test they added confirms that limits of 858993460, 858993461, and Infinity now all behave identically to a limit of 10.
The other V8 change is subtler. PR #66241 by Victor Gomes keeps the new keyword off of WebAssembly call sites, so wasm frames show up consistently whether the code ran under Maglev or Ignition. It's a small fidelity win for code that mixes JS constructors with wasm calls, which is a fairly uncommon combination but easy to trip over in practice.
A streaming regression, quietly restored
The lone non-V8 change fixes an AsyncLocalStorage regression that Matteo Collina landed on October 25. It lives in the Web Streams API. When a TransformStream write parks itself on backpressure, it resumes later when the read side lifts that pressure. A prior change meant the parked write ended up running in the reader's async context instead of the writer's.
Collina's fix captures the context when the write parks and restores it on resumption. The before-and-after is easy to see: before the change everything reports as the default context, and after, everything reports as the writer, which is what the spec calls for. The bug dates back to 24.22.0, so this patch just restores expected behavior. A benchmark showed no performance hit, meaning the fix is essentially free.
Node.js 24 entered LTS on October 28, 2025 as version 24.11.0, right on schedule, and it's set to keep receiving updates through the end of April 2028. That makes 24.x a safe target for teams that value stability over new features. The line shipped with V8 13.6 for RegExp.escape and Float16Array support, npm 11 by default, a globally available URLPattern, and native .env support via the --env-file flag.
These past few weeks have been unusually busy for the Krypton line. 24.22.0 went out on October 14 with a batch of crypto, net, and sqlite additions plus the handy util.throttle and util.debounce helpers. 24.22.1 landed three days later as a dedicated security release, closing seven CVEs and upgrading OpenSSL to 3.5.9. This week's patch just rounds out the week.
For what it's worth, there's a detail here that has nothing to do with Node internals specifically. du Hamel is one of the most prolific people in the Node core group. If you've ever glanced at the Node.js pull-request log, you've likely noticed his username sitting near the top across nearly every category of change. It's a small reminder that a lot of the software running the internet gets kept alive by a handful of very busy people.
How to upgrade
Drop the latest 24.x into an existing project with whichever package manager you prefer:
npm install node@^24.22.2
You can also pin the version with nvm if you manage installations manually:
nvm install 24 --reinstall-packages-from=current
Head here to download the release.
