Notepad++ Updates Became a Malware Delivery Pipeline

Notepad++ updates got hijacked, and the attack chain is seriously concerning

Notepad++ is one of those utilities that ends up everywhere. Dev laptops, jump boxes, random servers that should not have a GUI but somehow do, IT workstations that have survived three hardware refresh cycles. That footprint is exactly why the attacker behavior in this case is worth paying attention to, even if you personally do not care about text editors.

This is not a “Notepad++ had a vuln” story. The repo was not poisoned and the application code was not the headline. The weak point was the distribution path, specifically the update flow and the infrastructure around it. The result was a targeted supply chain operation that ran for months in 2025 and delivered a custom backdoor that Rapid7 later named Chrysalis.

The part that should make defenders slightly uncomfortable is how normal it looked from the user’s perspective. Open Notepad++, updater runs, something downloads, user clicks through an installer. That is the whole trick. You can do everything “right” on the endpoint and still lose if the update channel is allowed to lie to you.

What actually got compromised

The public reporting and Notepad++’s statements describe a compromise that started in June 2025 and lasted until December 2, 2025. External responders found the hosting environment was compromised through early September, then the attacker lost direct access during kernel and firmware updates, then kept redirect capability using previously stolen internal service credentials until early December.

Two details matter here:

1. It was selective. Most users kept getting legitimate updates. Only a subset were redirected to attacker infrastructure.

2. The attackers were aiming at weaknesses in older updater verification controls. Notepad++ later hardened WinGUp so it verifies installer certificates and signatures and signs the update XML.

Selective delivery changes the detection game. If you only hit a few targets, you avoid the “someone on Reddit posted the SHA256 within 10 minutes” problem. You also avoid widespread breakage.

The delivery chain Rapid7 saw

Rapid7’s writeup is the most useful part of this whole story because it gives you an execution chain you can actually hunt for, instead of a vague “malicious update happened” statement.

Their MDR forensics found this sequence on impacted assets:

• notepad++.exe runs

• GUP.exe runs (the updater)

• a suspicious update.exe runs after being downloaded from an external IP (Rapid7 calls out 95.179.213.0)

Rapid7 analyzed it as an NSIS installer, a packaging choice that shows up a lot in China-linked intrusion chains because it is convenient and flexible.

Inside the installer, the actor used a “live off legit binaries” move. One extracted file was a renamed legitimate Bitdefender Submission Wizard binary, used specifically for DLL sideloading. The installer placed a malicious log.dll next to that binary so Windows would load the attacker DLL instead of the real library.

From there, log.dll handled the messy part: load encrypted shellcode, decrypt it in memory with a custom routine, resolve APIs with hashing to make static analysis and signature matching harder, then hand execution off to the decrypted stage. Rapid7 ultimately attributes the backdoor to a China-linked actor they track as Lotus Blossom, based on similarities to prior public reporting and toolchain overlap.

Once Chrysalis is running, it behaves like what you would expect from a long-term espionage implant. Rapid7 describes it as feature-rich, capable of remote execution and file operations, with persistence and self-removal options, plus additional staged payload behavior where it loads wininet.dll and pulls another stage from a domain under the attacker’s control (api.wiresguard.com/users/admin in their analysis).

What defenders should take from this, without turning it into a checklist post

If you run Notepad++ in your environment, the obvious move is to stop relying on older updater behavior. Notepad++ released changes starting in v8.8.9 where WinGUp verifies installer certificates and signatures and the update XML is cryptographically signed.

After that, treat this like a normal intrusion investigation problem: what executed, what wrote where, what connected out. You do not need perfect IOCs from the vendor to do that.

A few concrete places to look that come straight from the incident reporting and Rapid7’s chain:

• Systems where GUP.exe spawned something unusual, especially a child process named update.exe.

• Suspicious binaries appearing in temp or user-writable locations around update time. Public writeups mention checking for odd updater artifacts in temp paths, which is consistent with how this chain would land.

• Outbound connections that line up with Rapid7’s described staging behavior, including the domain they observed for second-stage retrieval.

Also, do not miss the meta lesson: this was a supply chain attack that did not require compromising GitHub, build servers, or release signing. It was “just” infrastructure plus trust.

The bigger story is not Notepad++

Notepad++ is the case study because it is popular and the reporting is unusually detailed. The real issue is the pattern.

If an attacker can manipulate update routing or update metadata for any widely deployed tool, they get a delivery mechanism that security teams are trained to accept as normal. Endpoint controls often treat software updates as higher-trust activity, users click through installers faster, and network teams rarely want to be the person who breaks patching.

That is why Lotus Blossom going after a boring update channel is a smart trade. It scales access to interesting targets while keeping the blast radius low enough to stay quiet.

If you want the short version to keep in your head: the most dangerous part of your software stack is not always the code. Sometimes it is the path the code takes to reach you.