What's concerning is the 6-month window. Supply chain attacks are difficult to detect because the malicious code runs with full user permissions from a "trusted" source. Most endpoint protection isn't designed to flag software from a legitimate publisher's update infrastructure.

For organizations, this argues for staged rollouts and network monitoring for unexpected outbound connections from common applications. For individuals, package managers with cryptographic verification at least add another barrier - though obviously not bulletproof either.

If one day, maybe in 10 or 20 years time, I feel Notepad++ lacks something and I decide to upgrade, I will do it myself, I don't need a handy helper.

There is no reason for a tool to implicitly access my mounted cloud drive directory and browser cookies data.

Supply chain attacks work because we implicitly trust the update channel. But the same trust assumption appears in other places:

- npm/pip packages where we `npm install` without auditing - AI-generated code that gets committed after a quick glance - The growing "vibe coding" trend where entire features are scaffolded by AI

The Notepad++ case is almost a best-case scenario — it's a single binary from a known source. The attack surface multiplies when you consider modern dev workflows with hundreds of transitive dependencies, or projects where significant portions were AI-generated and only superficially reviewed.

Sandboxing helps, but the real issue is the gap between what code can do and what developers expect it to do. We need better tooling for understanding what we're actually running.

* Enabled by default * No use of verification of the either the update metadata nor the update payload itself

Looks like someone wanted to write an auto updater without having the knowledge to do so properly

Very sad

Naive question, but isn't this relatively safe information to expose for this level of attack? I guess the idea is to find systems vulnerable to 0-day exploits and similar based on this info? Still, that seems like a lot of effort just to get this data.

Could this be the attacker? The scan happened before the hack was first exposed on the forum.

Notepad++ hijacked by state-sponsored actors

https://news.ycombinator.com/item?id=46851548

https://arstechnica.com/security/2026/02/notepad-updater-was...

I recommend removing notepad++ and installing via winget which installs the EXE directly without the winGUP updater service.

Here's an AI summary explaining who is affected.

Affected Versions: All versions of Notepad++ released prior to version 8.8.9 are considered potentially affected if an update was initiated during the compromise window.

Compromise Window: Between June 2025 and December 2, 2025.

Specific Risk: Users running older versions that utilized the WinGUp update tool were vulnerable to being redirected to malicious servers. These servers delivered trojanized installers containing a custom backdoor dubbed Chrysalis.

https://community.notepad-plus-plus.org/topic/27212/autoupda...

Thankfully the responses weren’t outright dismissive, which is usually the case in these situations.

It was thought to be a local compromise and nothing to do Notepad++.

Good lessons to be learned here. Don’t be quick to dismiss things simply because it doesn’t fit what you think should be happening. That’s the whole point. It doesn’t fit, so investigate why.

Most tech support aims to prove the person wrong right out the gate.