CVE-2026-53632

What it actually does

The vulnerable versions of the Node.js launch-editor package accept arbitrary file paths, including Windows UNC paths such as \\host\share\file. On Windows, resolving a UNC path causes the operating system to initiate SMB authentication to the referenced remote host. If an attacker can cause launch-editor to open an attacker-controlled UNC path, the victim system may automatically send an NTLMv2 challenge-response hash to the attacker's SMB server. The attacker does not directly receive the plaintext password, but may be able to crack the captured hash offline or use it in related credential attacks depending on environment controls.

Why it matters to the business

Successful exploitation can expose Windows user credentials, especially for developers or operators running Node.js-based tooling. Compromised credentials can lead to unauthorized access to source code, internal systems, build infrastructure, or other corporate resources if the account has meaningful privileges. The issue is not listed in CISA KEV, has low current EPSS, and has no reported mature public exploit in the provided data, but credential exposure bugs can become high-impact when they affect domain-joined Windows workstations or privileged users.

How an attack unfolds

An attacker first identifies an application, development server, framework integration, or tool path that passes user-controlled file names into launch-editor. The attacker then supplies a Windows UNC path pointing to an SMB server they control, for example a path beginning with double backslashes. When a Windows user triggers the vulnerable open-in-editor behavior, launch-editor attempts to open that path. Windows treats the path as a network share and automatically performs NTLM authentication to the attacker's SMB listener. The attacker captures the NTLMv2 challenge-response and then attempts offline password cracking. If the password is cracked, or if other NTLM abuse paths are possible in the environment, the attacker may use the credential to access additional systems.

How to fix it

Upgrade launch-editor to version 2.14.1 or later wherever it is used, including transitive dependency instances in development tools and framework packages. Review package-lock.json, yarn.lock, pnpm-lock.yaml, and dependency trees for vulnerable launch-editor versions, and use dependency overrides or resolutions if an upstream package has not yet updated. Rebuild and redeploy affected tooling after the dependency update. As defense in depth, block outbound SMB from workstations and build systems to the Internet, restrict NTLM where possible, require strong passwords resistant to offline cracking, and prefer Kerberos-only or NTLM-restricted configurations for domain environments. If immediate upgrade is not possible, disable features that open editor paths from untrusted input and reject UNC paths before invoking launch-editor.

How to confirm the fix worked

Confirm that dependency resolution shows launch-editor version 2.14.1 or later using commands such as npm ls launch-editor, yarn why launch-editor, or pnpm why launch-editor. Inspect lockfiles to ensure no vulnerable version remains. Perform a controlled negative test on a Windows test host by attempting to pass a UNC path to the affected open-editor workflow and confirming it is rejected or sanitized and does not initiate outbound SMB. Validate network controls by confirming Windows workstations and build hosts cannot make outbound TCP/445 connections to untrusted networks. Review CI builds, developer tool bundles, and packaged applications to ensure the updated dependency is actually present after rebuild.

Typical attack path

1. Set up an attacker-controlled SMB listener capable of capturing NTLM authentication attempts.
2. Find a vulnerable Node.js workflow or web development feature that invokes launch-editor with a user-influenced file path.
3. Send or inject a UNC path such as \\attacker-host\share\file into the vulnerable path-handling flow.
4. Induce a Windows user to trigger the open-in-editor action, often through a development UI, error overlay, link, or crafted input.
5. Capture the victim's NTLMv2 challenge-response when Windows attempts SMB authentication to the remote UNC path.
6. Attempt offline cracking of the captured hash or use the credential material in follow-on access attempts if feasible.

How to detect it

Look for signs that Windows hosts running Node.js or developer tooling attempted SMB authentication to unusual or external systems shortly after opening files from a development UI or editor integration. Useful sources include endpoint detection telemetry, Windows Security logs, Microsoft-Windows-SMBClient logs, firewall logs, DNS logs, proxy logs where applicable, and packet capture or NetFlow records. Focus on outbound TCP/445 or TCP/139 from node.exe, npm-launched processes, IDEs, or editor processes to unfamiliar hosts. Investigate Windows events showing explicit credential use or NTLM authentication to non-corporate systems, and correlate with command lines or application logs containing UNC-style paths. If packet captures or SMB server logs are available, look for NTLMSSP negotiation or captured NTLMv2 challenge-response material associated with developer workstations. Because exploitation may only leak a hash and leave little application-level evidence, absence of local file changes does not rule out exposure.

• launch-editor
• \\\\
• NTLMSSP
• NTLMv2
• SMB2 SESSION_SETUP
• TCP/445
• TCP/139
• node.exe
• npm.exe
• Microsoft-Windows-SMBClient
• Event ID 4648
• Event ID 4624
• Event ID 4776
• Outbound NTLM
• Tree Connect Request

What your security team should do

• Inventory all repositories, developer tools, and build pipelines for launch-editor usage and prioritize Windows-exposed workflows.
• Upgrade launch-editor to 2.14.1 or later and enforce the fixed version with lockfile updates, dependency overrides, or software composition analysis policy.
• Block outbound SMB traffic, especially TCP/445 and TCP/139, from endpoints and build systems to the Internet and other untrusted networks.
• Harden NTLM by restricting outbound NTLM, auditing NTLM usage, and applying domain policies that reduce credential leakage risk.
• Search recent endpoint, DNS, proxy, firewall, and SMB client telemetry for unexpected outbound SMB connections from Node.js or editor-related processes.
• If suspicious NTLM leakage is suspected, reset passwords for affected users, review account activity, and investigate lateral movement opportunities associated with those accounts.