CVE-2026-105482: Node.js Trusts a Name It Never Looked Up
On October 21, 2026, Node.js released security fixes for ten flaws across its three supported versions. One of them, CVE-2026-105482, is a problem in the way Node.js looks up domain names.
Summary
- First Seen
- October 21, 2026
- Affected Product
- Node.js
On October 21, 2026, Node.js released security fixes for ten flaws across its three supported versions. One of them, CVE-2026-105482, is a problem in the way Node.js looks up domain names. If a hostname contains a null byte, Node.js quietly cuts the name short at that point, so an application can check one domain and then look up a completely different one. That breaks any service keeping a list of allowed domains: the check passes, but the lookup goes wherever the attacker chose. Node.js calls this an incomplete fix of CVE-2026-48930, which covered dns.lookup() but not dns.resolve*(), dns.reverse(), or the Resolver class, so services using dns.lookup() are not affected.
CVEs
| CVE | Name | Affected product | Zero-day | CISA KEV | Patch |
|---|---|---|---|---|---|
CVE-2026-105482 | Node.js DNS Null Byte Truncation Vulnerability | OpenJS Foundation Node.js | No | No | Yes |
Vulnerability Details
CVE-2026-105482 is a flaw in how Node.js looks up domain names, rated High by the vendor. In JavaScript, a null byte, written as \x00, is just another character, so a hostname carrying one passes through your code as written. Node.js then hands that name to c-ares, a library written in C, where a null byte means the end of the text. Everything after it is dropped, with no warning. The name your code checked, and the name actually looked up can therefore be two different things. Node.js fixed this same problem once before in CVE-2026-48930, but only for dns.lookup() and the net and tls host options. The dns.resolve*() family, dns.reverse(), and the Resolver class were missed, so the trick kept working through them. If you patched that earlier CVE and thought the issue was closed, it was not.
The attack is simple and needs no login or special access. An attacker sends a hostname like attacker.example\0.trusted.example to any input that reaches those functions. Your code sees a name ending in a trusted domain and allows it. The resolver drops everything after the null byte and looks up attacker.example instead. A public write-up proves this works end to end, with the DNS query reaching a server the attacker controls.
Node.js 26.x, 24.x, and 22.x are affected, with fixes in 26.12.1, 24.22.1, and 22.23.4. Older lines such as 25.x, 23.x, 21.x, and 20.x get no fix and stay vulnerable, so the only option there is moving to a supported line. The flaw sits in the runtime itself, not in any package you install, so every container image, bundled app, nvm install, and serverless function carries its own copy.
There is no sign of attacks in the wild, and this was not a zero-day. It was reported privately and fixed ahead of the October 21 release. What changes the picture is that a working proof of concept is now publicly available, with the full steps laid out. Once a PoC is in the open, the chances of exploitation rise sharply, because an attacker no longer has to find the flaw or work out how to trigger it. The attack needs only one crafted parameter and no account, so patching should be treated as urgent rather than routine.
Vulnerabilities
| CVE ID | Affected products | Affected CPE | CWE ID |
|---|---|---|---|
CVE-2026-105482 | OpenJS Foundation Node.js 26.x (Before 26.12.1), Node.js 24.x (Before 24.22.1), Node.js 22.x (Before 22.23.4) | cpe:2.3:a:nodejs:node.js:*:*:*:*:*:*:*:* | CWE-284 |
Recommendations
- 01Upgrade the Runtime Without DelayMove every Node.js installation to
22.23.4,24.22.1, or26.12.1, depending on the line you run. The vendor has published no workaround, so upgrading the runtime is the only complete fix. If you are on 25.x, 23.x, 21.x, or anything 20.x and older, there is no patch coming and you need to migrate to a supported line instead. - 02Find Every Copy of the Runtime, Not Just the Obvious OneBecause the flawed code lives in the runtime rather than in a package, auditing your dependency manifests will tell you nothing. Inventory Node.js wherever it hides, including container images and running containers, single-executable applications, runtimes installed through version managers such as nvm, application-local folders, secondary drives, and serverless functions such as AWS Lambda runtimes. A patched host with an unpatched container image on it is still exposed.
- 03Rebuild, Redeploy, and Restart After PatchingUpgrading the binary on disk is not enough for anything already running. Rebuild container images and single-executable applications on the fixed version and redeploy them, then restart long-running services so they load the new runtime rather than keeping the vulnerable one resident in memory. No operating system reboot is required, since Node.js ships no kernel modules or drivers.
- 04Reject Null Bytes and Control Characters in HostnamesAs an interim control while you plan the upgrade, filter hostname inputs strictly and drop any value containing
\x00or other non-printable control characters before it resolves. Normalise the name to its canonical form first, then apply the allowlist check to the normalised value, so that validation and resolution operate on the same string. - 05Stop Trusting Suffix Checks on Their OwnTreat a simple
endsWith()style suffix match as insufficient for a trust decision about a domain. Where the design allows it, resolve user-supplied names withdns.lookup(), which is unaffected by this flaw, rather than thedns.resolve ()family, and validate against a parsed and normalised hostname rather than a raw string.
MITRE ATT&CK TTPs
References & Patch Links
References
What Next?
At Hive Pro, it is our mission to detect the most likely threats to your organization and to help you prevent them from happening.
.svg)