At a glance: Notepad++ version 8.9.2 introduces cryptographic verification of the XML update manifest, completing end-to-end verification of both update metadata and installers following the 2025 supply-chain compromise. The update closes the remaining gap that allowed threat actors to manipulate update metadata and redirect GUP to execute malicious payloads. Organizations running 8.9.1 or earlier are recommended to upgrade to 8.9.2 and remove any deprecated self-signed certificates.
Threat summary
On February 16, 2026, Notepad++ developers released version 8.9.2, which introduces the final security control needed to fully harden its update mechanism following the 2025 supply-chain compromise.
This release adds cryptographic verification of the XML update manifest, the last previously unsigned component in the update chain, closing the remaining gap that allowed threat actors to manipulate update metadata.
As Field Effect previously reported, between June and December 2025, a Chinese state-linked threat actor gained access to the shared hosting environment used to serve Notepad++ update files. By tampering with or redirecting the XML update manifest, the attackers were able to instruct GUP (the Get Update Program bundled with Notepad++) to download and execute malicious payloads. GUP relies entirely on the XML manifest for update instructions and, prior to 8.9.2, neither the manifest nor the downloaded executables were validated. This allowed the adversary to turn the updater into a general-purpose code-execution vector.
Initial fixes, released in December 2025, introduced installer signature verification and replaced the deprecated self-signed certificate with a GlobalSign certificate. These changes ensured that only signed installers would run, but the XML manifest itself remained unsigned.
An attacker controlling the hosting environment could still alter the manifest and redirect GUP to arbitrary executables. Version 8.9.2 closes this gap by adding XML Digital Signature (XMLDSig) validation, completing end-to-end verification of both update metadata and installers.
Analysis
Organizations running versions 8.9.1 or earlier are not exposed to the original attack path if they updated after December 2025, when installer signature checks and a GlobalSign-issued certificate were introduced. However, those changes did not fully secure the update mechanism, because the XML manifest that directs GUP’s behavior was still unsigned. Version 8.9.2 completes the end-to-end verification model by adding XML signature validation and removing the remaining opportunity for metadata manipulation.
Any environment running 8.9.1 or earlier would benefit from upgrading to 8.9.2, as the new version ensures that both the installer and update metadata are validated before execution. This is now the recommended baseline for all deployments.
Removing the deprecated self-signed certificate, if still present on systems that previously ran older versions, provides additional hardening. The deprecated certificate resides in the Windows certificate store, typically under Trusted Publishers or Trusted Root Certification Authorities.
Administrators can identify the Notepad++ self‑signed certificate, where the issuer and subject fields match, and remove it using existing enterprise tooling such as certificate management consoles, Group Policy, Mobile Device Management platforms, or endpoint management systems. Removing the certificate eliminates an outdated trust anchor and ensures that only the current GlobalSign certificate is recognized for update validation.
Recommended steps
- Reduce exposure by updating all Notepad++ installations to version 8.9.2 or later, which introduces full end‑to‑end verification of both installers and update metadata.
- Remove the deprecated self‑signed certificate if it is still present.
- Review installer execution logs from June-December 2025 for unexpected installer activity if your organization allowed client-initiated updates during that period.
- We recommend centralizing software distribution and monitoring update traffic to reduce exposure to similar infrastructure-level compromises in future.