Wouldn't it make sense to publicly disclose the common vulnerabilities and exposures so we all can examine the issue?

@guest271314 No, vulnerability reports should be discussed privately until maintainers provide a fix. Also if there is no response from the maintainers (in ~1month), then the vulnerability can be public so that users are aware of the issue.

Interesting philosophy. I would just expose the exploit so users in the field can be aware that they are running software vulnerable to exploits and maintainers can also know they are producing code with vulnerabilities. Full disclosure all the way around. No secrets.

We follow best practices from other source: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
So If they don't respond in time, we will make the vulnerability details public(similar to Google's Project Zero).

Right, the 2d option is full disclosure. It is possible that users and/or developers in the field can come up with a fix that maintainers have not thought about. Anyway, I'll check out what's going on here when the details are made public.

@guest271314 Now you can check the details :)

Reproducible with node v23.0.0-nightly202407272d1b4a8cf7 on Linux.

$ curl --path-as-is 0.0.0.0:8888/../../../../../../../../../../../../../../../../../../../etc/hostname
user

I converted the script to use Ecmascript Modules instead of CommonJS.

This also fixes the issue

  var filename = `./${new URL(request.url, import.meta.url).pathname}`;

by using the base parameter to URL() constructor https://developer.mozilla.org/en-US/docs/Web/API/URL/URL, import.meta.url, and prefixing the filename variable with ./

Static file server running at
  => http://localhost:8888/index.html
CTRL + C to shutdown
.//etc/hostname
File doesn't exist:.//etc/hostname

$ curl --path-as-is 0.0.0.0:8888/../../../../../../../../../../../../../../../../../../../etc/hostname
404 Not Found