Skip to content

Node.js 24.18.0: The Quiet Security-First LTS Update

Node.js 24.18.0 Is Mostly Security Work, and That's Fine

Node.js 24.18.0 landed as an LTS update in June 2026. Most of it is crypto hardening and dependency bumps. Here's what actually matters for your apps.

· · 4 min read
A computer screen displaying lines of server-side JavaScript code

Quick Take

Node.js 24.18.0 shipped on June 23, 2026, as part of the v24 'Krypton' LTS line. It's not a feature-packed release. It's a security-and-maintenance one, and for production that's exactly what you want.

A Boring Release, and I Mean That as a Compliment

Node.js 24.18.0 came out on June 23, 2026, and if you skimmed the changelog you'd be forgiven for closing the tab. There's no headline feature here. No new global, no syntax you'll rewrite code for. It's crypto hardening, updated root certificates, and dependency bumps.

That's a good thing. This is the v24 "Krypton" line, the active Long-Term Support release, and LTS updates are supposed to be dull. You want the version running your production traffic to change as little as possible while quietly closing security holes. So let me pull out the handful of entries that actually matter.

A program running in a terminal on a computer screen
Photo by Rahul Mishra on Unsplash

The Security Work Is the Story

Most of 24.18.0 sits under the crypto and TLS umbrella. Root certificates got updated to NSS 3.123.1, which keeps your outbound HTTPS connections trusting the right certificate authorities. That alone is worth the upgrade, because stale root stores are the kind of thing nobody notices until a cert chain breaks.

Beyond that, the release hardens several internal structures against prototype pollution, a class of attack where a malicious object messes with prototypes it shouldn't touch. Node tightened the WebCrypto layer, CryptoKey algorithm slots, and KeyObject internal slots specifically. If you handle keys or run WebCrypto in any exposed path, this is quietly protecting you.

There's also forward-looking crypto. The release adds the TurboSHAKE and KangarooTwelve algorithms to the Web Cryptography API, and the bundled BoringSSL picked up support for the post-quantum ML-DSA and ML-KEM schemes. You probably won't touch these tomorrow. But post-quantum readiness landing in an LTS release means it'll be there, stable, when you do need it.

The Two Changes You Might Actually Feel

Two entries are marked SEMVER-MINOR, meaning they add capability without breaking anything.

First, the default Buffer.poolSize went up to 64 KiB. Node keeps a small internal pool for tiny buffer allocations, and a bigger pool means fewer trips to the allocator on workloads that churn through small buffers. Is this going to transform your throughput? No. But it's a free efficiency nudge for parsing-heavy or streaming code. The only thing to watch is a marginally higher memory floor in tight containers.

Second, HTTP gained a writeInformation method to send arbitrary 1xx status codes. If you've ever wanted to send a 103 Early Hints response to let a browser start preloading assets before your real response is ready, this is the clean way to do it. Niche, but genuinely useful for performance-minded APIs.

Rounding it out: the bundled npm moved to 11.16.0 and the embedded SQLite was patched to 3.53.1. The inspector can now expose precise coverage start to the JS runtime, which matters if you build tooling on top of Node's coverage data.

I keep a small checklist for releases like this, and it's short: does anything change how my code runs, does anything close a hole I care about, and does anything move a bundled dependency I pin. Here the answer is no, yes, and yes. That combination is my cue to upgrade without a second thought. The releases I slow down for are the ones that touch module resolution or the HTTP defaults, because those are where a silent behavior change hides. A crypto-and-dependencies patch like 24.18.0 doesn't carry that risk, so it goes straight to the front of the queue.

Colorful lines of source code on a dark editor background
Photo by Markus Spiske on Unsplash

Should You Upgrade?

If you're already on the v24 line, yes, and without much ceremony. Patch and minor updates inside a major version are backward compatible, so upgrade in a branch, run your tests, and ship. There's no behavior change waiting to bite you here.

If you're still on Node 20 or 22, 24.18.0 isn't the reason to jump, but it's a reminder that the v24 LTS line is stable and getting steady security attention. Just don't treat a patch release as a migration guide. The move from 20 to 24 removes require() for ES modules and drops several legacy globals, and none of that shows up in a 24.18.0 changelog. If that's your path, read our Node.js 20 to 24 migration guide first, then check the Node 24 features worth adopting once you're across. Planning to drop ts-node while you're at it? Node 24's native TypeScript support pairs nicely with the upgrade.

The short version: 24.18.0 is a maintenance release doing maintenance work. Install it, move on, and appreciate that your runtime spent its energy on your security instead of your changelog.

Frequently Asked Questions

Is Node.js 24.18.0 safe to upgrade to from an earlier v24 release?
Yes, for almost everyone. Patch and minor updates within the same major line are backward compatible by design, and 24.18.0 is dominated by security fixes and dependency bumps rather than behavior changes. The two SEMVER-MINOR additions, a larger default Buffer pool and a new HTTP 1xx helper, are additive. The safest path is still the usual one: upgrade in a branch, run your test suite, and watch CI before you ship.
Do I need to change code because Buffer.poolSize increased to 64 KiB?
No. The Buffer pool is an internal allocation optimization, and raising the default from 8 KiB to 64 KiB just changes how Node batches small buffer allocations under the hood. Your code behaves the same. The tradeoff is slightly higher baseline memory in exchange for fewer allocations on workloads that create many small buffers. If you run memory-constrained containers, glance at your RSS after upgrading, but most apps won't notice.
Should I be on Node 24 at all, or stay on Node 20 or 22?
Node 24 is the current active LTS, so it's the right target for new production work expecting multi-year support. Node 20 and 22 remain supported but are older LTS lines, and 20 in particular is heading toward end of life. If you're starting fresh, go to 24. If you're on 20 and upgrading, read the migration notes first, because the jump from 20 to 24 has real breaking changes that a patch release like 24.18.0 won't warn you about.