Notepad++ release 8.9.6.1

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…

PeterJones

@Coises said:

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.

I am leaning towards agreeing. I like the idea of granular control from my suggestion, because some user/admin might want it, I don’t know how important it would be. OTOH, making it easy for the installer checkbox, and thus easy for users to opt out of this fix, is definitely important.
.

xomx

@donho said:

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

So are you trying to fix a situation when a user (inadvertently) set for these N++ xml files a location, where also everyone else (instead of him or admins) has the write permission?

Coises

@xomx said:

@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)?

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.

Thank you for the clarification.

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…

That’s kind of why I wondered if the vulnerability was about a form of privilege escalation. If not…

You know, if someone gains write access to my desktop, they could replace my shortcut to Notepad++ with one that has the same name and icon but actually starts a malicious program. Shortcuts are a security risk! (/sarcasm… just in case)

donho

@xomx said:

So are you trying to fix a situation when a user (inadvertently) set for these N++ xml files a location, where also everyone else (instead of him or admins) has the write permission?

It is not the fix provided in v8.9.6.1, but it could be considered.

donho

I will see if I can treat only “-settingsDir=” & cloud option, and keep %appdata% case as before (without confirmation).

MarkusBodensee

@PeterJones said:

@Coises said:

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.

I am leaning towards agreeing. I like the idea of granular control from my suggestion, because some user/admin might want it, I don’t know how important it would be. OTOH, making it easy for the installer checkbox, and thus easy for users to opt out of this fix, is definitely important.
.

I like the idea of having a filled supressRunAlertDialog.xml, even if it may be a bit more difficult to implement, but on the other side:
There would be no need to add an option to the installer if the file should be installed or not. Just install/ship a prefilled file but with no added path by default and a user with admin rights can add the needed path. Or the file can be prefilled with all the program files path by default, so you don’t have to hard code them in source code. This way, admin in company environment would even be able to remove those paths at all if needed.