Six months. That’s how long Chinese hackers reportedly hijacked Notepad++ updates before anyone noticed. Six months of malicious code flowing through a trusted update channel to millions of developers, sysadmins, and power users worldwide. If you’re in infosec, that number should keep you up at night. Update NOW!
The Perfect Target
Notepad++ isn’t just a text editor, it’s practically requiredd infrastructure. It sits on the machines of the people who build and maintain everything else: developers writing code, sysadmins editing configs, security analysts examining logs. Compromise Notepad++ and you’re not just getting access to random endpoints. You’re potentially getting access to:
- Source code repositories
- Production server credentials
- Cloud infrastructure configs
- Security tool configurations
- SSH keys and API tokens
The attackers weren’t casting a wide net for grandma’s banking password. They were fishing in the exact pond where the biggest fish swim.
Supply Chain Attacks Work
Traditional security thinking focuses on keeping bad things out: firewalls, endpoint protection, and email filtering. But supply chain attacks flip the script, making the bad thing look like a good.
When your trusted software vendor pushes an update:
- ✅ It comes from a legitimate domain
- ✅ It’s signed with valid certificates
- ✅ It follows the normal update process
- ✅ Your security tools recognize it as safe
Every checkbox is green. Every indicator says “trusted.” And that’s exactly the problem. It continues to happen because attackers know that this scheme works and there is a big payoff for their efforts. It’s like a heist movie sans Mini Coopers, and with this great editing tool everywhere, who knows what they have gotten away with.
The Uncomfortable Questions
1. Should critical tools auto-update at all?
Auto-updates are a security best practice… until they’re not. The convenience of automatic patching becomes a liability when the update mechanism itself is compromised. The speed of automatic updates to get your whole infrastructure patched can be a good feeling when you know that you are fixing vulnerabilities.
But the alternative of manual updates means that many users never update at all, leaving them vulnerable to known exploits. And doing a manual update means? Waiting so that the software code can be scanned, or waiting for everyone who already installed it to give a thumbs up? Are you doing any of that? Mixed bag of maybe some update, or maybe you wait a few weeks to see if anything breaks?
Pick your poison.
2. How do you verify what you can’t see?
Even if you’re cautious, how would you have detected this? The update came from the official source. The signatures checked out. The behavior was subtle enough to avoid triggering alerts for half a year.
Traditional verification assumes a trusted anchor point. When that anchor is compromised, the whole chain of trust collapses. There is a scaffold of trust that has been shaken here.
3. Is air-gapping the only answer?
For truly critical systems, maybe. But “just air-gap it” isn’t a realistic answer for most organizations — or for the millions of individual developers who rely on tools like Notepad++ daily.
The Pattern Continues
This isn’t new. We’ve seen this movie before:
- SolarWinds (2020): Russian hackers compromised Orion updates, hitting 18,000+ organizations including US government agencies
- 3CX (2023): North Korean actors trojanized the popular VoIP client’s installer
- Codecov (2021): Bash Uploader script modified to exfiltrate credentials
- event-stream (2018): Popular npm package hijacked to steal cryptocurrency
Each time, the lesson is the same: the supply chain is the attack surface now.
What Can We Actually Do?
There’s no silver bullet, but there are layers:
For Organizations:
- Software Bill of Materials (SBOM): Know what’s in your software stack. With the recent US government abandonment of the SBOM requirement, we will have to rely on other means to piece this together.
- Update staging: Test updates in isolated environments before broad deployment. But with the 6-month timeline of this event, I don’t think anyone’s staging plan was set up to beat this.
- Behavioral monitoring: Watch for anomalies even from “trusted” software. Even with the best tools, no organization’s UEBA caught on to this.
- Zero-trust architecture: Assume compromise, limit blast radius. This is probably the best, but most expensive option.
For Individuals:
- Delay updates slightly: Let others be the canary (uncomfortable but practical). This just means you could be sitting on another vulnerability that needs to be fixed. A ticking time bomb. Perhaps there is room for a public service, maybe by Homebrew and Chocolatey, that manages update rings you can choose to be a member of?
- Monitor network traffic: Know what your tools are phoning home to. This is beyond the average user to set up consistently for proper detection, and who is going to review the logs? Aim claude at this if you really have tokens to burn.
- Use open-source where possible: More eyes on the code, although this is not foolproof. Open-source code was supposed to fix these kinds of problems, but even that has proven susceptible to downstream dependencies being hacked. There just aren’t enough eyes, and with the advent of vibe coding, only AI will be able to keep up with scanning code.
- Compartmentalize: Don’t use the same machine for sensitive work and general browsing. I avoid using my personal machine for work, and vice versa, at all costs. I have the same secure behaviors on both systems, but never the twain shall meet.
For the Industry:
- Reproducible builds: Verify that the source code produces identical binaries. This is extra work that may be skipped in the rush to get a vital fix out, or just delay remediation of another vulnerability. Who pays for this extra work?
- Transparency logs: Publicly auditable records of software releases. Transparency is always a good thing! Can we all be this transparent?
- Better detection sharing: Six months is unacceptable; we need faster collective awareness. How and when was this originally found?
The Deeper Problem
At its core, this is a trust problem. Modern computing is built on layers of abstraction and delegation. We trust our OS vendors. We trust our compiler writers. We trust our package managers. We trust our tool developers. And now we are even trusting crab-based AI orchestration systems to abstract even all those layers.
That trust is usually warranted, but it creates a brittle system. Compromise any link in that chain, and the whole edifice wobbles. Ken Thompson pointed this out in 1984 with his Turing Award lecture “Reflections on Trusting Trust.” Forty years later, we still haven’t solved it. We’ve just made the supply chain longer and more complex.
How can we strengthen the links between these systems to narrow the gaps? Now that CISA is being cut to the bone, in an age where threats are only escalating, who can be trusted to provide that strength?
Shared trust in third-party management, and thus Nth-party management, should be more transparent. The opacity of industry sets the stage for these exploits to go undetected, even as we should be working together to fight them. It sounds like unreasonable optimism or over-the-top idealism, but at one point, much of the computing cooperation we have today seemed far-fetched.
The Takeaway
The Notepad++ compromise isn’t just a story about one text editor getting owned. It’s a reminder that our security models haven’t caught up with our dependency models.
Every piece of software you install is an act of trust. Every auto-update is a bet that the vendor’s infrastructure hasn’t been compromised since the last one. Most of the time, that bet pays off.
But six months of silent compromise show how badly it can go wrong, and how little visibility we have when it does.
What’s your take? How do you balance the convenience of trusted software with the risk of supply chain compromise? I’d love to hear from other security practitioners wrestling with this.
Related Reading:
- Dark Reading: Chinese Hackers Hijack Notepad++ Updates for 6 Months
- Ken Thompson’s “Reflections on Trusting Trust” (1984)
- NIST Cybersecurity Supply Chain Risk Management
Playing with Sharp Objects. 