Malware News Notepad++ updater installed malware

Screenshot_2-2-2026_181234_x.com.jpeg
 
Last edited by a moderator:
Notepad++ addressed a flaw in its updater that allowed attackers to hijack update traffic due to improper authentication of update files in earlier versions.

Beaumont explained that although downloads are signed, older Notepad++ versions used a self-signed root certificate publicly available on GitHub, weakening validation. Because traffic to notepad-plus-plus.org is rare, ISP-level redirection is feasible for well-resourced actors.

 
  • Like
Reactions: Sorrento
Just had to look as I'm using an alternative Notepad, & its Notepad Classic, this is why this forum is so useful as I may not know of such things.
I have been using notepad++ for many years and still use it. I have even donated them twice. But i still use it despite this disclosure. Fortunately in Q2 2025, i was not hit by their updater malware as i use winget to update my apps.
 
winget tells me where file is being fetched from which is github in this case.
The source of update file for Notepad ++ was not the problem; the file was downloaded from their own server, but it was tampered, as far as I can get.

If it is a dns spoofing, it would be blocked by secure dns provider.
 
  • HaHa
Reactions: Khushal
The source of update file for Notepad ++ was not the problem; the file was downloaded from their own server, but it was tampered, as far as I can get.

If it is a dns spoofing, it would be blocked by secure dns provider.
I suppose u reread my comments and the article for more details but when i have mentioned github, i think it was clear what the problem was. The vuln was in Wingup not in Winget so i don't know what are u talking about. If i am downloading from Winget a microsoft certified app from github another Microsoft owned site how the hell it can be dns spoofing etc. I fortunately was able to reduce the attack vectors by avoiding Wingup and using Winget.
Also it is almost certain it is act of a Chinese Apt group which used such advanced TTPs.
 
I suppose u reread my comments and the article for more details but when i have mentioned github, i think it was clear what the problem was. The vuln was in Wingup not in Winget so i don't know what are u talking about. If i am downloading from Winget a microsoft certified app from github another Microsoft owned site how the hell it can be dns spoofing etc. I fortunately was able to reduce the attack vectors by avoiding Wingup and using Winget.
Also it is almost certain it is act of a Chinese Apt group which used such advanced TTPs.
However, is still unclear how attackers hijacked updater traffic in the wild. Beaumont speculates threat actors may have intercepted traffic at the ISP level to deliver malicious updates, though this would require substantial resources.

If the above mentioned correct, then winget or notepad++ does not matter.
 
  • Like
Reactions: Sorrento
Speculations because no body knows the exact scenario of the infection process; all the possibilities are on the table.
A hijacked hosting provider account modified the getDownloadUrl.php script to redirect specific targets' WinGUp requests to malicious servers.

This is why the remediation focuses on updating to v8.8.9+ (which enforces strict verification) and resetting hosting credentials, rather than "unknown" possibilities like a source code compromise.

Post in thread 'Notepad++ updater installed malware' Malware News - Notepad++ updater installed malware
 
I think it is pretty clear. Plus from Dec 9th 50+ days from original discovery.
Did not answer my previous inquiry; cannot files on github (update files) get compromised, just as they are supposed to be compromised on the culprit update server?
 
Did not answer my previous inquiry; cannot files on github (update files) get compromised, just as they are supposed to be compromised on the culprit update server?
Could files on GitHub be compromised? Yes, theoretically, if the developer's GitHub credentials were stolen. Were they compromised in this incident? No. The evidence confirms the breach was strictly isolated to the web hosting provider and the update manifest logic, not the Git repository or the GitHub release assets.

Target
The notepad-plus-plus.org web server.

Mechanism
Attackers hijacked the getDownloadUrl.php script.

Action
When the updater asked "Where is the file?", the compromised script lied and pointed to a malicious IP instead of the legitimate GitHub URL.

Result
The updater went to the wrong location. The legitimate files on GitHub were never touched, the updater just never went there.
 
Not necessarily.
https[:]//notepad-plus-plus.org/update/getDownloadUrl.php server was only compromised.
The same way such a server was compromised, the one on github can also.
What safeguard is not the server destination, it is the ability of the updater to check for update file hash compatibility.
 
  • Like
Reactions: Sorrento