Notepad++: A Harsh Lesson in Supply Chain Failures

Overview

On February 2, 2026, the developer behind the popular text editor Notepad++ announced that their application had been the target of a roughly 6-month campaign believed to be orchestrated by nation-state actors out of China (e.g., Lotus Blossom). There have been multiple 3rd party reports within the last week from vendors (Kaspersky, Validin, Censys, Rapid7) that document alleged attribution as well as multiple indicators and context that weren’t shared in the original developer announcement. The primary basis for the vendors’ assessment is believed to be related to the TTPs (e.g., MitM manipulation of update mechanisms), targeting, and what types of malicious payloads were delivered.

According to Hostinger, an unnamed vulnerability was exploited, and they provided no evidence for this claim. Issues related to the updater (Wingup) being MitM were documented as early as December 2, 2025, by Kevin Beaumont on his blog. The developer has migrated from their old platform (Hostinger) to a new host platform (Aqua Ray), and claims to have implemented additional measures to prevent this from happening in the future. However, by Notepad++’s own admission, certificate and signature verifications aren’t planned to be fully implemented until version 8.9.2 (current version as of this writing is 8.9.1).

In this blog, we will highlight the security-related issues that have long plagued this application, issues that ultimately led to a successful, long-term campaign that went unnoticed by the developer and its users for at least 6 months. Additionally, we will highlight the importance of using dynamic runtime risk metrics and real-time telemetry to effectively protect your devices against the real dangers of supply chain compromise.

Security-Focused Timeline

Notepad++ was originally released on November 24, 2003, by Don Ho, and as of this writing, the application continues to be open source, is available in 90 languages, and has more than 350 contributing developers on its primary GitHub repository. By all accounts, it is one of the most popular and widely used free Windows text editors available. The source code for the application was originally housed at SourceForge, but due to disagreements with how they bundled software packages, Notepad++ migrated to GitHub in June 2015. Since then, there have been 134 releases, most related to standard feature improvements and bug fixes. However, there were multiple key releases and related security issues identified that were the precursor for the eventual supply chain compromise, and as a result, made the long-lived campaign possible.

Outlined below is a timeline we created that elucidates the issues we intend to highlight. Although we mention items specific to the compromise/incident, we will primarily focus on the application’s development timeline.

Code signing

Version 8.8.2 was the first release in 9 years (since it was originally signed by a trusted CA) that was not signed; this version was released June 25, 2025. Don Ho mentioned in the release notes that the free signing certificate he had been previously gifted from DigiCert would not be renewed/reissued. Coincidentally, June 2025 is also when the months-long campaign initially began.

Later, in July of that same year, version 8.8.3 was released with a self-signed certificate. This release encountered multiple issues with AV scanners due to the nature of the certificate, and Don mentioned he was still working to acquire a certificate from a trusted Certificate Authority (CA). The release of version 8.8.7 on October 20, 2025, marked the first time since 8.8.2 that the Notepad++ binary would be signed using a certificate issued by a trusted Certificate Authority (GlobalSign)–roughly 3 months between releases. For clarity, this isn’t to say the releases weren’t signed with a GPG key (and have been for some time), but it’s important to highlight the major difference between a certificate issued by a Certificate Authority and an asc file generated by the developer.

Updating mechanisms

To understand how the supply chain compromise was successful, it’s important to understand how the update process works in the context of Notepad++. The updater component of the application, known as Wingup (Windows Generic Updater) (aka:gup.exe), is a side project of Don Ho originally developed to be used as an updating mechanism for any Windows-based application. Now, the code has been forked to be specific to the text editor and has had 27 releases under the current GitHub repository.

From the README within the repository (formatting added):

“WinGUp can be launched by your program or manually. It reads from a xml configuration file for getting the current version of your program and url where WinGUp gets update information, checks the url (with given current version) to get the update package location, downloads the update package, then runs the update package (it should be a msi or an exe) in question.”

Until version 5.3.7 of Wingup, the application lacked a mechanism to validate the download URL, and the threat actors took advantage of this fact when they compromised the Notepad++ server and redirected specific individuals and organizations to malicious payloads instead of the legitimate install package/update.

The fix for the URL validation was added in the 8.8.8 release of Notepad++, released on November 18, 2025. But it wasn’t until version 8.8.9 (released on December 9, 2025) of the application that the Wingup workflow would verify the signature and certificate of the installers downloaded during the update process before it would execute them. It was also in this release that the self-signed binaries finally ceased.

To sum up: an application that was originally released in November 2003 didn’t verify packages until December 2025, a 22-year delta, where attackers could have easily MitM update traffic and executed malicious payloads on a targeted organization or a broader demographic. It’s also important to note that even though this was a major security flaw, as of this writing, a CVE still hasn’t been issued for this context–meaning people who rely on CVEs as a reason to force mandatory updates are more than likely still running vulnerable versions.

What Your Vulnerability Tooling Should Tell You

Assessing risk shouldn’t be limited to which applications are installed, where they are installed, which versions are installed, and whether there are vulnerabilities. Unfortunately, this is where traditional vulnerability detection and prioritization tools generally stop.

With Spektion’s continuous monitoring of runtime behavior, we take it further by reporting risky runtime behavior that helps you assess what the application does, and more importantly, when it changes. We show you what the software and its plugins are executing before and during exploitation attempts. We keep track of outbound network communications that allow you to establish a baseline of network patterns over time so you can easily determine variance.

In the example of Notepad++, your organization would have known that assets were downloading malware instead of the most recent version of the application, and what commands the malware was executing. And finally, we document which executables make up a given application or tool–something your internal teams currently manage on their own. This is what runtime-based vulnerability management looks like for everything executing in your environment, so you can manage attack surface risk from software in the absence of CVEs or attack signatures.

Execution Behavior

Spektion surfaces risky behavior in software as it runs

Network destinations (external)

See software's network destinations in Spektion

Conclusion

In this blog, we took a brief look at design flaws in a widely used text editor that enabled a successful, now well-documented, supply chain compromise. Our intention isn’t to call out a specific application or group of contributors, but to highlight that even the most well-intentioned software developers can maintain a project for years in an insecure way.

Software development is hard. In the age of vibe coding, struggling TPRM teams, and an expanding attack surface, it’s increasingly difficult to stay informed of every risky application your company uses. There will always be insecure configurations, methods to MitM “secure” update channels, and that next CVE disclosure accompanied by a well-crafted logo. Informed risk assessment is about having a complete view of your enterprise, not just CVEs, and not just the next release, hoping it fixes all your security woes. Modern vulnerability and attack surface management needs an edge to stay one step ahead.