When A Hosting Provider Becomes A Hostile Provider: The Notepad++ Compromise

The detailed writeup from cybersecurity vendor Rapid7 about the Notepad++ compromise gives CISOs a clear demonstration of how a single failure in the distribution process for a widely used utility can become an enterprise-scale software supply chain event. Developers, analysts, automation engineers, researchers, IT operators, and security teams use this editor as part of their daily workflow. That widespread use makes this compromise a potentially high-consequence incident with reach across systems, pipelines, and users. Attackers target distribution paths because one successful insertion delivers access to thousands of environments at once. The continued trend of software supply chain compromises shows the efficacy of this strategy.

Notepad++ Hijack: Timeline And Details

Attackers prize distribution points that touch a large population. Update servers, download portals, package managers, and hosting platforms become efficient delivery systems, because one compromise creates thousands of downstream victims. The Notepad++ incident is another example where adversaries infiltrate a trusted channel and wait for victim organizations to pull contaminated content into production.

Notepad++ is a free, open-source tool licensed under GPLv3 that can be used for commercial purposes. Open-source software is appealing because it is cost-effective, highly customizable, transparent, and benefits from community support and rapid innovation. It does not require an enterprise contract or license, however, and does not include usage tracking by default and therefore may not be tracked in an enterprise software inventory. In addition, open-source projects may lack the needed resources to devote to supply chain security, such as strict code signing and update verification processes, when compared to enterprise-grade software equivalents. The software is typically hosted on publicly accessible infrastructure, making it an easier target for compromise.

Here’s a detailed timeline of the Notepad++ events:

June 2025: Attack begins. Security researchers believe a state-linked actor compromised the former hosting provider’s infrastructure and gained the ability to intercept and redirect Notepad++ update traffic.
June to September 2, 2025: Attackers maintain direct access to the shared hosting server. On September 2, a routine kernel and firmware update unintentionally removes their server-level foothold.
September 2 to December 2, 2025: Although server access is lost, attackers retain valid internal service credentials. These credentials allow continued redirection of some update requests to malicious servers.
November 10, 2025: Security experts assess that active attack operations ceased on this date, though credential-based redirection may have persisted.
December 2, 2025: The hosting provider completes remediation, rotates credentials, patches exploited vectors, and confirms that all attacker access is fully terminated.
Post-December 2025: The Notepad++ website is migrated to a new hosting provider with stronger security controls.

Users are advised to manually install version 8.9.1.

What CISOs Should Do Now

CISOs should take the following steps to obtain situational awareness, understand the potential impact of the compromise, and make the environment more resilient to issues in the future:

Initiate threat hunts as TTPs emerge. Compare any current deployments and versions to the list of legitimate checksums for Notepad++ release assets on GitHub to validate the use of known-good releases. Florian Roth put together a collector to pull the set of of known-good hashes and X user K Jackson created a KQL query to help search for it. At the same time, start executing threat hunts immediately to search for suspicious processes, unexpected update activity, redirected downloads, abnormal file writes, and telemetry patterns tied to the compromise based on emerging TTPs such as those listed in the Rapid7 blog.
Build and maintain a software inventory that includes widely used utilities. Maintain a complete software inventory that includes widely used utilities like Notepad++, since these tools often have auto-update mechanisms that can be abused. Open-source software tools must be tracked alongside commercial software. Knowing exactly which systems had Notepad++ and which versions were installed allows faster identification of potentially exposed machines. An up-to-date inventory enables teams to quickly disable updates, apply mitigations, or hunt for indicators of compromise tied to affected software.
Validate software provenance for tools used in development or security workflows. Verify software integrity by enforcing signed packages and disallowing unmanaged updates. Ensure that all software installs and updates are from trusted sources by verifying digital signatures. In addition, put least-privilege permissions on all tools and implement network controls to ensure that only approved software runs and that unexpected outbound connections are blocked.
Fold this case into your software supply chain incident playbooks. Add playbook steps for when third-party update infrastructure is compromised but vendor source code is not. The runbook should treat “suspicious updater behavior observed” as the pivot point from “monitoring only” to “full host‑level DFIR.” Be prepared for a situation where the software has a known vulnerability but does not have a patch or mitigation available.
Use EDR, network telemetry, and proxy logs. Monitoring and endpoint detection and response (EDR) tools can help detect abnormal updater behavior, such as launching unknown executables or attempting suspicious network activity.
Communicate clearly with executives about software supply chain fragility. Classify this as a strategic supply chain threat with potential long‑tail impact; brief the board and risk committee accordingly, highlighting exposure in high‑value engineering and admin populations. Use concise language and active phrasing to explain the urgency of supply chain controls to executive stakeholders. Ensure your organization’s understanding of the role you play in securing the software supply chain and the corresponding practices that need to be followed.
Show customers you’re on top of it. Prove that you understand and are actively managing the Notepad++ risk and give crisp, honest answers to anticipated questions such as: “Do we use it? What do our hunts show? What exactly are we doing next?” Make sure that every external message matches internal reality and treat the situation as a SolarWinds-style stress test to tighten controls and rehearse your governance and disclosure muscle for the next one.
Shift your culture from one of implicit trust to one of continuous verification. Make verification part of your default workflow. Tools that enter your environment must be known, cataloged, and validated. For all software, ensure that you obtain, generate, or download a software bill of materials (SBOM) and monitor the SBOM for newly disclosed vulnerabilities. Use this incident to push suppliers to provide SBOMs, plus update chain-of-custody tracking and third-party IR obligations in third-party risk assessments or vendor due diligence questionnaires and contracts.
Expose and eliminate trusted noise in endpoint behavior. Over the long term, consider your developer-specific EDR approach. Most EDR programs are blind by design to “expected” developer behavior. A compromised utility does not need exploits, LOLBins, or exotic malware. It just needs to look boring — like something a dev would do. An updated spawning curl, PowerShell, or CMD is normal. A developer running unsigned binaries from user space is also normal, as is network egress from laptops. Supply chain attacks win by hiding inside what defenders have already normalized as acceptable noise. If your detection strategy hinges on novelty rather than violation of trust assumptions, you are structurally conceding this class of attack.
Treat developer endpoints as governed execution environments. Specify which tools are allowed to run, what they can spawn, and what their update strategy is. Any organization that cannot enforce this is not managing software supply chain risk effectively.

What It Means Longer-Term

Use this event as a precursor warning in terms of the future of AI deployments in your environment. AI agents further blur the tool/operator dichotomy. Agents can edit files, execute commands, install dependencies, and pull updates without your input. As such, every trusted utility is an autonomous execution surface. The same supply chain blind spots that let a compromised tool blend into developer noise will let a compromised agent establish persistence and elevate privileges at scale. If you cannot strictly define what should execute, spawn, update and communicate before delegating those abilities to agents, your automation becomes a self-propagating supply chain vulnerability.

Forrester clients who want to continue this discussion or dive into Forrester’s wide range of AI research can set up a guidance session or inquiry with us.