CVE-2026-48770

What it actually does

This is a local memory-corruption/availability flaw in Notepad++ before version 8.9.6.1. A process running in the same interactive Windows session can send a malformed WM_COPYDATA message through the COPYDATA_FULL_CMDLINE handling path. The vulnerable handler appears to treat COPYDATASTRUCT.lpData as an unbounded NUL-terminated wide-character string instead of respecting COPYDATASTRUCT.cbData, allowing malformed or unterminated data to cause out-of-bounds reads, instability, or a Notepad++ process crash. Based on the published CVSS vector, the known impact is denial of service against the local Notepad++ instance, with no confirmed confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash Notepad++, causing loss of unsaved work, interruption to developer or operator workflows, and reduced reliability on Windows workstations where vulnerable versions are installed. The risk is primarily local and opportunistic because the attacker must already be able to run code in the same user session and the user must have Notepad++ active or interact with it. Although the CVSS score is moderate and EPSS is low, organizations with broad Notepad++ deployment should still patch because the fix is straightforward and the flaw can be abused by local malware or nuisance tooling to disrupt users.

How an attack unfolds

An attacker first obtains the ability to execute a local process under the same interactive Windows session as the user running Notepad++. The attacker then locates the Notepad++ window or process and sends a crafted WM_COPYDATA inter-process message using the COPYDATA_FULL_CMDLINE path. The message supplies a COPYDATASTRUCT where lpData points to malformed wide-character data and cbData does not properly bound the string as the vulnerable handler expects. Because affected Notepad++ versions process lpData like an unbounded NUL-terminated wchar_t* rather than enforcing cbData, the application can read beyond the intended buffer and crash. There is no public indication from the supplied data that this is exploited in the wild, used by ransomware, or reliably weaponized for code execution.

How to fix it

Upgrade Notepad++ to version 8.9.6.1 or later. Where centralized software management is used, push the updated package to all Windows endpoints and remove or replace portable copies of Notepad++ older than 8.9.6.1. If immediate upgrade is not possible, reduce exposure by preventing untrusted local code execution, limiting interactive desktop access, controlling user-writable application directories, and using endpoint controls to block suspicious processes from sending Windows messages to unrelated GUI applications where feasible. Mitigation should not be treated as equivalent to patching because the vulnerable parsing behavior remains present in older versions.

How to confirm the fix worked

Confirm the installed Notepad++ version is 8.9.6.1 or later from the application About dialog, installed software inventory, package manager records, or by checking the file version of notepad++.exe. Search endpoints for unmanaged or portable Notepad++ binaries outside standard installation paths, especially copies under user profile, downloads, desktop, tools, or archive directories. Validate that software deployment tooling reports successful upgrade across managed Windows systems. For exposure testing, verify that versions prior to 8.9.6.1 are no longer present rather than attempting to reproduce the crash in production.

Typical attack path

1. Gain local code execution in the same interactive Windows session as a user running Notepad++.
2. Enumerate the Notepad++ process or window handle.
3. Construct a malformed WM_COPYDATA message targeting the COPYDATA_FULL_CMDLINE handler.
4. Set COPYDATASTRUCT.lpData to malformed or unterminated wide-character data and provide a misleading or insufficient cbData value.
5. Send the message to the Notepad++ window.
6. Trigger memory corruption or out-of-bounds processing that causes Notepad++ to become unstable or crash.

How to detect it

There is no reliable network-level indicator because exploitation is local inter-process messaging inside an interactive Windows session. To assess whether exploitation may have occurred, review Windows Application logs, Windows Error Reporting artifacts, EDR telemetry, and process execution history for Notepad++ crashes on versions prior to 8.9.6.1. Focus on repeated notepad++.exe application crash events, crashes shortly after unknown or suspicious local processes start in the same user session, and binaries or scripts containing strings such as WM_COPYDATA or COPYDATA_FULL_CMDLINE. Useful log sources include Windows Event Log Application events for application errors and WER reports, EDR process creation and cross-process interaction telemetry, Sysmon process creation events if deployed, and filesystem artifacts under Windows Error Reporting report archives. Because normal plugin faults or application bugs can also crash Notepad++, correlate crash timing with newly executed local tools, user-writable paths, suspicious command lines, and any evidence of custom automation targeting GUI windows.

• Faulting application name: notepad++.exe
• APPCRASH notepad++.exe
• notepad++.exe stopped working
• Windows Error Reporting\ReportArchive\AppCrash_notepad++.exe
• Windows Error Reporting\ReportQueue\AppCrash_notepad++.exe
• WM_COPYDATA
• COPYDATA_FULL_CMDLINE
• COPYDATASTRUCT
• notepad++.exe

What your security team should do

• Prioritize upgrading Notepad++ to 8.9.6.1 or later across managed Windows endpoints.
• Inventory for portable or user-installed Notepad++ copies that may not appear in normal installed-program records.
• Monitor Windows Application event logs and Windows Error Reporting for unusual or repeated Notepad++ crashes, especially when correlated with recently started unknown local processes in the same user session.
• Treat exploitation evidence as a possible sign of existing local malware or unauthorized tooling, because the attacker must already be able to execute code locally.
• Harden endpoint controls to reduce local code execution from user-writable paths and untrusted downloads.
• Educate support teams that repeated Notepad++ crashes on older versions may indicate exploitation or malformed local automation rather than a normal application defect.