Worth noting this is not a new vulnerability, it’s an analysis of a vulnerability found in December:
Following the security disclosure published in the v8.8.9 announcement
https://notepad-plus-plus.org/news/v889-released/
the investigation has continued in collaboration with external experts and with the full involvement of my (now former) shared hosting provider.According to the analysis provided by the security experts, the attack involved infrastructure-level compromise that allowed malicious actors to intercept and redirect update traffic destined for notepad-plus-plus.org. The exact technical mechanism remains under investigation, though the compromise occured at the hosting provider level rather than through vulnerabilities in Notepad++ code itself.
So the exploit redirected update traffic. Does that mean anyone who ran updates in that time period could have downloaded a compromised version and their machine would be infected?
Why isn’t that covered in the post?
Yes, that’s what it means.
And apparently, it happened selectively, not generally, but for specific people/request sources.
It would only be if you use the Notepad++'s own update mechanism. If you used other package managers or went and downloaded the installer to update you’d be fine.
First thing I do every time I (manually) update notepad++ is turn off automatic updates. Automatic updates are the root of all evil
It bothers me that there are so many typos in this post. Doesn’t N++ have spellcheck?
How many times has this happened to Notepad++ now?
Once
“The exact technical mechanism remains under investigation, though the compromise occured at the hosting provider level rather than through vulnerabilities in Notepad++ code itself. Traffic from certain targeted users was selectively redirected to attacker-controlled served malicious update manifests.”
Fuckall they could really have done about it other than changing host providers, which they mentioned they already have as a result.
Sign the updates before uploading them so they can’t be faked?
It’s astounding this wasn’t done years sooner to be honest. I mean, signing software with keys is not something invented recently. Not doing so is akin to storing passwords in plain text.
I think they want to, but Microsoft has made it expensive for open source developers who do this as a hobby and not as a job to sign their software. I know not too long ago, this particular dev was asking its users to install a root certificate on their PC so that they wouldn’t have to deal with Microsofts method of signing software, but that kind of backfired on them.
Yes, but from what I understand this refers to the automatic update functionality and not Microsoft’s own .exe signature verification thing.
Couldn’t you do it like this:
- Put hardcoded key into N++
- If a new release is available: Download, then verify signature
- If the signatures match, do whatever Windows requires to install an update
That should work, shouldn’t it?
Let’s Encrypt is a trusted, established alternative, it could replace Microsoft for long-lived software certificates.
Or tarnish its name associating it with malware and bad actors, who knows?
Let’s Encrypt is a trusted, established alternative, it could replace Microsoft for long-lived software certificates.
Uh, no it could not.
First of all, the whole point of signing software is to ensure it comes from a reputable source. Let’s Encrypt signs certificates with an automated process that does no verification whatsoever of the identity of the person asking for a certificate. It would make the whole process completely pointless.
Second, Let’s Encrypt has stated themselves over a decade ago that they have no intention of doing this because it would render the whole system pointless.
The point of signing software is to ensure the software was not tampered from the publisher. Linux package managers solve this by comparing a gpg key from the publisher with the software’s. There is no need for a corporate giant to “vet” software.
Cryptography is hard and programmers are notoriously really really really bad at it.
Note on timelines: The security exper’s analysis indicates the attack ceased on November 10, 2025, while the hosting provider’s statement shows potential attacker access until December 2, 2025. Based on both assessment, I estimate the overall compromise period spanned from June through December 2, 2025, when all attacker access was definitively terminated.
I’m only aware of the one (somewhat extended) time described in the article. The dev(s?) has been upfront about what happened and provided updates as they learned more information, hence multiple headlines on the subject.
With these changes and reinforcements, I believe the situation has been fully resolved. Fingers crossed.
I remember a day when hackers used to be sponsored privately. /s
It used to be that being a ML (Malicious Linguist) in someones garage was the rage, now we got “Hackers with Chinese characteristics” smh
The incident began from June 2025. Multiple independaent security researchers have assessed that the threat acotor is likely a Chinese state-sponsored group, which would explain the highly selective targeting obseved during the campaign.
I do kind of wonder about the emacs package management infrastructure system. Like, if attacking things that text editors use online is an actively-used vector.
Text editors with plugin support as potential vectors of malware is a pretty well known problem. It’s why at the very least organisations should be auditing the plugins used and actively monitoring them.
Well now I’m nervous! My first instinct though is that the vast majority of Emacs packages are plain elisp, and Emacs users have a habit of cracking open and tinkering with their packages, so any malicious code ought to be spotted quickly.
With the native compiled modules however, it could be another story…
know this one was not their fault but i haven’t trusted np++ since the charlie hebdo stunt that made it look like the app was a virus.
