Passing malformed UNC hostname to pathToFileURL() crashes the process

Version

v25.9.0

Platform

Linux snoopy-MacBookPro11-4 6.17.0-19-generic #19~24.04.2-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar  6 23:08:46 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

node -e "const p='\\\\\\\\exa mple\\\\share\\\\file.txt'; console.log(JSON.stringify(p)); require('node:url').pathToFileURL(p,{windows:true});"

snoopy@snoopy-MacBookPro11-4:~/$ node -e "require('node:url').pathToFileURL('\\\\\\\\exa mple\\\\share\\\\file.txt',{windows:true})"; echo $?

  #  node[95573]: static void node::url::BindingData::PathToFileURL(const FunctionCallbackInfo<Value> &) at ../src/node_url.cc:172
  #  Assertion failed: out->set_hostname(hostname.ToStringView())

----- Native stack trace -----

 1: 0x90ace8 node::Assert(node::AssertionInfo const&) [node]
 2: 0xa2a2b7 node::url::BindingData::PathToFileURL(v8::FunctionCallbackInfo<v8::Value> const&) [node]
 3: 0x771269d8fb4d 

----- JavaScript stack trace -----

1: URL (node:internal/url:825:20)
2: pathToFileURL (node:internal/url:1659:12)
3: pathToFileURL (node:url:1022:10)
4: [eval]:1:21
5: runScriptInThisContext (node:internal/vm:219:10)
6: node:internal/process/execution:483:12
7: [eval]-wrapper:6:24
8: runScriptInContext (node:internal/process/execution:481:60)
9: evalFunction (node:internal/process/execution:315:30)
10: evalTypeScript (node:internal/process/execution:327:3)


Aborted (core dumped)
134
snoopy@snoopy-MacBookPro11-4:~/ node -v
v25.9.0
snoopy@snoopy-MacBookPro11-4:~/$

How often does it reproduce? Is there a required condition?

No require condition

What is the expected behavior? Why is that the expected behavior?

process shouldn't crash

What do you see instead?

process crash

Additional information

This could be considered denial of service, but reading https://github.com/nodejs/node/blob/main/SECURITY.md, hence opening a github issue. reading https://github.com/nodejs/node/blob/main/SECURITY.md probably a bug than a security issue

edit: confirmed with nodejs-wg team that they see it as a bug, reopening to keep track

url: process crash via malformed UNC hostname in pathToFileURL()

Confirmed — this is a crash-on-invalid-input (assertion DoS) in node:url's pathToFileURL when given a UNC path with a space in the hostname portion.

The assertion fires because ada::url::set_hostname() rejects the hostname "exa mple" (spaces are not valid in hostnames per RFC 3986) — but rather than gracefully throwing a TypeError, the C++ code hits a DCHECK/RELEASE_ASSERT which aborts the process.

Expected behavior: pathToFileURL('\\\\exa mple\\share\\file.txt', { windows: true }) should throw a TypeError (or ERR_INVALID_ARG_VALUE), not crash the process. Any untrusted input that can kill a Node.js process via assertion is a DoS vector.

The fix is in src/node_url.cc around line 172 — instead of DCHECK/asserting on the return value of set_hostname(), it should check the result and throw a proper JavaScript error:

// Instead of:
DCHECK(out->set_hostname(hostname.ToStringView()));

// Should be:
if (!out->set_hostname(hostname.ToStringView())) {
  THROW_ERR_INVALID_ARG_VALUE(env, "Invalid hostname in path: %s", path.c_str());
  return;
}

This pattern is used elsewhere in the codebase for URL validation failures.

url: process crash via malformed UNC hostname in pathToFileURL()

Navigation Menu

Repository navigation

Passing malformed UNC hostname to pathToFileURL() crashes the process #62546

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Passing malformed UNC hostname to pathToFileURL() crashes the process #62546

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

verysleepylemon commented on Apr 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions