NLnet Labs disclosed CVE-2026-42944 on May 20, 2026, as a high-severity Unbound DNS resolver vulnerability affecting versions 1.14.0 through 1.25.0, where crafted queries containing multiple NSID, DNS Cookie, and EDNS Padding options can trigger a heap overflow and crash the service. The fix is in Unbound 1.25.1, released the same day as part of a broader security update. This is not a Windows kernel bug or a Microsoft DNS Server flaw, despite appearing in Microsoft’s Security Update Guide feed. It is a reminder that Windows networks depend on more than Windows code, and DNS remains one of the least forgiving places to discover memory-safety debt.
CVE-2026-42944 sits in an uncomfortable category: a vulnerability that may not hand an attacker the keys to the kingdom, but can still knock the kingdom’s directory service out of reach. The affected component is Unbound, NLnet Labs’ widely used validating, recursive, caching DNS resolver. In plain terms, it is the software many networks rely on to turn names into addresses quickly, locally, and with DNSSEC validation when configured.
The specific failure involves EDNS, the extension mechanism that lets DNS carry additional options beyond the protocol’s older limits. The vulnerable path appears when Unbound encodes a reply packet after receiving multiple instances of certain EDNS options: NSID, DNS Cookie, and EDNS Padding. The vendor description points to a size-calculation flaw where the EDNS field length can be truncated, after which the encoder writes more data than the allocated heap space can hold.
That is the kind of bug that sounds esoteric until you remember where DNS lives. It is not a decorative service. It is the thing that makes authentication endpoints, package repositories, SaaS applications, VPN gateways, telemetry endpoints, update servers, and internal line-of-business applications reachable by name. A DNS resolver crash can look to users like “the internet is down,” even when every router, firewall, and uplink is technically still alive.
Microsoft’s listing matters because many defenders consume MSRC data as part of a broader vulnerability-management workflow, not because Microsoft owns the affected code. The MSRC entry’s availability language is severe: total loss of availability, sustained while the attack continues or persistent until the condition is cleared. That tracks with the practical risk here. If an attacker can send the right kind of DNS query to a vulnerable resolver, they may be able to repeatedly crash it.
NSID, or Name Server Identifier, lets a DNS server identify itself in responses, which can help operators debug anycast and distributed DNS deployments. DNS Cookies are intended to make certain spoofing and amplification attacks harder by adding lightweight request-response state. EDNS Padding is a privacy feature, used to obscure message sizes and make traffic analysis harder, particularly in encrypted DNS contexts.
Individually, none of those options is exotic. The problem is what happens when an attacker supplies multiple instances of them and the resolver’s reply-building logic fails to account correctly for the combined size. The advisory’s language is important: this is not described as an attacker writing arbitrary bytes of their choosing into memory. It is described as an overflow write of Unbound-controlled data that eventually causes a crash.
That distinction matters, but it should not be over-relied upon. Security history is full of bugs that began life as “just a crash” before researchers found sharper edges. For now, the responsible operational stance is to treat CVE-2026-42944 as a denial-of-service vulnerability with a clear network trigger and a patch available, not as a proven remote-code-execution emergency.
This is how infrastructure bugs become weekend incidents. Nobody on the team thinks, “We run an EDNS option laboratory.” They think, “We run a DNS resolver.” The vulnerable behavior hides behind features that are either useful, privacy-preserving, or easy to inherit through distribution defaults.
Unbound’s footprint also cuts across the neat boundaries Windows admins often use to triage risk. A Windows-heavy organization may still run Unbound on Linux appliances, BSD firewalls, recursive resolver VMs, containers, campus network services, or bundled security products. Home lab users and small offices may run it behind Pi-hole. Hosting providers may expose recursive or forwarding resolvers to customer networks. The affected code is not Windows code, but the outage will still land on Windows desktops if those desktops depend on the resolver.
That is why the correct inventory question is not “Do we have this CVE on Windows?” It is “Which DNS resolvers do our Windows clients, servers, VPN users, domain controllers, and management tools actually rely on?” In many environments, the answer is messier than the diagram.
A resolver that repeatedly crashes under crafted traffic creates a strange kind of outage. The network may not be saturated. The firewall may show no obvious volumetric attack. The authoritative DNS servers may be healthy. Yet users cannot reach anything by name because the local recursive layer is falling over faster than service managers can restart it.
That is the danger embedded in the MSRC-style “total loss of availability” phrasing. The attacker does not need to corrupt business data or steal credentials to create serious impact. If users cannot resolve identity-provider names, software-update names, endpoint-management names, or internal service names, the result is business interruption by dependency collapse.
The practical severity also depends on exposure. A public recursive resolver that accepts queries from the internet faces a different risk profile than an internal resolver reachable only from a locked-down subnet. But internal does not mean safe. Malware on a workstation, a compromised IoT device, a guest VLAN escape, or an abused VPN account may provide enough query access to turn the resolver against itself.
De-duplication is a defensive move that says, in effect, “Even if the request contains repeated instances of these options, the response encoder should not carry that multiplicity forward in a dangerous way.” The size-calculation fix addresses the arithmetic failure that let the allocation and the write disagree. Either one of those fixes might reduce risk; together they close both the malformed-input path and the memory-accounting mistake.
For administrators, the upgrade target is straightforward: move to Unbound 1.25.1 or a distribution package that backports the relevant patch. The latter point matters because enterprise Linux and appliance vendors often keep the old upstream version number while applying security fixes downstream. A system reporting an older Unbound version is not automatically vulnerable if the distribution has backported the patch, but it should be verified through vendor changelogs, package metadata, or security advisories rather than assumed.
There is also a configuration-based mitigation logic here, though it is inferior to patching. If the relevant features are disabled, the vulnerable path may not be reachable. But disabling DNS Cookies or padding can carry security or privacy tradeoffs, and configuration drift is a poor long-term substitute for corrected code. The safest durable answer is patched software plus sensible network exposure controls.
Modern Windows environments are hybrid by default. Active Directory may still lean on Microsoft DNS internally, while recursive resolution is forwarded through Unbound, BIND, dnsmasq, cloud filtering services, firewall appliances, or ISP resolvers. Branch offices may use a local resolver for caching. Developers may run Unbound in containers. Security teams may deploy it as part of DNS filtering, sinkholing, or lab infrastructure.
The vulnerability therefore belongs in the dependency map, not the OS map. If a Windows client points to a domain controller, and that domain controller forwards to a vulnerable Unbound resolver, the user-facing outage may still appear as failed browsing, failed authentication, broken package installs, or strange application timeouts. The vulnerable process might be two hops away from the desktop, but the desktop gets the blame.
That is especially true in environments that have treated DNS as plumbing rather than as a tier-one service. Redundant resolvers, health checks, service isolation, and rate limiting all matter. A patched resolver is the primary fix, but a resilient DNS architecture can determine whether a single crashing daemon becomes a brief alert or a company-wide incident.
The good news is that many Unbound deployments are not meant to be open resolvers. A properly configured resolver should answer only trusted clients. Access-control lists, firewall policy, interface binding, and segmentation can sharply reduce the population of systems able to hit the bug. In that sense, old-fashioned hygiene still matters.
The bad news is that “trusted client” can be a broad category. If every endpoint on a campus network can query the resolver, then every compromised endpoint can become an exploit source. If VPN clients are allowed to use internal DNS, then a stolen VPN credential may be enough. If a resolver is accidentally exposed to the public internet, the risk escalates from local nuisance to internet-scale target.
This is why denial-of-service bugs in DNS deserve a slightly paranoid reading. The attack does not have to be sophisticated if the affected service is reachable and restartable. A loop of crash, restart, crash can be enough to degrade an organization’s ability to function.
But the score cannot know whether the resolver sits behind three layers of filtering or answers half your enterprise. It cannot know whether you have redundant resolvers on separate software stacks or a single recursive service that everything quietly depends on. It cannot know whether your monitoring detects resolver crashes in seconds or whether the first alert is a flood of help-desk tickets.
In practice, this vulnerability should be prioritized according to exposure and dependency. Publicly reachable recursive resolvers should be patched or isolated immediately. Internal resolvers that serve critical business networks should be patched quickly and monitored for abnormal crash behavior. Lab systems and single-user resolvers still deserve updates, but their blast radius is smaller.
The deeper lesson is that DNS inventory should be treated as security inventory. If your vulnerability scanner tells you about operating systems but not resolver roles, it is missing the part of the system that users experience first. Name resolution is not just another daemon; it is the first domino in most application paths.
That changes the patch calculus. If this were a single corner-case crash in a rarely used feature, some teams might be tempted to defer. But a cumulative security release for a DNS resolver deserves a maintenance window, not a bookmark. The service is critical enough that the operational question becomes how to upgrade safely, not whether the update is interesting.
For many environments, the hardest part will not be compiling Unbound or installing a package. It will be finding every place Unbound exists. Appliances, containers, security gateways, BSD firewalls, recursive resolver VMs, and developer-managed systems often live outside the cleanest asset-management databases.
This is where security teams should work backward from DNS traffic. Resolver logs, DHCP options, endpoint network settings, firewall flows, and domain-controller forwarder settings can reveal which systems are actually resolving names. The vulnerable daemon may be easier to find by observing who receives DNS queries than by trusting a CMDB to be complete.
That is useful, but it also creates a framing problem. A Microsoft-hosted advisory page does not necessarily mean a Microsoft product is vulnerable. For this CVE, the affected product is Unbound from NLnet Labs. The remediation path is through Unbound 1.25.1 or downstream vendor packages, not Windows Update.
Still, Microsoft-centric teams should pay attention precisely because the dependency may sit under Microsoft workloads. Active Directory, Entra-connected apps, Windows Update for Business, Intune, Defender for Endpoint, RDP gateways, and enterprise SaaS access all assume DNS is available. If a third-party resolver in the path falls over, the Microsoft stack can look broken from the user’s chair.
That is the modern enterprise reality. Vendor boundaries rarely match incident boundaries. A bug in a resolver maintained by one organization, packaged by another, deployed on a Linux host, and used by Windows clients can become a Microsoft help-desk problem by 9:05 a.m.
Administrators should first identify Unbound versions and package provenance. Upstream versions 1.14.0 through 1.25.0 are in scope unless a vendor has backported the fix. Unbound 1.25.1 contains the upstream correction. Distribution packages should be checked against vendor security notices, not judged only by version strings.
Next, teams should review who can query each resolver. A recursive resolver should not be open to the world unless it is intentionally operated as a public service with appropriate protections. Internal resolvers should be reachable only from networks that need them. Segmentation and firewall policy can reduce the number of systems capable of triggering the flaw.
Finally, monitoring should treat resolver crashes as security-relevant events. A single crash may be a bug. Repeated crashes following unusual EDNS-heavy traffic should trigger investigation. DNS logs, service-manager restarts, core dumps, and network captures can help distinguish ordinary instability from exploit attempts.
The Bug Is in the Resolver, but the Blast Radius Is in the Network
CVE-2026-42944 sits in an uncomfortable category: a vulnerability that may not hand an attacker the keys to the kingdom, but can still knock the kingdom’s directory service out of reach. The affected component is Unbound, NLnet Labs’ widely used validating, recursive, caching DNS resolver. In plain terms, it is the software many networks rely on to turn names into addresses quickly, locally, and with DNSSEC validation when configured.The specific failure involves EDNS, the extension mechanism that lets DNS carry additional options beyond the protocol’s older limits. The vulnerable path appears when Unbound encodes a reply packet after receiving multiple instances of certain EDNS options: NSID, DNS Cookie, and EDNS Padding. The vendor description points to a size-calculation flaw where the EDNS field length can be truncated, after which the encoder writes more data than the allocated heap space can hold.
That is the kind of bug that sounds esoteric until you remember where DNS lives. It is not a decorative service. It is the thing that makes authentication endpoints, package repositories, SaaS applications, VPN gateways, telemetry endpoints, update servers, and internal line-of-business applications reachable by name. A DNS resolver crash can look to users like “the internet is down,” even when every router, firewall, and uplink is technically still alive.
Microsoft’s listing matters because many defenders consume MSRC data as part of a broader vulnerability-management workflow, not because Microsoft owns the affected code. The MSRC entry’s availability language is severe: total loss of availability, sustained while the attack continues or persistent until the condition is cleared. That tracks with the practical risk here. If an attacker can send the right kind of DNS query to a vulnerable resolver, they may be able to repeatedly crash it.
EDNS Was Built to Modernize DNS, and Modernity Brought Attack Surface
DNS began life in a smaller internet, with smaller assumptions. EDNS exists because the original protocol needed room for bigger answers, DNSSEC, client hints, cookies, padding, and other features bolted onto a system that is older than most modern operating systems. That history is not a criticism; it is one of the reasons DNS survived. But every extension mechanism becomes a parser, and every parser becomes a place where malformed input tests the optimism of implementers.NSID, or Name Server Identifier, lets a DNS server identify itself in responses, which can help operators debug anycast and distributed DNS deployments. DNS Cookies are intended to make certain spoofing and amplification attacks harder by adding lightweight request-response state. EDNS Padding is a privacy feature, used to obscure message sizes and make traffic analysis harder, particularly in encrypted DNS contexts.
Individually, none of those options is exotic. The problem is what happens when an attacker supplies multiple instances of them and the resolver’s reply-building logic fails to account correctly for the combined size. The advisory’s language is important: this is not described as an attacker writing arbitrary bytes of their choosing into memory. It is described as an overflow write of Unbound-controlled data that eventually causes a crash.
That distinction matters, but it should not be over-relied upon. Security history is full of bugs that began life as “just a crash” before researchers found sharper edges. For now, the responsible operational stance is to treat CVE-2026-42944 as a denial-of-service vulnerability with a clear network trigger and a patch available, not as a proven remote-code-execution emergency.
The Default Setting Is the Trap Door Administrators Might Miss
The most operationally awkward detail is that exploitation depends on relevant options being enabled:nsid, answer-cookie, and pad-responses. On paper, that sounds like a narrowing condition. In practice, one of those settings, response padding, is described as enabled by default in the affected advisory text, which means some operators may be exposed without remembering that they ever made a deliberate choice.This is how infrastructure bugs become weekend incidents. Nobody on the team thinks, “We run an EDNS option laboratory.” They think, “We run a DNS resolver.” The vulnerable behavior hides behind features that are either useful, privacy-preserving, or easy to inherit through distribution defaults.
Unbound’s footprint also cuts across the neat boundaries Windows admins often use to triage risk. A Windows-heavy organization may still run Unbound on Linux appliances, BSD firewalls, recursive resolver VMs, containers, campus network services, or bundled security products. Home lab users and small offices may run it behind Pi-hole. Hosting providers may expose recursive or forwarding resolvers to customer networks. The affected code is not Windows code, but the outage will still land on Windows desktops if those desktops depend on the resolver.
That is why the correct inventory question is not “Do we have this CVE on Windows?” It is “Which DNS resolvers do our Windows clients, servers, VPN users, domain controllers, and management tools actually rely on?” In many environments, the answer is messier than the diagram.
Availability Bugs Deserve More Respect Than They Usually Get
The industry still tends to rank vulnerabilities by the drama of remote code execution. That instinct is understandable. RCE turns a vulnerable service into an attacker’s beachhead, and beachheads become breaches. But availability vulnerabilities in network infrastructure can be just as operationally decisive, especially when they affect name resolution.A resolver that repeatedly crashes under crafted traffic creates a strange kind of outage. The network may not be saturated. The firewall may show no obvious volumetric attack. The authoritative DNS servers may be healthy. Yet users cannot reach anything by name because the local recursive layer is falling over faster than service managers can restart it.
That is the danger embedded in the MSRC-style “total loss of availability” phrasing. The attacker does not need to corrupt business data or steal credentials to create serious impact. If users cannot resolve identity-provider names, software-update names, endpoint-management names, or internal service names, the result is business interruption by dependency collapse.
The practical severity also depends on exposure. A public recursive resolver that accepts queries from the internet faces a different risk profile than an internal resolver reachable only from a locked-down subnet. But internal does not mean safe. Malware on a workstation, a compromised IoT device, a guest VLAN escape, or an abused VPN account may provide enough query access to turn the resolver against itself.
The Patch Says as Much About the Bug as the Advisory Does
Unbound 1.25.1 fixes CVE-2026-42944 by de-duplicating EDNS options and preventing truncation in the EDNS field size calculation. That is a concise fix description, but it tells us the shape of the vulnerability. The resolver was not simply failing to reject a giant packet. It was mishandling the relationship between repeated logical options and the size of the encoded reply structure.De-duplication is a defensive move that says, in effect, “Even if the request contains repeated instances of these options, the response encoder should not carry that multiplicity forward in a dangerous way.” The size-calculation fix addresses the arithmetic failure that let the allocation and the write disagree. Either one of those fixes might reduce risk; together they close both the malformed-input path and the memory-accounting mistake.
For administrators, the upgrade target is straightforward: move to Unbound 1.25.1 or a distribution package that backports the relevant patch. The latter point matters because enterprise Linux and appliance vendors often keep the old upstream version number while applying security fixes downstream. A system reporting an older Unbound version is not automatically vulnerable if the distribution has backported the patch, but it should be verified through vendor changelogs, package metadata, or security advisories rather than assumed.
There is also a configuration-based mitigation logic here, though it is inferior to patching. If the relevant features are disabled, the vulnerable path may not be reachable. But disabling DNS Cookies or padding can carry security or privacy tradeoffs, and configuration drift is a poor long-term substitute for corrected code. The safest durable answer is patched software plus sensible network exposure controls.
Windows Shops Should Look Beyond Microsoft DNS
The WindowsForum audience will naturally ask whether this affects Microsoft DNS Server. Based on the available advisory language, CVE-2026-42944 is an Unbound vulnerability, not a Windows DNS Server vulnerability. That said, Windows shops should not dismiss it as “Linux people’s problem.”Modern Windows environments are hybrid by default. Active Directory may still lean on Microsoft DNS internally, while recursive resolution is forwarded through Unbound, BIND, dnsmasq, cloud filtering services, firewall appliances, or ISP resolvers. Branch offices may use a local resolver for caching. Developers may run Unbound in containers. Security teams may deploy it as part of DNS filtering, sinkholing, or lab infrastructure.
The vulnerability therefore belongs in the dependency map, not the OS map. If a Windows client points to a domain controller, and that domain controller forwards to a vulnerable Unbound resolver, the user-facing outage may still appear as failed browsing, failed authentication, broken package installs, or strange application timeouts. The vulnerable process might be two hops away from the desktop, but the desktop gets the blame.
That is especially true in environments that have treated DNS as plumbing rather than as a tier-one service. Redundant resolvers, health checks, service isolation, and rate limiting all matter. A patched resolver is the primary fix, but a resilient DNS architecture can determine whether a single crashing daemon becomes a brief alert or a company-wide incident.
The Exploit Prerequisite Is Simple Enough to Be Uncomfortable
The attacker needs the ability to query the vulnerable Unbound resolver and attach multiple relevant EDNS options to the query. That is a cleaner prerequisite than defenders would like. It does not require local shell access, administrator credentials, or user interaction. It requires network reachability to the resolver and crafted DNS traffic.The good news is that many Unbound deployments are not meant to be open resolvers. A properly configured resolver should answer only trusted clients. Access-control lists, firewall policy, interface binding, and segmentation can sharply reduce the population of systems able to hit the bug. In that sense, old-fashioned hygiene still matters.
The bad news is that “trusted client” can be a broad category. If every endpoint on a campus network can query the resolver, then every compromised endpoint can become an exploit source. If VPN clients are allowed to use internal DNS, then a stolen VPN credential may be enough. If a resolver is accidentally exposed to the public internet, the risk escalates from local nuisance to internet-scale target.
This is why denial-of-service bugs in DNS deserve a slightly paranoid reading. The attack does not have to be sophisticated if the affected service is reachable and restartable. A loop of crash, restart, crash can be enough to degrade an organization’s ability to function.
The CVSS Number Is Less Useful Than the Service Map
CVE scoring gives security teams a shared language, but it can flatten the parts of risk that matter most. CVE-2026-42944 is high severity because it is network-reachable, does not require authentication in the usual sense if the resolver accepts the query, and can cause high availability impact. That is useful as a prioritization signal.But the score cannot know whether the resolver sits behind three layers of filtering or answers half your enterprise. It cannot know whether you have redundant resolvers on separate software stacks or a single recursive service that everything quietly depends on. It cannot know whether your monitoring detects resolver crashes in seconds or whether the first alert is a flood of help-desk tickets.
In practice, this vulnerability should be prioritized according to exposure and dependency. Publicly reachable recursive resolvers should be patched or isolated immediately. Internal resolvers that serve critical business networks should be patched quickly and monitored for abnormal crash behavior. Lab systems and single-user resolvers still deserve updates, but their blast radius is smaller.
The deeper lesson is that DNS inventory should be treated as security inventory. If your vulnerability scanner tells you about operating systems but not resolver roles, it is missing the part of the system that users experience first. Name resolution is not just another daemon; it is the first domino in most application paths.
The 1.25.1 Release Is a Reminder to Read the Whole Advisory, Not Just the One CVE
Unbound 1.25.1 was not a one-CVE release. NLnet Labs bundled fixes for multiple security issues, including other denial-of-service and memory-safety problems. CVE-2026-42944 may be the item that caught Microsoft’s feed or a particular scanner’s attention, but administrators should treat the upgrade as a broader resolver hardening event.That changes the patch calculus. If this were a single corner-case crash in a rarely used feature, some teams might be tempted to defer. But a cumulative security release for a DNS resolver deserves a maintenance window, not a bookmark. The service is critical enough that the operational question becomes how to upgrade safely, not whether the update is interesting.
For many environments, the hardest part will not be compiling Unbound or installing a package. It will be finding every place Unbound exists. Appliances, containers, security gateways, BSD firewalls, recursive resolver VMs, and developer-managed systems often live outside the cleanest asset-management databases.
This is where security teams should work backward from DNS traffic. Resolver logs, DHCP options, endpoint network settings, firewall flows, and domain-controller forwarder settings can reveal which systems are actually resolving names. The vulnerable daemon may be easier to find by observing who receives DNS queries than by trusting a CMDB to be complete.
Microsoft’s Role Here Is Signal Amplification, Not Ownership
The presence of CVE-2026-42944 in Microsoft’s Security Update Guide can confuse readers because it appears beside Windows, Edge, Office, Azure, and other Microsoft ecosystem vulnerabilities. But MSRC increasingly functions as part of a larger vulnerability-information pipeline, and organizations that live in Microsoft tooling often consume third-party CVE awareness through Microsoft surfaces.That is useful, but it also creates a framing problem. A Microsoft-hosted advisory page does not necessarily mean a Microsoft product is vulnerable. For this CVE, the affected product is Unbound from NLnet Labs. The remediation path is through Unbound 1.25.1 or downstream vendor packages, not Windows Update.
Still, Microsoft-centric teams should pay attention precisely because the dependency may sit under Microsoft workloads. Active Directory, Entra-connected apps, Windows Update for Business, Intune, Defender for Endpoint, RDP gateways, and enterprise SaaS access all assume DNS is available. If a third-party resolver in the path falls over, the Microsoft stack can look broken from the user’s chair.
That is the modern enterprise reality. Vendor boundaries rarely match incident boundaries. A bug in a resolver maintained by one organization, packaged by another, deployed on a Linux host, and used by Windows clients can become a Microsoft help-desk problem by 9:05 a.m.
The Practical Move Is to Patch, Restrict, and Watch the Resolver
The response to CVE-2026-42944 should be disciplined rather than theatrical. There is no need to pretend every affected resolver is moments away from compromise. There is also no excuse to leave a network-reachable DNS crash bug unpatched when a fixed release exists.Administrators should first identify Unbound versions and package provenance. Upstream versions 1.14.0 through 1.25.0 are in scope unless a vendor has backported the fix. Unbound 1.25.1 contains the upstream correction. Distribution packages should be checked against vendor security notices, not judged only by version strings.
Next, teams should review who can query each resolver. A recursive resolver should not be open to the world unless it is intentionally operated as a public service with appropriate protections. Internal resolvers should be reachable only from networks that need them. Segmentation and firewall policy can reduce the number of systems capable of triggering the flaw.
Finally, monitoring should treat resolver crashes as security-relevant events. A single crash may be a bug. Repeated crashes following unusual EDNS-heavy traffic should trigger investigation. DNS logs, service-manager restarts, core dumps, and network captures can help distinguish ordinary instability from exploit attempts.
The Resolver Checklist This CVE Forces Onto the Desk
The immediate response is short, but it cuts across operations, security, and architecture. CVE-2026-42944 is best handled as both a patching task and a dependency audit.- Upgrade Unbound to 1.25.1 or install a downstream vendor package that explicitly includes the CVE-2026-42944 fix.
- Verify whether any resolver still running an older version has received a backported patch before marking it safe.
- Restrict recursive DNS access so only intended client networks can query Unbound.
- Review exposure from VPN clients, guest networks, lab networks, containers, and appliances that may not be represented accurately in asset inventories.
- Monitor Unbound restarts, crashes, and anomalous DNS queries containing repeated EDNS options.
- Treat DNS resolver redundancy as a security control, not merely an uptime luxury.
References
- Primary source: MSRC
Published: 2026-05-23T01:40:36-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: sentinelone.com
CVE-2026-42945: NGINX Buffer Overflow Vulnerability
CVE-2026-42945 is a buffer overflow vulnerability in NGINX. Learn about its impact, affected versions, and mitigation methods to secure your systems.www.sentinelone.com
- Related coverage: threats.kaspersky.com
Kaspersky Threats — KLA90953
threats.kaspersky.com
