A Critical Windows DNS Flaw Lets Attackers Run Code on Any Machine Without Logging In
Want to learn ethical hacking? I built a complete course. Have a look!
Learn penetration testing, web exploitation, network security, and the hacker mindset:
→ Master ethical hacking hands-on
Hacking is not a hobby but a way of life!
Microsoft patched a critical heap buffer overflow in the Windows DNS Client. An attacker needs no account and no help from the person sitting at the machine to trigger it. Every Windows machine that performs DNS lookups is potentially in scope, and every Windows machine performs DNS lookups constantly.
The vulnerability is tracked as CVE-2026-41096 with a CVSS score of 9.8. It sits in a component called dnsapi.dll, the file that handles DNS lookups on every Windows machine. DNS, which stands for Domain Name System, is the system that translates domain names into IP addresses so computers know where to connect. Every time a browser loads a page, an application connects to a server, a VPN establishes, or Windows checks for updates, the system sends out a DNS query asking what IP address belongs to a given name. The DNS Client receives the answer, processes it, and passes it along.
CVE-2026-41096 is a flaw in how that answer gets processed.
When a DNS response arrives, the DNS Client reads what came back and picks out the information it was looking for. The flaw is in how it handles the data fields inside those responses. A response with a broken or oversized data field can cause the DNS Client to write more data into memory than the space set aside for it. In memory terms, a chunk of space was reserved for the answer, the malicious response is larger than that space, and the overflow spills into memory next to it, where the attacker can plant code or take over what runs next. This type of flaw is called a heap-based buffer overflow, and it is one of the oldest exploitation techniques around.
An attacker needs two things to trigger it. A Windows machine that processes DNS responses, which is every Windows machine. And a position to send that machine a malicious response. That position can be a rogue DNS server the attacker controls, or a man-in-the-middle position on the network where outgoing DNS queries can be intercepted and answered with crafted data. Public wifi networks, hotel connections, coffee shop hotspots, captive portals before a VPN connects, compromised home routers, poisoned corporate DNS resolvers: all of these give an attacker the position they need.
The DNS Client service, internally named Dnscache, runs under NT AUTHORITY\NETWORK SERVICE. That is not full system control, but it gives an attacker enough access to chain more attacks from there. Rapid7 noted in their report: the DNS client runs as NetworkService, not SYSTEM, but attackers chain multiple weaknesses. The code in dnsapi.dll has to handle all kinds of DNS record types, caching, retry logic, compressed names, modern features like DNS-over-HTTPS, and VPN routing. Every added feature means more code that processes attacker-controlled input.
Microsoft called exploitation unlikely in the advisory, but Dustin Childs of the Zero Day Initiative responded that since the DNS Client runs on virtually every Windows machine the attack surface is enormous, and an attacker who can influence DNS responses from a rogue server or a man-in-the-middle position could run code on every unpatched machine in an entire company without ever logging in.
Jason Kikta, CTO at Automox, pointed out that any Windows machine making a DNS request is potentially at risk, including every workstation behind a compromised resolver. Jack Bicer from Action1 added that it could spread across company networks fast.
Microsoft’s own advisory added a detail worth paying attention to: in certain configurations, this allows an attacker to run code remotely without authentication. Microsoft has not specified which configurations are required, and those details are not public yet. Until they are, treating every unpatched Windows machine as potentially at risk is the most reasonable approach.
This is not the first time a critical flaw has appeared in this exact component. In 2017, researcher Nick Freeman at Bishop Fox found three heap buffer overflows in dnsapi.dll, specifically in the function that processes NSEC3 DNS records. The overflow mechanics were similar: a record field overflowed the space set aside for it and corrupted nearby memory. That was CVE-2017-11779. It was patched. The underlying code was not rewritten.
There is one more detail about the Dnscache service worth knowing: when it crashes from a failed exploit attempt, Windows restarts it automatically. The person at the machine notices nothing, and the attacker keeps trying until something works.
Then in 2020, SIGRed arrived. CVE-2020-1350 was a wormable remote code execution vulnerability in the Windows DNS Server with a perfect CVSS score of 10.0. It had been sitting undetected in the code for 17 years. SIGRed targeted the DNS Server, the component running on domain controllers. CVE-2026-41096 targets the DNS Client, the component running on everything else.
The reason these bugs keep appearing in the same component is not random. The DNS Client code in dnsapi.dll is written in C++ and contains old code written before anyone took memory safety seriously. Microsoft has adopted the Rust programming language for newer kernel components, because Rust is designed from the ground up to prevent memory bugs like this one. The DNS Client has not been rewritten in Rust. It remains C++ code, reverse-engineered and analyzed repeatedly, patched in specific places while the core structure stays the same.
This month Microsoft confirmed for the first time that an internal AI system called MDASH independently found 16 vulnerabilities in the May 2026 release. If automated systems find bugs faster on the defensive side, attackers can use the same methods to find how to exploit it faster. Proof-of-concept exploit code typically appears on GitHub within a week of Patch Tuesday as researchers work backward from the patch to figure out what went wrong. May 12 started that clock.
Affected systems include Windows 11 versions 23H2, 24H2, 25H2, 26H1 and 22H3, and Windows Server 2022 and 2025 including Server Core installations.
The fix is the May 12, 2026 cumulative update through Windows Update. To verify the patch is installed, check the file version of dnsapi.dll:
| |
If patching right now is not an option, Microsoft published a temporary mitigation. Stopping and disabling the DNS Client service makes applications handle their own DNS lookups instead, skipping the vulnerable service:
| |
This breaks VPN clients and some enterprise applications that depend on the DNS Client service. It is a workaround, not a solution.
Enabling DNS over HTTPS or DNS over TLS via Group Policy encrypts DNS traffic so no one on the network can tamper with DNS responses on the way.
Blocking outbound DNS traffic except to your own internal DNS servers prevents machines from ever reaching a rogue one.
Monitoring for unusual behavior from the Dnscache process under svchost.exe, specifically abnormal child processes or unexpected outbound connections, catches anything that slips through while patching is still in progress.
| |
How to find and exploit real CVEs, how network-level attacks work from the attacker’s perspective, and how to escalate from initial access to full SYSTEM control on Windows machines is exactly what the ethical hacking course covers step by step:
Hacking is not a hobby but a way of life. 🎯
Sources: Microsoft MSRC | Zero Day Initiative
→ Stay updated!
Get the latest posts in your inbox every week. Ethical hacking, security news, tutorials, and everything that catches my attention. If that sounds useful, drop your email below.