Notepad++ release 8.9.6.1

donho

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

donho

I implemented another solution that removes the annoying requirement of adding authorized directories.
This solution was suggested by the security expert who reported CVE-2026-48800.

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.

xomx

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

fml2

@donho I unchecked the plugins item (i.e. all of them); the installation completed then.

donho

@fml2
Did you check if NppExport.dll is read-only in your system?

androidec50

@donho you forgot to update/upload this new minor version to winget microsoft repository?

Until now I only can find 8.9.6.

Thank you so much.

donho

@xomx

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.

xomx

@donho

Ok, fair enough. So you assume that someone could hack into a user’s cloud account and modify there the stored N++ configuration files to be then abused later by running N++ on the user’s local PC, right?

I can only object to this that such a capable attacker may not be immediately stop by this, because there are certainly ways for reaching this MachineGuid. Now I can think of:

as the MachineGuid seems not to be considered as a secret key or such (as pwds or private certs), you can just try to read that regkey remotely (ok, not likely exploitable, as the local RemoteRegistry service has to be running, FW not blocking it, etc.):

$reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', "FULL_PC_NAME")
...

it’s much more likely that the victim’s GUID will be inadvertently leaked - e.g. through some third-party diagnostic (e.g. I know that MalwareBytes Support Tool collected also this info and its users were routinely posting such logs on the helping forums)
tracking/fingerprinting abusing - many commercial apps and game devs abuse that value for HW-id bans/trials and if such a SW sends this GUID to its servers unencrypted via HTTP, it may be then captured on the net
or a common cloning mistake where IT admins forget to run the Sysprep tool before creating a disk image and then have the same GUID on many PCs in the org…

xomx

@androidec50 said:

forgot to update/upload this new minor version to winget microsoft repository?

Until now I only can find 8.9.6.

winget is maintained by MS staff and/or bot.

donho

@xomx

From the scenarios you described, HMAC is not infaillible. However, just because the burglar is cabable of anything does not mean I leave my door unlocked when I leave home.

Also you make valid points. The MachineGUID is not a cryptographic secret, and it was never designed to be one.
But it’s still better to use the MachineGUID than to rely sorely on sha256 of shortcuts.xml. Not only does HMAC make tempering with shortcuts.xml more difficult, but it also prevents attackers from pre-computing the sha256 value of the factory-default shortcuts.xml.

As a result, I believe HMAC is a suitable solution: it prevents the most effortless forms of shortcuts.xml tempering, and under normal circumstances users are not disturbed.