How the Notepad++ Supply-Chain Attack Unfolded: A Deep Technical Analysis

In early February 2026, the developers of Notepad++, the widely-used open-source text editor, confirmed what cybersecurity analysts had feared: a sophisticated supply-chain attack had compromised the Notepad++ update infrastructure for months, resulting in targeted delivery of malicious update binaries.

This incident is a textbook example of how supply-chain threats can bypass traditional application security by attacking the delivery mechanisms rather than the software itself. In this post, we’ll explore how the attack worked, when it happened, why it was dangerous, the threat actor profiling, and what it means for modern software distribution security.

What Was Compromised and What Wasn’t ?

This was not a bug in Notepad++ source code.

Instead, the attack targeted the update delivery infrastructure — specifically the system responsible for serving automatic updates to users via the built-in updater called WinGUp (also known as GUP).

Here’s the key point:

• The application itself was intact — no malicious code was injected into the Git repository or official releases.
• The attackers compromised the shared hosting environment that hosted the update mechanism, allowing them to intercept and redirect update requests to attacker-controlled servers.

Fig 1. Software Update Delivery System

What Made Notepad++ Vulnerable

The core weakness was in how older versions of Notepad++ handled update verification. Versions prior to 8.8.9 did not strictly enforce cryptographic integrity checks on downloaded update packages:

• The updater would contact the update server and retrieve a URL pointing to the installer file.
• The update metadata (XML) and installer binary lacked robust signature verification.
• Because of this, if an attacker could redirect the update command to a malicious server, the updater would happily download and execute whatever it found.

This is precisely the crux of a supply-chain attack — the users implicitly trust the update source but the trust model is broken. Once a trusted delivery path is compromised, all bets are off.

Timeline: How the Attack Unfolded

• June 2025 — Attackers gain initial access to the shared hosting infrastructure used for Notepad++ updates.
• June — September 2, 2025 — The attackers maintain direct access to the compromised server environment.
• September 2, 2025 — Hosting provider performs kernel/firmware updates that remove the attackers’ direct server access.
• September — December 2, 2025 — Although direct server access was lost, attackers still had valid internal credentials, allowing them to continue redirecting some traffic.
• December 2, 2025 — All attacker credentials are rotated and access is fully terminated.
• December 9, 2025 — Notepad++ releases version 8.8.9 with hardened update verification.
• February 2, 2026 — Official public disclosure of the attack.

This means the active compromise window stretched for nearly six months, enabling long-term persistence and stealthy operations.

Anatomy of the Attack

1. Initial Compromise

The attackers did not exploit a software bug in Notepad++; instead, they gained access to the hosting provider infrastructure — likely through compromised credentials or weak segregation controls — which served the update endpoint getDownloadUrl.php.

Once inside this environment, they could intercept update requests from legitimate users and respond with URLs pointing to malicious files residing on attacker-controlled domains.

2. Malicious Update Traffic Redirection

The hosted script would normally:

1. Receive an update request from a user’s WinGUp executable.
2. Respond with a URL pointing to a signed XML manifest.
3. The updater would then download and execute the installer.

However, the attackers modified this flow so that for selected targeted users, the same script instead returned a URL pointing to malicious content.

This is not random — the redirection was selective and likely based on targeted criteria (e.g. IP ranges, corporate networks, or geographic filtering), a hallmark of highly sophisticated threat actors.

3. Malicious Payload & Backdoor

Once a targeted user received the malicious update URL and executed it, the malware could deploy a variety of payloads. Technical analyses (such as those by Rapid7 and community investigators) have revealed that:

• The malicious installers deployed backdoors like a custom payload dubbed Chrysalis.
• Some variants employed DLL side-loading techniques to remain stealthy.
• Other chains included Metasploit or Cobalt Strike beacons for remote command and control.

This means once installed, the malware could:

• Persist on the system undetected.
• Execute arbitrary code with user privileges.
• Connect back to C2 infrastructure.
• Facilitate espionage objectives.

4. Persistence After Partial Remediation

Even after the hosting provider’s maintenance on September 2, 2025 stripped out high-level access, the attack didn’t end. The attackers had already obtained internal service credentials, which they continued to abuse for another three months, maintaining their ability to issue malicious update URLs until December 2.

This is textbook persistence — the capability of an attacker to remain active in an environment even after initial footholds are neutralized.

Why This Was Dangerous

This attack illustrates several critical cybersecurity lessons:

1. Trusted Update Channels Are High-Value Targets

Security teams usually focus on application code and platform vulnerabilities. But as this incident proves, the delivery mechanism — especially automatic updating — can be an even more valuable attack vector.

2. Lack of Cryptographic Verification Is a Fatal Flaw

Older Notepad++ versions accepted installer files without strict cryptographic verification, essentially granting attackers carte blanche to serve arbitrary binaries if they could manipulate update URLs.

3. Selective Targeting Is Hard to Detect

Because only specific users received malicious updates — not every single Notepad++ user — the breach could have gone unnoticed for months. This is typical of state-sponsored campaigns, which seek stealth over noise.

Threat Actor: Who Was Behind It?

Multiple cybersecurity firms and media outlets have tentatively attributed the campaign to a Chinese state-linked advanced persistent threat (APT) group, possibly the infamous Lotus Blossom cluster.

This inference is based on:

• The technical sophistication of the attack.
• Targeted deployment patterns.
• Regions and industries affected.
• Long-term operational planning required to sustain the campaign.

How Notepad++ Responded

After discovery, the project took swift action:

• Migrated to a new, hardened hosting platform.
• Rotated all credentials tied to compromised systems.
• Released Notepad++ v8.8.9, which introduced certificate and signature verification for updates — meaning updates without valid signatures are no longer trusted.
• Planned further enhancements (e.g., mandatory signed XML manifests in later versions).

Key Takeaways for Developers & Security Teams

1. Automatic updaters must enforce strict cryptographic integrity checks.
2. Update infrastructure is part of the trusted computing base — protect it as rigorously as the core application.
3. Credential and access controls at hosting providers must be locked down.
4. Selective targeting often indicates state-linked activity rather than random cybercrime.

Final Thoughts

The Notepad++ compromise is a wake-up call for anyone involved in software distribution. Even trusted, open-source tools can become a vector for advanced attacks when supply chains are weak.

As software ecosystems grow more complex, so too must the security models that protect them. Developers and organizations should treat update mechanisms and delivery infrastructure as critical security assets, and invest accordingly.