WhatsApp zero-click zero-day attack: What to do?
0-click, 0-day, Oh dear! What you need to know, and what you can do right now.
Another week, another Windows security hole that’s turning up all over the news and social media.
This one is CVE-2026-41089, a stack-based buffer overflow vulnerability officially headlined by Microsoft itself as Windows Netlogon Remote Code Execution (RCE) Vulnerability.
Microsoft gave it a CVSS (common vulnerability scoring system) rating of 9.8/10, tagged it as Critical, and, as the bug headline above makes clear, described it as a potential RCE.
Remote code execution is a class of bug typically associated with attackers on the other side of the planet reaching out across the internet to implant malware silently into your network.
That’s the bad news.
The good news is that this bug seems to have been found by security researchers inside Microsoft, and was patched proactively nearly a month ago in the May 2026 Patch Tuesday updates.
If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.
Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
Despite providing a possible path of attack to anyone who can send UDP packets to your network, this vulnerability shouldn’t really be all over the news in the dramatic way that it has been.
But a curious and dramatic tweet from the Centre for Cybersecurity Belgium at the end of May 2026 seems to have kickstarted a bit of a fear-and-feeding frenzy:
The inference that many readers will quite reasonably make here is that cybercriminals have been breaking-and-entering networks at will, for all that the message hedges its bets by saying that the known attacks “could” lead to RCE.
The message also invites the conclusion that numerous cybercriminals have been successfully triggering this vulnerability from afar, although the text would still be true even if many or most of the detected attack attempts had failed.
Nevertheless, the advice to ensure that you have applied this patch is sound, not least because the bug only seems to be exposed on Windows Domain Controllers (DCs).
DCs are critical servers that manage and control access to most corporate Windows networks, so some IT managers may therefore paradoxically be more afraid of patching them than of leaving them at risk of exploitation.
I’ve also seen reports, including Github-hosted proof-of-concept (PoC) attack code apparently “borrowed” from other researchers, implying that the bug is reliably exploitable on almost any unpatched server․․․
․․․but my testing (combined with information from a writeup that isn’t on GitHub) suggests that:
DC1-GB.EXAMPLE.ORG or FINANCE.DEPT.AT.EXAMPLE.COM are unlikely to be exploitable even if unpatched. Unless your DCs have unusually long domain names and hostnames (details that an attacker can’t control remotely), the abovementioned buffer overflow will probably never happen, as covered below.
According to a report published (on an admittedly very new and curiously secretive website), CVE-2026-41089 is an old-school buffer overflow bug caused by poor programming choices.
Given that this bug goes back to Windows Server 2016, it’s likely to have been around for a decade or more, and was probably caused by a programmer making a hasty assumption.
Indeed, that assumption may have been valid back when they made it, namely that their code would need at most 528 bytes of space to do its work.
Whatever led them to this assumption, they explicitly reserved a fixed-size chunk of 528 bytes on the stack.
This vulnerable Netlogon code is used to help process username queries via what’s known as a Connectionless LDAP request (CLDAP), using the UDP protocol.
This allows a user or a device on the network to ask for a username search via the lightweight directory access protocol, a cross-platform network directory service that happens to be at the core of Microsoft Active Directory (AD).
Greatly simplified, the relevant query handler allows the request code to send in a username to look for, and the internet-style name (e.g. EXAMPLE.ORG) of the Windows domain in which that user’s account should be sought.
The attacker needs to use the DC’s real domain name in the query, or else the query processing will fail, but they can ask about a non-existent user, with a maximum of 130 characters in that username.
When processing the query, the code stores the username as a sequence of Windows “widechars”, which use 2 bytes per character, plus a terminating zero character, so a malevolent attacker can force the server to consume 130×2 + 2 = 262 bytes of the 528-byte buffer just for the username.
The query processing code also stores a bunch of other temporary data into the buffer, including the internet-style hostname of the DC server, and the internet-style name of the domain, both of which have variable lengths.
For example, in the sample name DC1-GB.EXAMPLE.ORG above, the internet domain name would be EXAMPLE.ORG, and the hostname would be DC1-GB.
You can see where this is going, and why this bug apparently never showed up in real life or in testing.
Many companies limit their Windows hostnames to 15 characters, which is the longest name compatible with old-school NETBIOS naming.
Most companies don’t use super-long domain names, either, because they’re a pain to type in.
Short hostnames and a short domain name, even combined with a rogue 130-character username in a malicious search request, won’t use up all 528 bytes in that worrisome fixed-length buffer.
In my testing, I deliberately set up a DC with a 64-character internet-style domain name (which seems to be the longest allowed by Active Directory when setting up a domain), to create a worst-case situation.
When I combined this with a 15-character internet hostname, I was unable to trigger this bug, regardless of the length of username I requested via CLDAP.
But when I renamed the DC to have a 63-character hostname, which for historical reasons is the maximum length of any single part of an internet name, and used CLDAP to look up an imaginary user with a 130-character username․․․
․․․the server-side query-handling code crashed reliably (if that is the right word in this context) and instantly.
When it crashes, the buggy code exits abruptly with Windows error 0xC0000409, the numeric code for STATUS_FAIL_FAST_EXCEPTION.
Fail Fast exceptions are special errors that Windows handles as abruptly as possible, without calling any error logging, exception handling, or cleanup code in the offending program.
These exceptions are typically triggered when a stack buffer overflow is detected, as in this case, meaning that it is no longer safe to allow the affected program to execute any more instructions.
Letting the program try to recover or clean up on its own, or even just to report the error, would be dangerous because its memory space is already known to be corrupted.
Unfortunately, if an attacker successfully triggers CVE-2026-41089, the process that gets “fast failed” just happens to be LSASS, the Local Security Authority Subsystem Service, a critical privileged process that takes care of security in and between Windows processes.
Once LSASS crashes, the system needs to reboot in order to reinitialize in a known (and hopefully unmodified) sequence such that a fresh copy of LSASS loads up in advance of the programs and users it will be taking care of.
Windows therefore displays an emergency popup saying, “Your PC will automatically restart in one minute․․․ You should close this message now and save your work,” as speeded up and shown here:
Of course, if you use short server and domain names and therefore consider your risk from this bug to be low, don’t use that as an excuse to put off those patches!
After all, if you’re invulnerable for that reason, that’s down to good fortune, not good judgement.
Don’t leave cybersecurity to luck – talk to SolCyber about signing up for a human-led, human-centric cybersecurity service that will free you up to concentrate on your core business.
Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
0-click, 0-day, Oh dear! What you need to know, and what you can do right now.
Businesses are desperate for cybersecurity offerings, and business owners often turn to you, the MSPs, for help. An MSP is the logical first choice to consult because you’re already handling the business’s IT. Unfortunately, the sophistication and growing number of cybersecurity threats mean that MSPs may not have the resources or expertise to stay current and offer their customers reliable and consistent security service. Organizational cybersecurity needs have grown multifaceted and vast. The move to cloud-first services opens the door […]
When it comes to cybersecurity, just how safe is your mobile device? Can it protect you from yourself?
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
