Understanding CVE-2026-105483

Context for CVEs

It's been a big week for vulnerabilities. We found out that you can just have 4 as your private key for years and nobody noticed. We learned that PHP has had a horrific RCE for decades. More and better bloggers than I are going to cover those to death in detail that I can't even aspire to. In the onslaught there's a much funnier one, though: CVE-2026-105483. By the way, if you're running a Node app you do need to patch the other vulnerability: CVE-2026-111497. Seriously, go patch or mitigate that one right now then come back to read.

The vulnerability we're talking about only affects Node.js, and while it's nominally a security vulnerability it's not particularly exploitable. It's important to know how to come to that conclusion though, and for that matter what's a CVE anyway?

CVE, which stands for Common Vulnerabilities and Exposures, is in the simplest terms a database of potential security problems for programs. The database started in the late 90's and was a response to one of the hardest problems on the planet: naming things.

As long as programs have existed there have been security vulnerabilities, but before the CVE system's widespread adoption (and even after,) it can be difficult to talk about them. Every vendor maintained its own bug database but many vendors are going to share the same code. If there's a vulnerability in zlib, a popular compression library, and I'm an Oracle shop while you're an IBM shop, we might have a problem. I might know that vulnerability as Oracle Patch 48738321098. You might know it as IBM bug 898774231348427 (IBM has been in business a lot longer, after all.) These are the same vulnerability with the same fix but if we're talking to each-other we may not realize this. Even worse: most vulnerabilities fall under relatively few categories. This is why things like the OWASP Top 10 can exist. It's inconvenient if I tell you about my Oracle fix for that buffer overflow, you go Oh, I think that's this IBM number. I have that fixed already., and it's fixed. It can be catastrophic if you think that and it's a new vulnerability you haven't patched.

So in response to this, more or less, the US Government stepped in. It partnered with the MITRE Corporation, a non-profit here, and funded the creation of a single authoritative name and description format for security vulnerabilities. Whether I'm running on AWS and you're on Azure, or if you're self hosted, or if you don't have any servers at all, if I tell you about a CVE then we all have access to that database. Some of these names and words may ring a bell if you read the news because the CVE system underwent a funding crisis in 2025 for reasons which weren't ever fully disclosed, as far as I know. Luckily the program is now fully funded, so you don't have to worry about the system falling over any time soon.

The NPM Vulnerability

CVE-2026-105483 (I'll probably just call it The Bug from now on,) is a vulnerability in the TLS validation code of Node.js, now fixed. For reasons we're going to get into this is not a particularly exploitable vulnerability, but that raises a question: why does this have a CVE if it's not exploitable? This is mostly a case of better safe than sorry, plus some tricky social factors. It could possibly be that the person who found it can't think of a way to exploit it, but there is one. On the social side having a CVE looks better if you're a security researcher because this is a real, confirmed CVE, not just some bug. It also helps downstream: if I tell my boss I have to push back a deployment by a couple hours to fix something, it's easier if I can point to the CVE. Part of why I chose this bug is that it demonstrates an important skill that not a lot of people talk about: we have this vulnerability in code we're shipping. Are we actually vulnerable? Can we do anything to mitigate it? Sometimes, like here, the answer is probably that you shouldn't go out of your way to fix it. Sometimes we need to take the whole website down to prevent exploits, like many PHP sites are at time of writing.

In this case how do we know it's not something to worry about? We have to look at the bug itself. I would link the CVE here, but the CVE website appears to be down, presumably to make sure that mitigations are in place for the PHP bombshells. Instead the best we have is the patch which fixed it. Don't worry, we aren't diving too deep into code. There are just a few important things to know going in:

  1. When connecting securely to a website, this is done with a certificate. This certificate says that a website is who it claims to be and one of the ways it does this is with a hostname verification. Essentially the certificate says This certificate is valid for example.com and your browser makes sure that you're browsing to example.com.
  2. There are 2 primary ways of identifying a computer on the internet: its IP address, which is like a mailing address, or via DNS (Domain Name Service,) which is a more memorable name like Just Enough Technology. Your computer is capable of looking up Just Enough Technology and seeing its corresponding IP address, which is why you can connect to it. You have to turn that name into an IP address to connect.
  3. Unicode is hard. Unicode, a standard for representing text on computers (to hand-wave it a bit,) includes many entries which visually look very similar but are different to computers. Of particular interest here are the Double Width Digits. Can you spot the difference between these two 3s at a glance? 3 and ３. You probably only noticed because the latter rendered in a different font. They're both clearly 3.
  4. Next, Unicode is even harder than that. Because of the case above, it defines so-called normalization rules: how to transform a piece of text into its canonical form. An example in English is that you'll often see text on tickets and such translated to ALL CAPS.

The confluence of these 4 was the problem. In order to set up the attack, step 1 is that I have to connect to another computer specifically by its IP address. We'll call the IP address 3.3.3.3 for simplicity's sake. Step 2 is that you have to be intercepting my traffic to the other computer for some malicious reason. In this case you've inserted yourself into the network and are claiming to be 3.3.3.3.

With the scenario set up, my computer tries to connect to 3.3.3.3. Instead of connecting to the server I wanted, I've connected to you! Luckily, we have TLS protecting the connection. My computer asks yours for a certificate, which yours returns. That certificate says that it's for the host ３.3.3.3. Note the first 3 is double-width. The textual representation of an IP address does not have a double width character in it, so it's not an IP address. Therefore (according to the code) it must be a domain name. Domain names are normalized, so we apply the normalization rules. ３.3.3.3 becomes 3.3.3.3, then we perform our check: is 3.3.3.3 (the IP address I tried to browse to) the same as 3.3.3.3 (the post-normalization host in the certificate)? Yes it is! You've successfully convinced me that I'm talking with the real server while I'm talking with you.

So why isn't this a vulnerability? We've shown exactly how you could perform a Man-in-the-Middle attack. The problem is that it's actually not very practical to execute. It relies on connecting directly to an IP address without going through DNS, which is going to be relatively rare. Even within corporate networks that sort of direct connection is rare. The other part is that for this to work the attacker needs a certificate which your computer already trusts. Your computer ships with a set of trusted certificates, which you might know from the eMudhra disclosure this week (heck of a week for a Wednesday, isn't it?) When your computer retrieves a new certificate, it sees if one of the certificates it already trusts has vouched for it. The attacker needs to get a valid certificate for you to trust and, quite simply, they can't get that for a domain like 3.3.3.3 for many very good reasons. The only way an attacker could pull this off is if they had the ability to get you to trust random certificates, and that level of control means that they've already done better than intercepting your encrypted browser traffic. They could just install a keylogger, capture your screen, or any myriad of other things. You're almost certainly safe from this one, and if you're not you have much bigger problems.

Conclusion

So why bother talking about this at all? For one, it's an interesting bug. It hits a surprising number of intersections for a patch which amounts to fewer than 5 lines, ignoring comments. For another, it came out in context. Triage is an absolutely essential skill in bug hunting as well as security response. The bug wasn't going to get you hacked. If you were focused on this potential Man-in-the-Middle and missed the Remote Code Execution I told you to go patch first at the start of the article, then maybe your response to the bug got you hacked. Securing your servers is great. Make sure you secure them against the things that matter first.