Skip to content

Node.js Trust Falls Dangerous Module Resolution on Windows#2108

Open
carlospolop wants to merge 1 commit intomasterfrom
update_Node_js_Trust_Falls__Dangerous_Module_Resolution_o_20260408_192638
Open

Node.js Trust Falls Dangerous Module Resolution on Windows#2108
carlospolop wants to merge 1 commit intomasterfrom
update_Node_js_Trust_Falls__Dangerous_Module_Resolution_o_20260408_192638

Conversation

@carlospolop
Copy link
Copy Markdown
Collaborator

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

  • Blog URL: https://www.thezdi.com/blog/2026/4/8/nodejs-trust-falls-dangerous-module-resolution-on-windows
  • Blog Title: Node.js Trust Falls: Dangerous Module Resolution on Windows
  • Suggested Section: Windows Hardening -> Windows Local Privilege Escalation (new page): "Node.js/Electron module resolution hijacking on Windows (C:\node_modules)" (cross-link from: Generic Hacking -> Uncontrolled search path element / hijacking patterns; and potentially from: Pentesting Web -> NodeJS Express as an ecosystem note)

🎯 Content Summary

Title/Topic
ZDI analyzes a systemic Windows local privilege escalation (LPE) pattern caused by Node.js module resolution behavior: when resolving packages, Node.js includes C:\node_modules in its default search path. This maps to CWE-427: Uncontrolled Search Path Element. Because low-privileged users can commonly create C:\node_modules on Windows, attackers can plant malicious modules that may be loaded by higher-privileged Node.js/Electron applicati...

🔧 Technical Details

Trick 1 — Abusing Node.js upward module resolution to reach a user-writable root path (CWE-427):
If a Node/Electron app performs a bare import like require('X') and the legitimate module is missing, Node searches node_modules up the directory tree and can eventually probe C:\\node_modules on Windows. If an attacker can create C:\\node_modules and place a file/module matching the missing name (e.g., C:\\node_modules\\X.js), Node will load and execute it. This yields local code execution and can become LPE when the victim process runs with higher privileges (admin, auto-start elevated context, etc.).

Trick 2 — Turning npm's optionalDependencies "silent catch" pattern into a reliable load primitive:
Many packages intentionally wrap optional imports in a try/catch (or equivalent) to continue when the module isn't installed. On Windows, this "missing module but continue running" beha...

🤖 Agent Actions

I’m mapping the repo first and then I’ll read the most relevant Windows, Node.js, and search-path hijacking pages before deciding where this belongs.
I’ve got the structure. Next I’m checking whether HackTricks already documents this as a Windows search-path hijack, a Node/Electron note, or both, so I can avoid duplicating existing material.
The existing Windows content covers DLL search-order hijacks well, but not this JavaScript module-resolution variant. I’m checking where HackTricks already keeps references and related ecosystem notes so I can keep the change in one file without breaking navigation or style.
I’ve settled on a single-file update in the Windows LPE methodology, next to the existing PATH hijacking material. I’m adding a focused subsection for C:\node_modules abuse plus the source links at the file’s References section.
The content is in place. I’m tightening one grep example now so the command syntax is cleaner and the final diff stays copy-paste friendly.
Updated README.md with a new Windows LPE subsection covering Node.js/Electron module resolution hijacking via C:\node_modules. I placed it next to the existing PATH DLL hijacking material so it sits with the other Windows uncontrolled search-path privesc patterns, and kept the addition technique-focused rather than CVE-focused.

The new content covers the upward node_modules search behavior, why optionalDependencies and silent require() failures make it exploitable on Windows, how to validate it with Procmon, a minimal exploitation pattern, and defender-focused detection/hardening notes. I also updated the file’s ## References section with the ZDI post plus Node.js, npm, and Procmon sources.

Verification: reviewed the diff and only README.md was modified. No tests were run.


This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

@carlospolop
Copy link
Copy Markdown
Collaborator Author

🔗 Additional Context

Original Blog Post: https://www.thezdi.com/blog/2026/4/8/nodejs-trust-falls-dangerous-module-resolution-on-windows

Content Categories: Based on the analysis, this content was categorized under "Windows Hardening -> Windows Local Privilege Escalation (new page): "Node.js/Electron module resolution hijacking on Windows (C:\node_modules)" (cross-link from: Generic Hacking -> Uncontrolled search path element / hijacking patterns; and potentially from: Pentesting Web -> NodeJS Express as an ecosystem note)".

Repository Maintenance:

  • MD Files Formatting: 972 files processed

Review Notes:

  • This content was automatically processed and may require human review for accuracy
  • Check that the placement within the repository structure is appropriate
  • Verify that all technical details are correct and up-to-date
  • All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant