I can't believe a well funded company with multiple highly paid application and infrastructure security experts isn't able to provide more robust guarantees than this.
I can't believe so many people are willing to download software from a party who can't provide basic security guarantees. (Just kidding; I can. But I wish I couldn't!)
On the other side of that, do you know of any OSS/hobby/volunteer/small-company that can provide this kind of "basic" security guarantee? I'm not being deliberately obtuse here, but what we're seeing here is "your project's threat model is the union of all your user's threat models", which means if one of your users is considered important enough to warrant government level resources being deployed against them, you are now in that path as well.
Not many! That's why I install software thru apt. [edit: to clarify; I can think of lots of hobby/volunteer projects that do better than notepad++, but I can't think of many that do a good enough job that I would trust them to do the job of distribution. if they leave that work up to people who are experts in distribution, I see that as a good sign.]
But in general, I think it's better to omit an auto-update function than to include one that doesn't do basic checks. (Enabling TLS certificate verification is one such basic check.)
I'm unclear what verification was not occurring - as far as I can make out from the blog post their infrastructure was compromised and was returning compromised binaries, no indication of a TLS failure. I'm unclear what the post means when saying it now verifies the "certificate and signature" for updates - if they've got a TLS library that isn't verifying signatures, let alone certificates, that's a broken TLS library not the client. If they mean they've got code signing for updates then they were already trying to do better update security than most other auto-updating software.
TLDR for the edits below as I went through a journey of discovery: They use wingup to do updates and similar, and as far as I can make out the default behavior of that is to silently ignore signing entirely, and even if you do say "actually check the signature" it looks like it might not check the trust chain, etc by default???
[edit: oh I see, they used their own self signed key for code signing, but the interface used to perform verification is broken as it defaults to "is this correctly signed" rather than "is this correctly signed with a given certificate". So 50/50 fault: they decided not to use a trusted root meaning that they couldn't rely on default authentication working, and then the interface used for verification doesn't require a certificate (set) to verify against]
[further edit: 100% fault - SecurityGuard is their own wrapper around WinTrust, which while looking like a truly garbage API, they made a wrapper that maintains those bad defaults]
[yet another edit, I don't really think this is their fault: while SecurityGuard is their wrapper around WinTrust, it's WinGUP that is responsible for doing the update check and is where they're setting up the change in defaults, as far as I can tell by default it apparently does not perform any actual certificate validation, and I'm sure if I had decided to use a tool like this it would not have occurred to me that that was even an option, let alone the default]
Maybe the fact that their communication is honest is part of why they are loved. Perfect absolute flawless security does not exist, despite what $ANYCORP could claim.
Sure, but "oopsy, I didn't care about your security! tee-hee!" is both honest and should be disqualifying. I know that's not what happened here, but it is common to see breaches and everyone shrugs if they aren't personally affected if the tool falls into this "beloved" status (a certain games store comes to mind).
This is absolutely bonkers. I guess the only defense I had against this (running Notepad++ on all my devices) is that I am too unimportant to be targeted.
But the post is extremely thin on details. What kind of exploit was being shipped to targeted users? How can I check if I'm affected?
I’ve only talked to a small number of victims. They are orgs with interests in East Asia. Activity appears very targeted. Victims report hands on keyboard recon activity, with activity starting around two months ago.
It has just this about the exploit.
I'm assuming that if a victim is skilled enough to recognize "keyboard recon activity" and report it, surely they must've shared the binary with the exploit as well, right? Is anyone analyzing it yet?
From context, I think they mean that there's someone at the other end typing in commands to run on the compromised computer - i.e. the attacker is giving each compromised computer individual attention, rather than an at-scale attack where the exact same malicious thing is done on every computer.
It's recognizable if you have a log of commands executed - the sort of commands you'd see from a human poking around are pretty distinct from what an automated exploitation script would do, and might even include typos and such.
This traffic is supposed to be over HTTPS, however it appears you may be to tamper with the traffic if you sit on the ISP level and TLS intercept. In earlier versions of Notepad++, the traffic was just over HTTP.
Fetching update instructions via HTTP is madness, I wonder up to which version it was done like that. But it seems like at the point where this blog post was written, it wasn't known that Notepad++'s host was compromised and they conjectured the cause to be TLS intercept.
It's not automatically a bad idea, as long as you are not concerned about confidentiality and do integrity checking via another mechanism. The FreeBSD pkg tool use HTTP for a long time because the package database was signed with a private key and the individual packages had cryptographic hashes stored stored in the package database, and this made it easy to put a caching proxy in front of the package site for a bunch of machines to share. It moved to HTTPS because a bunch of places had an HTTPS-only policy (which is sensible: mandating HTTPS everywhere is a simpler policy to get right than HTTPS-except-when-you-have-a-good-reason-that-HTTP-is-secure).
But if you're just downloading things and not verifying them, especially executable things, HTTP is a disaster.
Even cases like this with a package database it is pretty complex. For example you need to be very careful that an attacker can't perform an unintentional rollback. This could possibly result in older (signed) packages with vulnerabilities being used (either not upgraded or the packages themselves rolled back).
APT servers used HTTP for a long time for similar reasons.
Still, why would I want anyone near the network path to know which packages I download? That information can reveal a lot.
Honestly I suspect the main reason Debian stopped using HTTP for this is so that people would stop saying "Well, Debian does it, so we can do it too" without realizing that Debian has a whole lot more going on behind the scenes that made it safe in this one case.
Well, URL's are encrypted on the wire, but are not usually encrypted anywhere else. SNI is not usually encrypted(but it's at least possible in certain configurations), so they can see on the wire that you hit http.us.debian.org, but not debian/pool/main/c/curl/curl_8.14.1-2+deb13u2_amd64.deb
Though I bet with a little bit of work the metadata available, like package sizing would give you a pretty great clue as to what package is being requested. (I haven't done any of this work, but I imagine it would work fairly well for debian packages)
That is a good point, there is nuance to it indeed. As you said, if you are not concerned about confidentiality and have another root of trust with which you verify, it's fine.
But if you're just downloading things and not verifying them, especially executable things, HTTP is a disaster.
if you are not concerned about confidentiality […], it's fine.
I think it’s worth pointing out that the “you” here refers to the package providers (the Debian or FreeBSD package databases), not the package users. If the only supported transport is HTTP, then it doesn’t matter whether the users are concerned about confidentiality; it’s not available to them either way.
HTTP was the norm, but as demonstrated here that's kind of moot if the ISP is compromised.
That's why an embedded signature in the file is needed, even when transferred over TLS. Though if an app does adopt that the developers of the app have to assume that by proxy their own system is now being subjected to the same level of attacker scrutiny.
If anyone is curious, dnshistory.org seems to suggest the old hosting provider was Hostinger, up to as late as 2 weeks ago. They've now switched to Aqua Raywhich seems less trustworthy, tbh.
This is not meant to be a dig at Hostinger in any way. I think their response was professional (the author seems satisfied with it too?). Getting hacked is a bad look, but we don't know how they got hacked, and since we seem to be dealing with state-sponsored hackers... could've happened to anyone, really.
dealing with state-sponsored hackers... could've happened to anyone, really.
This is really important to stress out IMHO. Cryptography (and cybersecurity in general) is needed and an interesting field (cool maths, what's not to love about it?), but I feel sometimes people have delusion of grandeur about how far one can fight back about state-level actors. When your threat model is intelligence services with next to unlimited resource, it's over before it even starts.
No idea of the scale of these hosting services, but I have noticed a belief that smaller providers are "more trustworthy", but if your concern is attackers at this scale and complexity then hypothetical differences in trustworthiness (esp. ones based primarily on corporation size) is secondary to ability to invest in infra security and hardening.
But also you need to simply start assuming your infra is compromised and verify information is correctly verified through other channels
Tangential, but: XML signing is a shitshow. I'm fairly confident that we haven't seen the end of vulnerabilities with XML signing. Signatures should not be embedded in the signed data and require normalization dances.
Something I find interesting with the various attacks is that they're not new techniques at all. Quite often they could be considered fairly basic (TLS interception isn't news). However, we used to consider these threats are not very likely to happen in the open because they're not very stealth.
Fast-forward today and we get news of them every few months or even weeks. Intercepting traffic of everybody using notepad++ to target a limited number of opponents in a specific region to exfiltrate data? No hesitation.
I guess the main change is the proliferation of state-sponsored groups that aren't directly part of these states and offer plausible deniability (or just silence).
We used to consider these threats are not very likely to happen in the open because they're not very stealth.
But the stealthiness of a technique isn't just an inherent trait of its technical means, it's also a measure of monitoring and review in the system it's used against. In its most basic form (I'm not saying this is what happened, it's just the canonical example of this distinction) any threat is 100% stealthy if no one's watching. TLS interception isn't inherently stealthy on its own. But if you only need it to work for a few weeks, and you know no one's going to look for it for a few weeks, you've got yourself an extremely stealthy attack.
Plus, as BenjaminRi pointed out, the stealthiness threshold isn't exactly fixed, either. Realistically, a state actor targeting the infrastructure of a commercial hosting services provider in a foreign country can afford to break a lot of glassware these days. What are the victims going to do?
Plus, as BenjaminRi pointed out, the stealthiness threshold isn't exactly fixed, either. Realistically, a state actor targeting the infrastructure of a commercial hosting services provider in a foreign country can afford to break a lot of glassware these days. What are the victims going to do?
Reverse-engineer the attacker activity and publish technical details online. Once those details are published, the exploits they're using to get in and the tools that they're implanting in the malicious updates become significantly less valuable. Which is problematic if they spent a lot of money building the pieces for the attack.
I think my writing there was imprecise. I agree, there are things victims can do to inconvenience foreign state actors, and while one victim doing that isn't a lot, if everyone gangs up then a history of bad risk/benefit analyses will begin to hurt.
What I meant is that state actors enjoy a quasi-monopoly on violence at home and, past a certain threshold, wide-reaching impunity abroad, so the consequences of being found aren't quite as bad as they are for, say, organised crime. So they don't have an immediate need to outmaneuver law enforcement in all their ops the way organised crime does, and can afford less stealthiness if it's economically feasible. Sure, sometimes they need to, for various reasons (politically sensitive op, burning a zero-day etc.) but the mere fact of an attack being potentially linked to them isn't as big a deal.
Organised crime orgs can get shut down very theatrically from leaving sufficiently easily-followed traces even just one time. I don't think the PLASF is in as bad a pickle if it turns out it really was them. They could literally leave a note saying "hey it was us, greetings from Beijing, kind regards gen. Zhang" and nothing's going to happen, because we simply don't have credible international institutions and channels to deal with that.
I.e. when I said "what are the victims going to do?" I meant it as in, what, is Don Ho (Notepad++'s author) going to call the Internet police on the PLASF?
Organised crime orgs can get shut down very theatrically from leaving sufficiently easily-followed traces even just one time. I don't think the PLASF is in as bad a pickle if it turns out it really was them. They could literally leave a note saying "hey it was us, greetings from Beijing, kind regards gen. Zhang" and nothing's going to happen, because we simply don't have credible international institutions and channels to deal with that.
I.e. when I said "what are the victims going to do?" I meant it as in, what, is Don Ho (Notepad++'s author) going to call the Internet police on the PLASF?
That makes sense. I was pointing out that, even though these state-affiliated actors have little to fear from attribution for the most part[1], and nearly nothing to fear from international policing, they still have significant reasons to prefer stealth. Those reasons are that as their tools and techniques become better known, they become less effective, and they spend money to develop/acquire those tools and techniques. Whether they're zero-day exploits or remote-access toolkit payloads. In this case, the ability to silently infect notepad++ uses was very valuable. Now it's at worst lost and at best less valuable.
[1]: While they may not mind being attributed, I don't think taking credit for their attacks is good for any of them, or a thing we'll likely see; if they admit things beyond a certain scale, retaliation could happen during things like trade negotiations or even imposition of sanctions that will give them much less impunity domestically as their executives deal with those.
even though these state-affiliated actors have little to fear from attribution for the most part[1], and nearly nothing to fear from international policing, they still have significant reasons to prefer stealth.
They also have significant reasons to keep their powder dry for a case where stealth is absolutely necessary, and every time you use an exploit you risk burning it.
I was pointing out that, even though these state-affiliated actors have little to fear from attribution for the most part[1], and nearly nothing to fear from international policing, they still have significant reasons to prefer stealth.
Oh, definitely. It's not just that it makes tools less effective, as you rightly point out, it's also that simply exposing their TTPs can be problematic. No team is infinitely skilled across all the range of offensive and defensive skills. Simply exposing what they're good at tells others what to watch out for, and implicitly communicates what they might not be as good at. A general disregard for stealth is definitely a bad stance, including for the reasons you mentioned in your footnote.
The post I was responding to came from a slightly different position: the technique being used was, itself, unstealthy, though not very sophisticated. The overall calculus is the same, of course -- a state-affiliated actor, like any red team, should aim for not being exposed.
Where I think the difference lays is the weights of the various factors being considered when assessing the risk of exposure. If lack of stealth is inherent in some intrusion method, the decision to greenlight it or not vs. the immediate gains it brings is just made along different lines for state actors, who have some means to protect their operatives, can leverage loyal press to take some flak or redirect public attention and so on. Things that we (as in industry professionals) would write off as too primitive may hold out way better than we expect in risk assessment meetings.
Is it really that frequent? Last one I remember was the jabber.ru interception, now this. What other examples have I missed?
TLS interception requires the server’s hosting provider to be compromised so that the attacker can perform on-path spoofing of ACME. I haven’t heard that hosting providers are routinely violated in this manner.
I think it's commonplace that it's actually getting difficult to point out specific examples!
The jabber.ru one was probably very targetted and done close to site. Like this one for notepadd++ it seems. I guess these are pretty uncommon, or at least not widely known.
Then you have Amesys and Bluecoat, selling interception boxes for use by corporations. And also selling these to various dictatorships (IIRC respectively Libya and Syria 15 years ago).
Ah I thought you were only talking about MITM attacks against specific servers.
AIUI much of the work on certificate authority compliance and certificate transparency was intended to prevent ISPs from running mass TLS interception. I believe that nowadays it should be impossible for an ISP to MITM its users.
Corporate interception is done with the informed consent of the owners of the client devices so strictly speaking it isn’t an attack. (Tho arguably the users are under some degree of duress and the servers don’t get a choice.)
What a wild disclosure format. None of the questions I might have as a user are answered: am I affected? What actions should I take if I am? The question of whether I should continue to use their software at least is answered very clearly by their wanton attitude to this situation...
That statement from the provider is awkward on mobile, with horizontal scrolling.
Dear Customer,
We want to further update you following the previous communication with us about your server compromise and further investigation with your incident response team.
We discovered the suspicious events in our logs, which indicate that the server (where your application https://notepad-plus-plus.org/update/getDownloadUrl.php was hosted until the 1st of December, 2025) could have been compromised.
As a precautionary measure, we immediately transferred all clients’ web hosting subscriptions from this server to a new server and continued our further investigation.
Here are the key finding points:
The shared hosting server in question was compromised until the 2nd of September, 2025. On this particular date, the server had scheduled maintenance where the kernel and firmware were updated. After this date, we could not identify any similar patterns in logs, and this indicates that bad actors have lost access to the server. We also find no evidence of similar patterns on any other shared hosting servers.
Even though the bad actors have lost access to the server from the 2nd of September, 2025, they maintained the credentials of our internal services existing on that server until the 2nd of December, which could have allowed the malicious actors to redirect some of the traffic going to https://notepad-plus-plus.org/getDownloadUrl.php to their own servers and return the updates download URL with compromised updates.
Based on our logs, we see no other clients hosted on this particular server being targeted. The bad actors specifically searched for https://notepad-plus-plus.org/ domain with the goal to intercept the traffic to your website, as they might know the then-existing Notepad++ vulnerabilities related to insufficient update verification controls.
After concluding our research, the investigated security findings were no longer observed in the web hosting systems from the 2nd of December, 2025, and onwards, as:
We have fixed vulnerabilities, which could have been used to target Notepad++. In particular, we do have logs indicating that the bad actor tried to re-exploit one of the fixed vulnerabilities; however, the attempt did not succeed after the fix was implemented.
We have rotated all the credentials that bad actors could have obtained until the 2nd of September, 2025.
We have checked the logs for similar patterns in all web hosting servers and couldn’t find any evidence of systems being compromised, exploited in a similar way, or data breached.
While we have rotated all the secrets on our end, below you will find the preventive actions you should take to maximize your security. However, if below actions have been done after the 2nd of December, 2025, no actions are needed from your side.
Change credentials for SSH, FTP/SFTP, and MySQL database.
Review administrator accounts for your WordPress sites (if you have any), change their passwords, and remove unnecessary users.
Update your WordPress sites (if you have any) plugins, themes, and core version, and turn on automatic updates, if applicable.
We appreciate your cooperation and understanding. Please let us know in case you have any questions.
Is has been a solid choice for the past 10+ years - I don't know if this event on state level actor taking over the hoster speaks about the quality of the software itself.
I very vaguely recall there being a pretty big vulnerability in Notepad++ a few years ago wrt. opening untrusted text files, but I can't find anything on it right now; the search results are all either about this compromise, or some fake CVE from last year. Am I just mistaking it for another editor, or was this actually a thing that I just cant find right now?
freddyb | 18 hours ago
What?
olliej | 10 hours ago
I can't believe a well funded company with multiple highly paid application and infrastructure security experts isn't able to provide more robust guarantees than this.
technomancy | 8 hours ago
I can't believe so many people are willing to download software from a party who can't provide basic security guarantees. (Just kidding; I can. But I wish I couldn't!)
olliej | 7 hours ago
On the other side of that, do you know of any OSS/hobby/volunteer/small-company that can provide this kind of "basic" security guarantee? I'm not being deliberately obtuse here, but what we're seeing here is "your project's threat model is the union of all your user's threat models", which means if one of your users is considered important enough to warrant government level resources being deployed against them, you are now in that path as well.
technomancy | 7 hours ago
Not many! That's why I install software thru apt. [edit: to clarify; I can think of lots of hobby/volunteer projects that do better than notepad++, but I can't think of many that do a good enough job that I would trust them to do the job of distribution. if they leave that work up to people who are experts in distribution, I see that as a good sign.]
But in general, I think it's better to omit an auto-update function than to include one that doesn't do basic checks. (Enabling TLS certificate verification is one such basic check.)
olliej | 4 hours ago
I'm unclear what verification was not occurring - as far as I can make out from the blog post their infrastructure was compromised and was returning compromised binaries, no indication of a TLS failure. I'm unclear what the post means when saying it now verifies the "certificate and signature" for updates - if they've got a TLS library that isn't verifying signatures, let alone certificates, that's a broken TLS library not the client. If they mean they've got code signing for updates then they were already trying to do better update security than most other auto-updating software.
TLDR for the edits below as I went through a journey of discovery: They use wingup to do updates and similar, and as far as I can make out the default behavior of that is to silently ignore signing entirely, and even if you do say "actually check the signature" it looks like it might not check the trust chain, etc by default???
[edit: oh I see, they used their own self signed key for code signing, but the interface used to perform verification is broken as it defaults to "is this correctly signed" rather than "is this correctly signed with a given certificate". So 50/50 fault: they decided not to use a trusted root meaning that they couldn't rely on default authentication working, and then the interface used for verification doesn't require a certificate (set) to verify against]
[further edit: 100% fault - SecurityGuard is their own wrapper around WinTrust, which while looking like a truly garbage API, they made a wrapper that maintains those bad defaults][yet another edit, I don't really think this is their fault: while SecurityGuard is their wrapper around WinTrust, it's WinGUP that is responsible for doing the update check and is where they're setting up the change in defaults, as far as I can tell by default it apparently does not perform any actual certificate validation, and I'm sure if I had decided to use a tool like this it would not have occurred to me that that was even an option, let alone the default]
BenjaminRi | 14 hours ago
Total amateur show. Also see the comment in the blog post linked above (https://doublepulsar.com/small-numbers-of-notepad-users-reporting-security-woes-371d7a3fd2d9):
I just checked and it's still implemented this way. I love Notepad++ but it is now clear that it's dangerous to use this tool.
Halkcyon | 17 hours ago
I feel like that's always been the vibe with these community-loved tools. Most of them don't pay much mind if any to infosec/opsec.
nicoco | 15 hours ago
Maybe the fact that their communication is honest is part of why they are loved. Perfect absolute flawless security does not exist, despite what $ANYCORP could claim.
Halkcyon | 14 hours ago
Sure, but "oopsy, I didn't care about your security! tee-hee!" is both honest and should be disqualifying. I know that's not what happened here, but it is common to see breaches and everyone shrugs if they aren't personally affected if the tool falls into this "beloved" status (a certain games store comes to mind).
BenjaminRi | 22 hours ago
This is absolutely bonkers. I guess the only defense I had against this (running Notepad++ on all my devices) is that I am too unimportant to be targeted.
But the post is extremely thin on details. What kind of exploit was being shipped to targeted users? How can I check if I'm affected?
tr4656 | 20 hours ago
See https://doublepulsar.com/small-numbers-of-notepad-users-reporting-security-woes-371d7a3fd2d9
osa1 | 20 hours ago
I'll save others a click to a Medium site:
It has just this about the exploit.
I'm assuming that if a victim is skilled enough to recognize "keyboard recon activity" and report it, surely they must've shared the binary with the exploit as well, right? Is anyone analyzing it yet?
timthelion | 19 hours ago
What is keyboard revon and howwould I notice it?
Gaelan | 18 hours ago
From context, I think they mean that there's someone at the other end typing in commands to run on the compromised computer - i.e. the attacker is giving each compromised computer individual attention, rather than an at-scale attack where the exact same malicious thing is done on every computer.
It's recognizable if you have a log of commands executed - the sort of commands you'd see from a human poking around are pretty distinct from what an automated exploitation script would do, and might even include typos and such.
BenjaminRi | 20 hours ago
Fetching update instructions via HTTP is madness, I wonder up to which version it was done like that. But it seems like at the point where this blog post was written, it wasn't known that Notepad++'s host was compromised and they conjectured the cause to be TLS intercept.
david_chisnall | 19 hours ago
It's not automatically a bad idea, as long as you are not concerned about confidentiality and do integrity checking via another mechanism. The FreeBSD
pkgtool use HTTP for a long time because the package database was signed with a private key and the individual packages had cryptographic hashes stored stored in the package database, and this made it easy to put a caching proxy in front of the package site for a bunch of machines to share. It moved to HTTPS because a bunch of places had an HTTPS-only policy (which is sensible: mandating HTTPS everywhere is a simpler policy to get right than HTTPS-except-when-you-have-a-good-reason-that-HTTP-is-secure).But if you're just downloading things and not verifying them, especially executable things, HTTP is a disaster.
kevincox | 16 hours ago
Even cases like this with a package database it is pretty complex. For example you need to be very careful that an attacker can't perform an unintentional rollback. This could possibly result in older (signed) packages with vulnerabilities being used (either not upgraded or the packages themselves rolled back).
ThinkChaos | 16 hours ago
APT servers used HTTP for a long time for similar reasons.
Still, why would I want anyone near the network path to know which packages I download? That information can reveal a lot.
technomancy | 13 hours ago
Honestly I suspect the main reason Debian stopped using HTTP for this is so that people would stop saying "Well, Debian does it, so we can do it too" without realizing that Debian has a whole lot more going on behind the scenes that made it safe in this one case.
k749gtnc9l3w | 12 hours ago
Does apt download the updates smoothly enough within a single connection to block size fingerprinting of individual packages?
ThinkChaos | 10 hours ago
The path includes the package name & version:
http://http.us.debian.org/debian/pool/main/c/curl/curl_8.14.1-2+deb13u2_amd64.debk749gtnc9l3w | 10 hours ago
If this goes over HTTP, everything is in the open, sure — my question is whether the move to HTTPS hides that information reliably.
ThinkChaos | 8 hours ago
Ah. I don't know enough to answer that.
HTTPS is an upgrade either way.
zie | 5 hours ago
Well, URL's are encrypted on the wire, but are not usually encrypted anywhere else. SNI is not usually encrypted(but it's at least possible in certain configurations), so they can see on the wire that you hit http.us.debian.org, but not debian/pool/main/c/curl/curl_8.14.1-2+deb13u2_amd64.deb
Though I bet with a little bit of work the metadata available, like package sizing would give you a pretty great clue as to what package is being requested. (I haven't done any of this work, but I imagine it would work fairly well for debian packages)
BenjaminRi | 19 hours ago
That is a good point, there is nuance to it indeed. As you said, if you are not concerned about confidentiality and have another root of trust with which you verify, it's fine.
Yeah.
bdesham | 5 hours ago
I think it’s worth pointing out that the “you” here refers to the package providers (the Debian or FreeBSD package databases), not the package users. If the only supported transport is HTTP, then it doesn’t matter whether the users are concerned about confidentiality; it’s not available to them either way.
olliej | 10 hours ago
HTTP was the norm, but as demonstrated here that's kind of moot if the ISP is compromised.
That's why an embedded signature in the file is needed, even when transferred over TLS. Though if an app does adopt that the developers of the app have to assume that by proxy their own system is now being subjected to the same level of attacker scrutiny.
dzwdz | 20 hours ago
If anyone is curious, dnshistory.org seems to suggest the old hosting provider was Hostinger, up to as late as 2 weeks ago. They've now switched to Aqua Ray
which seems less trustworthy, tbh.This is not meant to be a dig at Hostinger in any way. I think their response was professional (the author seems satisfied with it too?). Getting hacked is a bad look, but we don't know how they got hacked, and since we seem to be dealing with state-sponsored hackers... could've happened to anyone, really.
nicoco | 15 hours ago
This is really important to stress out IMHO. Cryptography (and cybersecurity in general) is needed and an interesting field (cool maths, what's not to love about it?), but I feel sometimes people have delusion of grandeur about how far one can fight back about state-level actors. When your threat model is intelligence services with next to unlimited resource, it's over before it even starts.
olliej | 10 hours ago
No idea of the scale of these hosting services, but I have noticed a belief that smaller providers are "more trustworthy", but if your concern is attackers at this scale and complexity then hypothetical differences in trustworthiness (esp. ones based primarily on corporation size) is secondary to ability to invest in infra security and hardening.
But also you need to simply start assuming your infra is compromised and verify information is correctly verified through other channels
ptman | 22 hours ago
Tangential, but: XML signing is a shitshow. I'm fairly confident that we haven't seen the end of vulnerabilities with XML signing. Signatures should not be embedded in the signed data and require normalization dances.
masklinn | 19 hours ago
mayas | 21 hours ago
I feel a bit relieved, at least, because it seems the issue was caused by a vulnerability with the hosting provider.
adrien | 20 hours ago
Something I find interesting with the various attacks is that they're not new techniques at all. Quite often they could be considered fairly basic (TLS interception isn't news). However, we used to consider these threats are not very likely to happen in the open because they're not very stealth.
Fast-forward today and we get news of them every few months or even weeks. Intercepting traffic of everybody using notepad++ to target a limited number of opponents in a specific region to exfiltrate data? No hesitation.
I guess the main change is the proliferation of state-sponsored groups that aren't directly part of these states and offer plausible deniability (or just silence).
BenjaminRi | 19 hours ago
In a world where international rules mean nothing, there is no need to pretend.
x64k | 17 hours ago
But the stealthiness of a technique isn't just an inherent trait of its technical means, it's also a measure of monitoring and review in the system it's used against. In its most basic form (I'm not saying this is what happened, it's just the canonical example of this distinction) any threat is 100% stealthy if no one's watching. TLS interception isn't inherently stealthy on its own. But if you only need it to work for a few weeks, and you know no one's going to look for it for a few weeks, you've got yourself an extremely stealthy attack.
Plus, as BenjaminRi pointed out, the stealthiness threshold isn't exactly fixed, either. Realistically, a state actor targeting the infrastructure of a commercial hosting services provider in a foreign country can afford to break a lot of glassware these days. What are the victims going to do?
hoistbypetard | 16 hours ago
Reverse-engineer the attacker activity and publish technical details online. Once those details are published, the exploits they're using to get in and the tools that they're implanting in the malicious updates become significantly less valuable. Which is problematic if they spent a lot of money building the pieces for the attack.
x64k | 14 hours ago
I think my writing there was imprecise. I agree, there are things victims can do to inconvenience foreign state actors, and while one victim doing that isn't a lot, if everyone gangs up then a history of bad risk/benefit analyses will begin to hurt.
What I meant is that state actors enjoy a quasi-monopoly on violence at home and, past a certain threshold, wide-reaching impunity abroad, so the consequences of being found aren't quite as bad as they are for, say, organised crime. So they don't have an immediate need to outmaneuver law enforcement in all their ops the way organised crime does, and can afford less stealthiness if it's economically feasible. Sure, sometimes they need to, for various reasons (politically sensitive op, burning a zero-day etc.) but the mere fact of an attack being potentially linked to them isn't as big a deal.
Organised crime orgs can get shut down very theatrically from leaving sufficiently easily-followed traces even just one time. I don't think the PLASF is in as bad a pickle if it turns out it really was them. They could literally leave a note saying "hey it was us, greetings from Beijing, kind regards gen. Zhang" and nothing's going to happen, because we simply don't have credible international institutions and channels to deal with that.
I.e. when I said "what are the victims going to do?" I meant it as in, what, is Don Ho (Notepad++'s author) going to call the Internet police on the PLASF?
hoistbypetard | 14 hours ago
That makes sense. I was pointing out that, even though these state-affiliated actors have little to fear from attribution for the most part[1], and nearly nothing to fear from international policing, they still have significant reasons to prefer stealth. Those reasons are that as their tools and techniques become better known, they become less effective, and they spend money to develop/acquire those tools and techniques. Whether they're zero-day exploits or remote-access toolkit payloads. In this case, the ability to silently infect notepad++ uses was very valuable. Now it's at worst lost and at best less valuable.
[1]: While they may not mind being attributed, I don't think taking credit for their attacks is good for any of them, or a thing we'll likely see; if they admit things beyond a certain scale, retaliation could happen during things like trade negotiations or even imposition of sanctions that will give them much less impunity domestically as their executives deal with those.
colonelpanic | 10 hours ago
They also have significant reasons to keep their powder dry for a case where stealth is absolutely necessary, and every time you use an exploit you risk burning it.
x64k | 12 hours ago
Oh, definitely. It's not just that it makes tools less effective, as you rightly point out, it's also that simply exposing their TTPs can be problematic. No team is infinitely skilled across all the range of offensive and defensive skills. Simply exposing what they're good at tells others what to watch out for, and implicitly communicates what they might not be as good at. A general disregard for stealth is definitely a bad stance, including for the reasons you mentioned in your footnote.
The post I was responding to came from a slightly different position: the technique being used was, itself, unstealthy, though not very sophisticated. The overall calculus is the same, of course -- a state-affiliated actor, like any red team, should aim for not being exposed.
Where I think the difference lays is the weights of the various factors being considered when assessing the risk of exposure. If lack of stealth is inherent in some intrusion method, the decision to greenlight it or not vs. the immediate gains it brings is just made along different lines for state actors, who have some means to protect their operatives, can leverage loyal press to take some flak or redirect public attention and so on. Things that we (as in industry professionals) would write off as too primitive may hold out way better than we expect in risk assessment meetings.
fanf | 13 hours ago
Is it really that frequent? Last one I remember was the jabber.ru interception, now this. What other examples have I missed?
TLS interception requires the server’s hosting provider to be compromised so that the attacker can perform on-path spoofing of ACME. I haven’t heard that hosting providers are routinely violated in this manner.
adrien | 12 hours ago
I think it's commonplace that it's actually getting difficult to point out specific examples!
The jabber.ru one was probably very targetted and done close to site. Like this one for notepadd++ it seems. I guess these are pretty uncommon, or at least not widely known.
From the other side, i.e. close to clients, you have stuff like https://arstechnica.com/information-technology/2015/01/gogo-issues-fake-https-certificate-to-users-visiting-youtube/ . I'm pretty sure many ISPs were doing it regularly, probably especially more "remote" places, including Australia. It has certainly gotten more difficult and more visible over the years so this case where the intent isn't completely nefarious is likely less common nowadays.
Then you have Amesys and Bluecoat, selling interception boxes for use by corporations. And also selling these to various dictatorships (IIRC respectively Libya and Syria 15 years ago).
fanf | 12 hours ago
Ah I thought you were only talking about MITM attacks against specific servers.
AIUI much of the work on certificate authority compliance and certificate transparency was intended to prevent ISPs from running mass TLS interception. I believe that nowadays it should be impossible for an ISP to MITM its users.
Corporate interception is done with the informed consent of the owners of the client devices so strictly speaking it isn’t an attack. (Tho arguably the users are under some degree of duress and the servers don’t get a choice.)
flisk | 7 hours ago
What a wild disclosure format. None of the questions I might have as a user are answered: am I affected? What actions should I take if I am? The question of whether I should continue to use their software at least is answered very clearly by their wanton attitude to this situation...
olliej | 3 hours ago
Ok, so here's how the attack seems to have worked as far as I can make out:
The blog links to an article on the exploit itself
pronoiac | 11 hours ago
That statement from the provider is awkward on mobile, with horizontal scrolling.
Dear Customer, We want to further update you following the previous communication with us about your server compromise and further investigation with your incident response team. We discovered the suspicious events in our logs, which indicate that the server (where your application https://notepad-plus-plus.org/update/getDownloadUrl.php was hosted until the 1st of December, 2025) could have been compromised. As a precautionary measure, we immediately transferred all clients’ web hosting subscriptions from this server to a new server and continued our further investigation. Here are the key finding points:
linhns | 13 hours ago
Wow. I came close to switching to Notepad++ at my previous job. No regrets now.
proctrap | 6 hours ago
Is has been a solid choice for the past 10+ years - I don't know if this event on state level actor taking over the hoster speaks about the quality of the software itself.
dzwdz | 4 hours ago
I very vaguely recall there being a pretty big vulnerability in Notepad++ a few years ago wrt. opening untrusted text files, but I can't find anything on it right now; the search results are all either about this compromise, or some fake CVE from last year. Am I just mistaking it for another editor, or was this actually a thing that I just cant find right now?