Manuel Roccon : 6 November 2025 06:58
A new vulnerability affecting Notepad++ was released in September. The vulnerability has been identified as CVE-2025-56383, and details can be found on the NIST website. CVE-2025-56383 is a DLL hijacking vulnerability affecting the Notepad++ text editor v8.8.3 and potentially later versions.
By exploiting this weakness, an attacker can trick the application into loading a malicious DLL that has the same name as a legitimate library required by the program (a common example involves DLL files in the plugins folder).
If the attack is successful, the malicious code executes with the same permissions as the user running Notepad++, allowing arbitrary code execution on the target system.
However, it is crucial to note that this CVE has been labeled “Disputed” by several sources.
This happens because the attack is actually only possible if the user has installed Notepad++ in a directory that, by mistake or misconfiguration, allows write access to non-privileged users.
In standard Windows installations, a normal user should not have permission to modify files in the program’s installation folder, which reduces the issue from an inherent software vulnerability to a risk resulting from an insecure operating system configuration.
A bit has been released that demonstrates with some screenshots how it is possible to perform DLL Hijacking of the NppExport.dll library visible in the link below in Notepad++.
DLL Hijacking is an attack method that exploits the way the Windows operating system searches for and loads dynamic link libraries (DLLs) that an application needs to run.
Essentially, an attacker tricks a legitimate application into loading and running a malicious DLL instead of the original, expected DLL.
DLL Hijacking is similar to DLL Injection but differs in its mechanism: DLL Injection is a generic technique that forces a running process to load an arbitrary (often malicious) DLL directly into memory, while DLL Hijacking exploits incorrect management of the search path of an existing or missing DLL to cause the malicious version to be loaded in its place.
Let’s analyze what is meant by DLL Hijacking and test it directly on Notepad++
There are several variations of this technique:
DLL Search Order Hijacking : Exploits the default Windows search order. The attacker places the DLL in a folder with precedence (for example, the same folder as the application executable).
DLL Side-Loading: A very common form. The attacker copies a legitimate, trusted executable (for example, a digitally signed program) and its malicious DLL (with the name of the expected DLL) to an external folder, often accessible to the user. The malicious code runs under the context of a trusted process, bypassing integrity-based or executable whitelist security checks.
DLL Substitution: A more aggressive and direct approach where the attacker bypasses the search order to overwrite the original, legitimate DLL with a malicious file in the exact same path.
Phantom DLL Hijacking: This exploits an application that attempts to load a DLL that doesn’t exist on the system (perhaps due to a programming error or an unnecessary dependency). The attacker places the malicious DLL with the missing filename, forcing it to load.
When an application needs to load a DLL and does not specify its full, absolute path, Windows searches a set of predefined directories in a specific order.
The search order for DLLs (which can vary slightly depending on loading APIs and system configurations) typically includes:
An attacker then exploits this sequence to place a malicious DLL (with the same name as the missing, expected, or replacing legitimate DLL) in one of the directories that Windows controls before the location of the real DLL.
When the application is started, Windows finds and loads the malicious DLL before reaching the location of the legitimate DLL (or by loading a different DLL if it has been replaced).
The malicious code inside this DLL is then executed, often with the same privileges as the application that loaded it.
This technique is popular among attackers because it allows them to:
Stealthy Execution: Malicious code runs inside the process of a legitimate (often even signed) application, making it difficult to detect by traditional antivirus or monitoring systems.
Persistence: Once placed, the malicious DLL can ensure that the attacker’s code is re-executed every time the legitimate application is launched.
Privilege Escalation: If the legitimate application runs with elevated privileges (for example, as SYSTEM), the malicious code will also inherit those same privileges.
This example is very simple and we will use Notepad++ to analyze this attack method.
We will replace the original library with one containing only a payload that will start the calculator.
In this case we use the script below to generate a new DLL where in the MAIN there is a payload that will be launched.
#include #include void Payload() { STARTUPINFO si; PROCESS_INFORMATION pi; char cmd[] = "calc.exe"; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); CreateProcess(NULL, cmd, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi); } BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { switch (fdwReason) { case DLL_PROCESS_ATTACH: Payload(); break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: break; } return TRUE; }Then we compile the library using mingw32-gcc.
x86_64-w64-mingw32-gcc -shared -o NppExport.dll version.c
After replacing NppExport.dll and starting the application, the calculator opens.
Unfortunately the application detects something related to the library and returns an error.
The reason is very simple: it does not contain the original exports, so there is a check that warns you of this, an obstacle we will see how to overcome in the next step.
Despite this error, Notepad++ continues to run normally.
It should be noted that in other cases this replacement could result in a critical error and stop the application from running, as it contains essential functions for the application itself.
The previous example showed how to compile a new library and replace the original one so that the app can execute malicious content. However, this replacement could cause the application to crash or generate various errors.
So let’s look at a DLL hijacking technique via proxy. DLL hijacking by proxy is an advanced cyberattack technique that allows an attacker to execute malicious code within a legitimate application without causing the program to crash or terminate.
The concept is very simple.
Here is a simplified diagram of the procedure:
Let’s analyze in practice what this attack consists of, for convenience we will take an existing repo that contains everything we need for this purpose.
https://github.com/tothi/dll-hijack-by-proxying
Let’s clone the project.
Inside there is a basic library (which we used in the previous example) for executing a payload once it is loaded into the app.
We take the DDL to be hijacked, in this case NPPExport.dll which has been renamed.
We generate the version.def file containing the export redirects via the Python script through the deng_def.py script.
The .def file contains a section called EXPORTS that lists all the functions the DLL needs to expose, so you can pipe them back to the original legitimate DLL.
Already from here you can see that various function names are redirected to NppExport_orig.dll.
Finally, we compile the library using mingw-w64:
The compilation options are similar to the first example, but in this one we are going to add the definitions of the additional exports that this library needs (version.def)
Now we place the new library next to the modified original one
NppExport.dll will proxy all exported function calls to the legitimate NppExport_orig.dll file, preventing applications from reporting malfunctions.
If we run the software, no errors will be given and the malicious code will execute correctly.
Manuel Roccon