The HMAC is only meant to protect against the -settingsDir= & settings on Cloud option vectors where the attacker prepares a malicious directory on a different machine — a USB drive, a downloaded archive, a network share. In that case they genuinely don’t know the victim’s MachineGUID and cannot forge the HMAC.

Until now I only can find 8.9.6.

Thank you so much.

@donho said:

The PR is ready for review now:
https://github.com/notepad-plus-plus/notepad-plus-plus/pull/18079

Please let me know your thoughts on this alternative enhancement.

This is classic security through obscurity (read - “no security at all”) or if you prefer a CWE-656. Or maybe I should rather use here “security through well-known obscurity”, because N++ is opensource, so anyone can easily do what I did below, STR:

• add a new shortcut to N++ shortcuts.xml via N++ menu > Run > Run…, enter there C:\Windows\System32\charmap.exe, click on Save…, enter a name for it, e.g. CharacterMap (you can also set a key-shortcut if you like, e.g. Ctrl+Alt+M seems to be free)
• the above will create new record in the N++ shortcuts.xml file (in my case: <Command Key="77" Shift="no" Alt="yes" Ctrl="yes" name="CharacterMap">C:\Windows\System32\charmap.exe</Command>)
• try it (e.g. via that Ctrl+Alt+M), the Windows CharMap should launch
• close N++
• go to where your N++ shortcuts.xml is and do the “evil” in question - e.g. modify the relevant line to <Command Key="77" Shift="no" Alt="yes" Ctrl="yes" name="CharacterMap">C:\Windows\System32\cmd.exe</Command>
• relaunch N++, press again that Ctrl+Alt+M, you should see the new warning:
  
  and the shortcuts.xml will be opened for you to review (DO NOT VALIDATE IT now, remember - we want to play here as the “attackers” do…)
• instead of validating via the N++ menu > Run > Validate shortcuts.xml, just close the N++ app for now

In the next steps we manually mimic (as a potential attacker also can) what the N++ app validation does:

• in the dir with your current N++ shortcuts.xml, create and launch this batch:

@echo off
setlocal enabledelayedexpansion

set "FILE_PATH=shortcuts.xml"

if not exist "%FILE_PATH%" (
    echo Error: Notepad++ file not found - "%FILE_PATH%"
    pause
    exit /b 1
)

echo.
echo Processing file: %FILE_PATH%
echo.

powershell -NoProfile -Command "$guid = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Cryptography').MachineGuid; $guid | Out-File 'MachineGuid-key.tmp' -Encoding ascii -NoNewline; $hmac = New-Object System.Security.Cryptography.HMACSHA256; $hmac.Key = [System.Text.Encoding]::UTF8.GetBytes($guid); $hash = [System.BitConverter]::ToString($hmac.ComputeHash([System.IO.File]::ReadAllBytes('%FILE_PATH:\=\\%'))).Replace('-','').ToLower(); $hash | Out-File 'HMAC.txt' -Encoding ascii -NoNewline;"

set /p SECRET_KEY=<MachineGuid-key.tmp
set /p HMAC_RESULT=<HMAC.txt
del MachineGuid-key.tmp

echo Secret-Key (MachineGuid): %SECRET_KEY%
echo HMAC-SHA256 Signature:    %HMAC_RESULT%
echo.
echo HMAC saved to: %cd%\HMAC.txt
echo.

endlocal
pause

• open the generated HMAC.txt file (e.g. in Windows Notepad app)
• open there also your current N++ config.xml file, edit the relevant line, mine was:
  <GUIConfig name="shortcutsXmlHMAC" value="5b3ed06c526a812cc93e147d5243adb0eded6b7529a59883977f480985bc360e" />, use your HMAC from the manually generated HMAC.txt file
• save N++ config.xml file
• relaunch N++, try Ctrl+Alt+M again (now no warning - an attacker silently fooled us to run whatever he wants, here only the cmd.exe instead of charmap.exe)

I’ll repeat myself here - the fixed CVE is not a security vulnerability! @coises has above another great example - modify in the same way e.g. the N++ shortcut on the Desktop (and be surprised that instead of notepad++.exe, you will launch whatever else…)

N++ is a powerful tool, like a sharp knife. And like with the sharp knife, users can “cut themselves” if not handled properly (allowing anyone else than me or admins to write to my N++ config.xml & shortcuts.xml…).

The idea is as follows:
We use the user’s machine GUID to generate a HMAC of shortcuts.xml, and store this value in config.xml. Each time a customized command is launched, Notepad++ recalculates the HMAC of the current shortcuts.xml content on HD, and compare it with the stored value.

If the HMAC in config.xml is missing or does not match, the shortcuts.xml file will be opened for review and a warning dialog is displayed, and the user must validate (and possibly modify) the file. Otherwise no command will not be executed.

The PR is ready for review now:
https://github.com/notepad-plus-plus/notepad-plus-plus/pull/18079

Please let me know your thoughts on this alternative enhancement.

@fml2 said:

@donho x64, installer (exe)

That’s strange. I really don’t see how the 3 vulnerability fixes could impact NppExport.dll during the installation.

What does it happen if you uncheck NppExport plugin during the installation?

@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.

@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.

@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 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 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.
.

@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.

@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.

@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.

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

@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.

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.

@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.

@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.