TL;DR: The Notepad++ incident was not a failure to patch quickly. It was a failure of update trust. Auto-updaters inherit long-term trust, run with high privilege, and offer little visibility. Centralized patch management cannot prevent supply chain attacks, but it restores control, auditability, and the ability to pause updates when trust breaks.
The Notepad++ supply chain incident wasn’t about slow patching. It was about misplaced trust in the update mechanism itself.
Rapid7 attributed the attack to the Chinese APT group Lotus Blossom. It compromised infrastructure used to deliver Notepad++ updates and used it to distribute a previously undocumented backdoor, which Rapid7 named Chrysalis.
No phishing was involved. No user made a mistake. This attack stemmed from an upstream infrastructure compromise that redirected update traffic. Based on current analysis, the Notepad++ updater functioned as designed — but that design relied on implicit trust in the update source.
That is the uncomfortable part. When the update path itself is trusted implicitly, compromise upstream becomes compromise everywhere.
Why auto-updaters are prime supply chain attack targets
Auto-updaters are attractive supply chain attack targets because they combine high privilege, routine execution, and minimal oversight.
Once a piece of software is approved, its updater inherits that trust indefinitely. It runs silently. It phones home on its own schedule. And in many environments, no one is logging where it connects, what it downloads, or how those binaries were validated.
From the endpoint’s point of view, there’s no difference between a clean update and a poisoned one. Both arrive through the same channel launched by the same process.
That’s why supply chain attacks don’t need zero-days or clever lateral movement. They aim upstream. If you can compromise the update source, you let everyone else do the deployment for you.
The Notepad++ case wasn’t unique in that sense. It just happened to land in a tool that’s widely trusted, widely deployed, and usually ignored once installed.
Why patching faster does not equal patching with control
IT has spent the last decade internalizing a simple mantra: patch faster.
That instinct exists for a reason. Unpatched vulnerabilities get exploited. Delays create exposure. Nobody is arguing for a return to quarterly patch windows and crossed fingers.
But patching quickly and patching deliberately are not the same thing.
Auto-updaters optimize for speed and convenience, not for governance. They assume that the vendor’s infrastructure is always trustworthy, that validation is always correct, and that the update path itself never needs to be reviewed.
Centralized patch management best practices flip that assumption. Updates still happen — often just as quickly — but they pass through a choke point that IT owns. Packages are fetched once, validated once, and deployed intentionally. If something looks off, rollout can pause. If trust is broken, it can be revoked. That extra step can introduce friction, but it also introduces control. You don’t get one without the other. However, you can at least minimize friction with the right solutions.
What centralized patch management changes in a supply chain attack
Centralized patch management doesn’t make supply chain attacks impossible. Nothing does. What it does is shrink the blast radius and improve your odds of catching something before it spreads. A few concrete differences matter here:
Fewer trust relationships: Instead of hundreds or thousands of endpoints trusting dozens of vendor update servers directly, endpoints trust you. Vendors become upstream sources, not runtime authorities.
Visibility into update paths: You know where installers came from, when they were pulled, and what version was deployed. That sounds basic. It often isn’t.
Intentional rollout: Updates happen because IT approved them, not because an embedded updater decided it was time.
A pause button: When an incident breaks, you can stop distribution immediately. Auto-updaters don’t ask permission.
None of that prevents a compromised vendor from shipping a bad update. But it does mean you’re not blindly consuming it at scale, in real time, without recourse.
Practical steps you can take without boiling the ocean
You don’t need a perfect environment to reduce this class of risk. A few pragmatic moves go a long way:
Disable auto-updaters where feasible: Not everywhere, and not blindly. Start with tools that don’t need same-day updates and don’t justify their own privileged network access.
Standardize how third-party software gets installed: Fewer packaging methods means fewer blind spots.
Audit outbound update traffic: If endpoints are reaching out to update servers you didn’t know existed, that’s useful information — even if you don’t act on it immediately.
Separate urgency from automation: Critical patches can still move fast without bypassing review. Speed doesn’t require abdication.
None of these steps call for malware expertise. They just require treating updates as infrastructure instead of background noise.
Where tools like PDQ fit — and where they don’t
Using PDQ won't make you immune to supply chain attacks, but it can significantly reduce your exposure. Centralized patch management tools, PDQ included, exist to make control practical at scale. They give IT teams a way to standardize packages, control rollout, and reduce dependence on vendor-controlled updaters scattered across endpoints.
For example, sysadmins who manage Notepad++ with PDQ weren't impacted because PDQ disables most auto-updaters by default. Instead, we download and verify the installers directly from the developer source, then make them available to our users.
The real advantage isn’t immunity — it’s control. PDQ shifts trust boundaries back into your environment, where decisions are visible, deliberate, and reversible.
The real lesson
The takeaway from the Notepad++ incident isn’t that patching failed. It’s that implicit trust in third-party update mechanisms is itself a risk, and one that rarely shows up in audits until something goes wrong.
Auto-updaters are convenient. They’re also invisible by design. Centralizing updates trades a bit of that convenience for clarity and control ... and that’s a trade worth making deliberately.
If you want more control over how third-party software gets updated without slowing your team down, PDQ Connect is built for exactly that. Centralize updates, standardize installs, and decide when and how changes roll out. Start a PDQ Connect trial and take ownership of your update paths.
