Notepad++ release 8.9.6.1

donho

Notepad++ release 8.9.6.1 is available:

https://notepad-plus-plus.org/news/v8961-released/

Notepad++ v8.9.6.1 vulnerability fixes:

Fix bad formed COPYDATASTRUCT makes Notepad++ crash (CVE-2026-48770).
Fix arbitrary code execution vulnerability via config.xml (CVE-2026-48778).
Fix arbitrary code execution vulnerability via shortcuts.xml (CVE-2026-48778).

Notepad++ v8.9.6. regression fixes, bug-fixes:

Fix vulnerability (CVE-2026-46710) of v8.9.4 & v8.9.5 installer. (Implement commit)
Fix x86 installer regression of not showing installation entry in “Unstall a program” of Control Panel. (Fix community discussion)
Fix x86 installer regression where context menu not installed or uninstalled correctly. (Fix community discussion)
Fix UAC prompt display regression (“Notepad++ installer” instead of “Notepad++”) for Notepad++ v8.9.5. (Fix GitHub comment)
Fix incorrect bevaviour when saving dirty read-only files. (Fix #17956)
Fix regression where saving a UDL file removed XML declaration. (Fix GitHub comment)

Notepad++ v8.9.5 regression fixes, bug-fixes & new improvements:

Fix updating issue where using v8.9.4 32-bits installer creates duplicate “Uninstall a program” entries. (Fix #17979)
Fix v8.9.4 64-bits installer error message caused by MSIX on Win10. (Fix installer regression)
Fix regression in UDL xml file EOL parsing issue. (Fix #18022)
Update Scintilla to 5.6.2 & Lexilla to 5.4.9. (Implement #18011)
Add option to synchronize zoom level across views. (Fix #17862)
Fix MSI installer writting language info to HKCU instead of HKLM. (Fix MSI issue)
Fix imported UDLs not appearing in the language menu without restarting Notepad++. (Fix #17909)
Make “(?)” tooltip in preferences & Find in Files dialogs persitant & reduce display delay. (Fix #17995, #16961)
Fix visual glitch in Mark dialog when in reduced mode. (Fix #17983)

Notepad++ v8.9.4 crash-fixexs, bug-fixes & new improvements:

Fix crashes in FindInFiles when nativeLang.xml’s “find-result-hits” contains “%s”. (Fix #17960, CVE-2026-3008, CVE-2026-6539)
Fix drop-file crash when file path length reaches 259 characters. (Fix #17921)
Fix crash caused by undoing column editor bad input in virtual space. (Fix #17915)
Fix bad column editor input in reverse-direction column selection on virtual space. (Fix #17915)
Update to Scintilla 5.6.1 & Lexilla 5.4.8. (Fix #17920, #17864, #13522, #11746)
Fix EOL conversion to Windows format not working (Scintilla update related). (Fix #17920)
Fix rendering corruption in .bat files (Lexilla update related). (Fix #17864)
Fix quote escaping causing incorrect JSON syntax highlighting (Lexilla update related). (Fix #11746, #13522)
Fix MSI installation error due to context menu item registration. (Fix #17918)
Fix NSIS installation stalling caused by context menu registration issue. (Fix #17308, #17885)
Add NPP_LANG property to install a specific localization file for MSI. (Fix issue reported in comment)
Fix MSI installer display random Hexadecimal number as name on UAC. (Fix #17967)
Add version info into MSI file property (as value of “Comments”). (Fix #17803)
Fix minimized window not restoring in administrator mode. (Fix #17945)
Fix Unicode search mismatching ANSI character ‘?’. (Fix #17125)
Fix Column Editor regression with empty fields. (Fix #17912)
Fix floating dialog content not displaying in certain situations. (Fix #17563)
Fix visual glitch when toggling group view in Document List. (Fix #14285)
Support improved C++ 11 raw string literal handling. (Fix #17875)
Fix visual glitch in the Mark dialog. (Fix #16084, #17886)

For security reason, this version was released in a rush, without nofifying the community.

PeterJones

From what I can tell, based on quick experiments, deriving implications to what @donho said and the commits that fix those CVE:

Fix arbitrary code execution vulnerability via config.xml

<GUIConfig name="commandLineInterpreter">"C:\path\with spaces\to\cli.exe"</GUIConfig> in config.xml will no longer do anything
instead, there is a “open into PowerShell” alongside all the menus that have “open into cmd” (or similar phrasing for that command in the various menus and context menus)

Fix arbitrary code execution vulnerability via shortcuts.xml

Any shortcuts that start with http: will be flagged, and you will be prompted to confirm every time.
Any shortcuts that resolve to an executable location outside of the trusted locations (whether by relying on PATH, or by harcoding the path to the executable), will warn you every time you try to run that command. (Trusted locations include Program Files or Program Files (x86) or windows\system32 or windows\ directories).

:-(

I think the remediation to this one takes things too far. Not all compilers, interpreters, and helper programs live in the Program Files or Windows hiearchies (I personally have another location where I often install such things). And now you are going to ask me to confirm I want to run my external application every single time I try to run it, with no way to say “always allow” to that dialog. This will cause a major headache for anyone who, like me, intentionally runs things that don’t live in Program Files. That will not result in increased security: that will result in driving users away from Notepad++ if they can no longer use the automation features of the application.

For example, Strawberry Perl, the primary Perl interpreter installation for Windows, installs into c:\strawberry by default, and parts of its toolchain have problems if you install into a directory like c:\program files\ with spaces in the filename; there are lots of engineering tools I have used that have problems with spaces in the path as well; and since I also use the gcc that comes with Strawberry Perl, that means that both my Perl interpreter and my C/C++ compiler that I use from Notepad++ will ask me to confirm every time. I’m really not sure that’s a usable workflow for me. Am I not going to ever be able to upgrade beyond Notepad++ v8.9.6? If not, that will be unfortunate.

donho

Note:
For fixing arbitrary code execution vulnerability via config.xml, “commandLineInterpreter” was removed, but “PowerShell here” command has been added, so I don’t think it’ll be an issue, though users who use “commandLineInterpreter” should be notified.
However, we might have some complains for fixing arbitrary code execution vulnerability via shortcuts.xml, due to the security warning, if the binary is not located under one of the fowing loctions:

C:\Program Files,
C:\Program Files (x86)
C:\Windows\System32
C:\Windows

Unfortunately, I haven’t yet found a way to store the definate “Never show the confirmation dialog” safely. Please let me know if anyone here has some ideas.

donho

@PeterJones said:

:-(

How about an empty supressRunAlertDialog.xml besides of notepad++exe to suppress the warning dialog?

fml2

When installing the latest version (8.9.6.1) I get the following error which I’ve never seen before:

Does anybody have a clue about this?

donho

@fml2
Which installer did you use?

fml2

@donho The one I downloaded from the official web site https://notepad-plus-plus.org/downloads/v8.9.6.1/ (64 bit).

PeterJones

@donho said:

How about an empty supressRunAlertDialog.xml besides of notepad++exe to suppress the warning dialog?

I think that should work:

in a normal install, that would be in the safe/UAC-protected Program Files hierarchy, so couldn’t be created by a malicious actor without UAC
it would allow someone with admin privileges to make the executive decision to disable that safety feature

It could, in theory, be made more fine-grained – the XML could contain actual information, such as a list of “additional safe directories” (like Excel allows you to specify so that you can run VBA macros even if your file is in an alternate location), so your for-loop across the safe directories could include those from that file.

The empty file would obviously be easier to implement, but I would be fine with either solution. (And given how many CVE’s have been fixed in v8.9.4-v8.9.6.1, I don’t think my complaint about this one should prevent triggering auto-update, since I make do with existing until v8.9.7)

donho

@fml2 ,

The one I downloaded from the official web site https://notepad-plus-plus.org/downloads/v8.9.6.1/ (64 bit).

I know.
What I need to know as information is, x64 or x86? NSIS exe Installer or MSI?

donho

@PeterJones said:

It could, in theory, be made more fine-grained – the XML could contain actual information, such as a list of “additional safe directories” that Excel allows you to specify so that you can run VBA macros even if your file is in an alternate location, so your for-loop across the safe directories could include those from that file.

The empty file would obviously be easier to implement, but I would be fine with either solution. (And given how many CVE’s have been fixed in v8.9.4-v8.9.6.1, I don’t think my complaint about this one should prevent triggering auto-update, since I make do with existing until v8.9.7)

The empty XML file is not only easier to implement, but it is also the only viable solution IMO. I considered storing a list of user-validated commands, or even a simple boolean like “Never Alert Dialog” inside config.xml - but obviously config.xml is not in a protected directory, as described in CVE-2026-48778.

OTOH, supressRunAlertDialog.xml solves the issue - it can be placed by users with admin rights to restore the old behaviour back (no confirmation dialog), and we can also include it in the installer (WITHOUT by default) so the previous behaviour can be restored during the installation - with the user’s awareness.

Sorry for breaking the old workflow - but I cannot simply ignore this vulnerability. The reporter will publish it in 3 months anyway, with or without a fix, and it is a valid issue.

PeterJones

@donho said:

the only viable solution IMO

It’s not the only viable solution. The exception list could go in suppressRunAlertDialog.xml in the Program Files directory – so the user with Admin/UAC could edit the list, but a normal user could not – and this is what I was trying to imply with my phrasing above, but apparently didn’t get that point across. There is zero difference in security between an empty suppressRunAlertDialog.xml in Program Files and a suppressRunAlertDialog.xml in Program files containing actual XML data with the list of files.

But as I said, I’d be fine with the simpler version.

fml2

@donho x64, installer (exe)

donho

@PeterJones
Could you pass me an example you would use for you in supressRunAlertDialog.xml?

PeterJones

@donho ,

Could you pass me an example you would use for you in supressRunAlertDialog.xml?

My thought was something like,

<?xml version="1.0" encoding="UTF-8" ?>
<NotepadPlus>
    <RunMenuSafeDirectories>
        <RunDirectory>C:\Users\peter\AppData\Local\Programs\Python\Python314\</RunDirectory>
        <RunDirectory>c:\strawberry\perl\</RunDirectory>
        <RunDirectory>c:\strawberry\c\</RunDirectory>
    </RunMenuSafeDirectories>
</NotepadPlus>

or

<?xml version="1.0" encoding="UTF-8" ?>
<NotepadPlus>
    <RunMenuSafeDirectories>
        <RunDirectory path="C:\Users\peter\AppData\Local\Programs\Python\Python314\" />
        <RunDirectory path="c:\strawberry\perl\" />
        <RunDirectory path="c:\strawberry\c\" />
    </RunMenuSafeDirectories>
</NotepadPlus>

(whether you prefer storing the data in the content or in an attribute)

These directories could then be added to the list of “safe directories” that you used in isInTrustedDirectory(), so that those directories (and their subdirectories) would be considered “safe”, too.

Since that XML would still be in Program Files, it would have the same level of security as a zero-byte file in the same directory, but give more granular control, so that the advanced user with UAC/Admin privileges could define certain directories that they want to consider safe, while still not allowing all directories to be in the path (thus, an attempted shortcuts.xml injection would have to know that on my system, I only allowed files in those specific extra paths, which I would presumably have some sort of protection on, so that they couldn’t be added to without my knowledge).

But again: I understand triggering v8.9.6.1 for auto-update without waiting for this; this would be a new feature of v8.9.7 instead. And, after looking at my suggestion, if you still decide that you wanted just the simple empty file, that will work; I just think this would be better for allowing better control, so that the unsafe-directory notification wasn’t an all-or-nothing prospect.

Coises

@donho said:

supressRunAlertDialog.xml solves the issue

I am wondering about something here… I’m not sure if this is a problem or not, and I hope you’ll forgive me, but it would take me a lot longer to rearrange my system to test it that it will probably take for someone who already knows how this works to consider it.

The alert dialog is, I gather, raised by Notepad++. Consider this condition:

Notepad++ is installed on a corporate-managed workstation which is fairly locked down.
Users’ ability to execute programs is restricted; they cannot execute an arbitrary program from an arbitrary directory (so they can’t install their own programs, even as portables), but they can execute Notepad++.

Does this vulnerability mean that a user, by manipulating the shortcuts file (and responding OK to the prompt in 8.9.6.1), would be able to execute an arbitrary program from an arbitrary directory (as it would be executing under the control of Notepad++, which has already been whitelisted)? Or would there still be a UAC prompt that the user could not satisfy?

As you can imagine, I ask because if this represents a work-around for executing forbidden programs, it could become a reason system administrators would consider Notepad++ unsafe to install.

PeterJones

@Coises said:

Does this vulnerability mean that a user, by manipulating the shortcuts file (and responding OK to the prompt in 8.9.6.1), would be able to execute an arbitrary program from an arbitrary directory (as it would be executing under the control of Notepad++, which has already been whitelisted)?

From my understanding, any “corporate management” system that would disallow running a specific executable by double-click or by command-line would also disallow it from running by ShellExecute. (if they didn’t, it would be an obvious hole that would have already been violated, and would have nothing to do with Notepad++ specifically).

Or would there still be a UAC prompt that the user could not satisfy?

If the system were set up to require UAC to run “untrusted” apps (which is how it used to be for me), then I would think there would still be the UAC prompt.

I don’t think your scenario is feasible (any more so than using any app that embeds a shell-execute).

Coises

@PeterJones said:

If the system were set up to require UAC to run “untrusted” apps (which is how it used to be for me), then I would think there would still be the UAC prompt.

That’s good. Thanks for clarifying.

Then it seems like a “simple” implementation would be to let an empty supressRunAlertDialog.xml file work as @donho suggested, which would make it easy to create the installer checkbox he mentioned to restore old behavior.

Either at the same time, or as a later enhancement, it could be added that if the file exists and is not empty, it works as you suggested, for users who want finer-grained protection.

donho

@Coises said:

Does this vulnerability mean that a user, by manipulating the shortcuts file (and responding OK to the prompt in 8.9.6.1), would be able to execute an arbitrary program from an arbitrary directory (as it would be executing under the control of Notepad++, which has already been whitelisted)? Or would there still be a UAC prompt that the user could not satisfy?

As you can imagine, I ask because if this represents a work-around for executing forbidden programs, it could become a reason system administrators would consider Notepad++ unsafe to install.

The vulnerability fix ensures that any program launched by Notepad++ is invoked using an absolute path, preventing hijacking. If the path is not in a trusted directory, Notepad++ displays a confirmation dialog.
I have no information about the behaviour on a corporate-managed workstation that is fully locked down. If previous version of Notepad++ (<= v8.6.9) were able to launch arbitrary programs, then this release can do so as well - the only difference is that it now adds a confirmation dialog.

xomx

@donho said:

Fix arbitrary code execution vulnerability via config.xml (CVE-2026-48778 ).
Fix arbitrary code execution vulnerability via shortcuts.xml (CVE-2026-48778 ).

IMO this is not a security vulnerability. Abuse of N++, I’d say.

Let’s see the published attack vectors:

Direct write to %APPDATA%\Notepad++\config.xml (same user privilege)
Malicious .lnk shortcut with -settingsDir= pointing to attacker-controlled directory
Archive extraction to AppData via social engineering

If someone can do arbitrary writes to my Windows user profile (or persuades me to do it for him via that mentioned social engineering), then such an attacker can easily do also other mischievous things, e.g. redirecting my user environment variables like %PATH%, where I can have paths to executables…

So if this is marked as Arbitrary Code Execution CVE, then it’s like patching up a small hole in a dam that just burst.

Cloud sync poisoning (NPP supports cloud choice path, Parameters.cpp:1386)

If someone gets into my cloud, then I have a bigger problem than a mischievous modification of some path.

Ditto the shortcuts.xml stuff.

I agree with @peterjones , I also like to launch any executable from the N++. And I like to point my shortcuts to any executable too.

@Coises said:
Notepad++ is installed on a corporate-managed workstation which is fairly locked down.

Users’ ability to execute programs is restricted; they cannot execute an arbitrary program from an arbitrary directory (so they can’t install their own programs, even as portables), but they can execute Notepad++.
Does this vulnerability mean that a user, by manipulating the shortcuts file (and responding OK to the prompt in 8.9.6.1), would be able to execute an arbitrary program from an arbitrary directory (as it would be executing under the control of Notepad++, which has already been whitelisted)?

No. If an app is not on a whitelist (realized e.g. by Windows App Control for Business), it should not be executed (even from a whitelisted app).

Or would there still be a UAC prompt that the user could not satisfy?

This is other thing. UAC gets in the way whenever an action is required to be performed with higher than the current privileges. So if an attacker creates e.g. that config.xml “commandLineInterpreter” redirection to his “mycmd.exe”, UAC shows up e.g. if that mycmd.exe has a manifest within with higher execution level requested.

donho

@xomx
The configuration files (config.xml, shortcuts.xml & others) could reside on any location with cloud option or by “-settingsDir=” command argument…