NLnet Labs disclosed CVE-2026-33278 on May 20, 2026, as a critical Unbound DNSSEC validation flaw affecting versions 1.19.1 through 1.25.0, with denial of service and possible remote code execution fixed in Unbound 1.25.1. The short version is simple: if you operate a validating recursive resolver and it runs vulnerable Unbound, this is not a cosmetic patch. The longer version is more interesting, because the bug sits precisely where modern DNS security has become both essential and operationally fragile. DNSSEC was supposed to harden trust in name resolution; here, the validator itself becomes the dangerous code path.
DNS vulnerabilities rarely receive the same popular attention as browser zero-days or Exchange bugs, but defenders know the truth: a recursive resolver is infrastructure in the purest sense. When it fails, users do not experience “a DNS issue.” They experience the internet as broken.
CVE-2026-33278 matters because Unbound is not obscure lab software. It is a widely deployed validating, recursive, caching DNS resolver used in Linux distributions, BSD systems, network appliances, home labs, Pi-hole-style setups, hosting environments, and security-conscious enterprise networks. It also runs on Windows, which makes it relevant to WindowsForum readers even though the bug is not a Windows DNS Server vulnerability in the traditional Microsoft sense.
The affected component is the DNSSEC validator, the part of the resolver that decides whether signed DNS data can be trusted. That makes the vulnerability awkward. The security feature that exists to prevent spoofed or tampered DNS answers becomes, under carefully arranged conditions, the path toward crashing the resolver or possibly executing code.
The practical impact begins with availability. A resolver crash can cut off name resolution for the clients that depend on it, and in modern environments that often means authentication failures, broken application dependencies, failed updates, unreachable SaaS portals, monitoring noise, and cascading helpdesk pain. But the phrase “possible arbitrary code execution” raises the stakes beyond nuisance downtime. If exploitability is proven in the wild, the resolver becomes a remote attack surface that many administrators forgot to include in their mental model of tier-zero infrastructure.
CVE-2026-33278 is rooted in one of those edge cases: validation involving NSEC3, the DNSSEC mechanism commonly used to prove that a name does not exist without trivially exposing an entire zone. NSEC3 is useful, but it is computationally heavier than simpler denial-of-existence schemes. Resolver developers have spent years adding safeguards so that a malicious or pathological signed zone cannot force validators into unbounded work.
That is the backdrop to this bug. Unbound introduced computational budget handling for these validation paths in version 1.19.1. When validation work had to be suspended because an NSEC3 budget was exhausted, Unbound preserved response data across memory-region teardown by deep-copying internal structures. According to vulnerability descriptions, a struct-assignment mistake overwrote a destination pointer with a source pointer. When the original region was later freed, the resumed validator could dereference a dangling pointer.
That is classic use-after-free territory. In the least exciting case, it crashes. In the worst case, heap state, allocator behavior, process privileges, hardening settings, and attacker control align enough to transform memory corruption into code execution. The public language remains careful — “possible” remote code execution — and that caution is appropriate. But defenders should not confuse cautious wording with low priority.
Recursive resolvers exist to ask questions on behalf of clients. If a client, script, phishing page, mail scanner, web proxy, sandbox, monitoring system, or any other network participant causes the resolver to look up attacker-controlled names, the resolver may walk into the malicious validation path. The attacker’s “interaction” with the target is indirect, but recursive DNS is built around indirect interaction.
That distinction matters for risk scoring. Many organizations expose recursive resolvers only internally, then downgrade the danger because “it is not internet-facing.” But internal-only resolvers still resolve internet names. They still process hostile DNS responses from authoritative infrastructure outside the organization. The boundary is not the firewall interface; it is the resolver’s willingness to validate data from the global DNS hierarchy.
This is where DNS bugs are often underestimated. A vulnerable web server has a neat owner and a visible port. A vulnerable resolver may be tucked into a firewall, a container, a domain-services VM, a Linux package pulled in by another product, or a branch-office appliance that nobody has logged into since the last power event. The attack surface is not always visible in asset inventories because DNS is treated as plumbing, and plumbing is noticed only after the floor is wet.
That distinction is not pedantry. Windows Server DNS has had its own memorable crises, including the kind of remote code execution flaws that make domain administrators sit up straight. CVE-2026-33278 belongs to a different family: third-party resolver software, often deployed deliberately by administrators who want DNSSEC validation, privacy features, local caching, or separation from ISP and platform defaults.
Still, Windows shops should not skip the advisory merely because “Unbound” sounds like a Unix-world concern. Unbound can be deployed on Windows. It may also sit upstream or downstream of Windows clients, domain controllers, VPN users, developer workstations, and security tools. If Windows endpoints depend on a vulnerable resolver, the outage is still a Windows outage from the user’s perspective.
There is also a supply-chain angle. Enterprises often consume open-source infrastructure through packages, appliances, managed images, containers, security products, hosting panels, and network distributions. The administrator may never have downloaded Unbound from NLnet Labs, but the code may still be present in the recursive DNS path. The right question is not “Did we install Unbound manually?” It is “Where do we validate DNSSEC, and what resolver code is doing it?”
The trap is that DNS infrastructure often has a lower change velocity than the systems it serves. Administrators may be comfortable patching browsers weekly and Windows monthly, but recursive resolvers are sometimes treated like “set and forget” infrastructure. That instinct is understandable. DNS changes can be noisy, and a bad resolver rollout can break everything at once.
But this is exactly the class of bug where conservative operations should mean staged urgency, not delay. Test the updated resolver in a lab or secondary node, validate forwarding and DNSSEC behavior, confirm monitoring, then roll through redundant resolvers. If the environment has only one resolver, that is a separate architectural problem this advisory should force into the open.
The update also arrived as part of a broader Unbound security release, not a single-issue patch in isolation. That increases the argument for moving quickly. Even administrators who judge the RCE path as uncertain still face a high-impact denial-of-service condition in a critical component, alongside other fixes in the same maintenance window.
The severity language around this CVE emphasizes total loss of availability: an attacker may be able to fully deny access to resources in the impacted component, either while the attack continues or potentially in a condition that persists after the attack has stopped. In resolver terms, that means clients keep asking for names and the resolver stops being a reliable answerer.
For small offices and home labs, the symptom may look like the broadband connection died. For enterprises, it can look like a platform outage. Cloud services fail to resolve. Identity providers become unreachable. Package repositories disappear. Security agents cannot phone home. Remote workers blame VPN. Application teams blame the network. The root cause may be one process crashing under crafted DNSSEC validation.
This is why “only DoS” is the wrong frame. Availability bugs in foundational services are leverage bugs. They let an attacker convert a narrow parser or memory-management flaw into a broad operational incident.
But resolver operators should not build policy around the hope that exploitation is impractical. The vulnerability is network reachable through normal resolver behavior, requires no authentication, and lives in C code handling attacker-influenced protocol data. Those are the ingredients that keep exploit developers interested.
The likely first wave of exploitation, if it appears, would be crash-oriented. Denial of service is simpler to prove, easier to automate, and useful enough for nuisance actors, extortionists, and botnet operators targeting hosting or gaming-adjacent infrastructure. More sophisticated exploitation would require careful heap shaping and environment-specific work, but the presence of a crash primitive in a critical daemon is not something to leave exposed while waiting for proof-of-concept code to mature.
There is also a defender’s asymmetry. Attackers need to find one overlooked resolver. Administrators need to find all of them, including the forgotten ones in containers, appliances, and nonproduction networks that quietly serve real users.
Unbound is popular in precisely the places that can escape enterprise patch discipline: homegrown recursive resolvers, developer lab networks, branch office boxes, Kubernetes sidecars, Pi-hole companions, BSD firewalls, hosting control panels, and small appliances that bundle open-source components. Many of those deployments are stable for years, which is another way of saying they can remain vulnerable for years.
Package managers help, but only if someone runs them and only if the distribution has shipped the fix. Ubuntu, Debian, BSDs, appliance vendors, hosting platforms, and container maintainers each move on their own cadence. A version string may show 1.25.0 and be vulnerable, or it may show an older downstream version with a backported patch. Administrators need to check vendor advisories rather than relying solely on upstream version comparisons.
Windows-heavy organizations face a particular inventory blind spot. Their central tooling may know everything about Windows Update compliance and almost nothing about the Linux VM running recursive DNS for a lab, the pfSense or OPNsense box doing local resolution, or the container image a developer copied from a tutorial. The network does not care which asset class owns the resolver. It only cares whether name resolution works.
The fix, therefore, starts with discovery. Query the resolver fleet, identify Unbound instances, confirm package provenance, and determine whether DNSSEC validation is enabled. Then patch or replace. If the resolver is embedded in an appliance, pressure the vendor for a fixed build and apply compensating controls while waiting.
DNSSEC exists because DNS without validation is vulnerable to classes of spoofing and cache-poisoning attacks that the industry has spent decades trying to contain. Disabling validation trades one risk for another, and it does so silently. Users will not know that an integrity check disappeared. Applications will not know that signed DNS answers are no longer being verified.
A better mitigation is patching. If patching must wait, limit who can use the resolver, remove open-recursive exposure, ensure redundant resolvers are available, monitor for crashes, and consider temporarily forwarding through a trusted, patched resolver. These are operational bridges, not destinations.
This is also a reminder that DNSSEC validation should not be a boutique setting hidden in a single fragile node. If an organization depends on it, the resolver architecture should be redundant, observable, and routinely patched. If it does not depend on it, administrators should be honest about that too, rather than discovering the policy only during an incident.
Start by asking which systems answer recursive DNS for users, servers, VPN clients, labs, and appliances. Then determine whether any of them run Unbound in the affected range. If the answer is yes, prioritize the upgrade to 1.25.1 or a vendor-fixed package, with redundancy and rollback plans in place.
Monitoring deserves attention as well. Resolver crashes, service restarts, spikes in SERVFAIL responses, unusual queries into obscure signed zones, and repeated validation failures can all provide clues. None of those signals alone proves exploitation, but together they can shorten the time between “users say the internet is down” and “we know which daemon is falling over.”
Security teams should also update vulnerability management logic to include indirect DNS exposure. A resolver does not need to be open to the internet to process malicious authoritative responses from it. If internal clients can trigger lookups, the resolver can be pulled toward attacker-controlled zones.
The uncomfortable part is that the bug appeared in software many administrators chose because they wanted a more secure DNS posture. That does not make the choice wrong. It means secure infrastructure is still software, and software that parses hostile input at internet scale needs fast patch paths.
This vulnerability also shows why open-source infrastructure needs operational respect. Unbound’s maintainers shipped a fix, distributions began moving updates, and the public advisory gave defenders enough detail to act. The remaining risk is not lack of information. It is delay, inventory gaps, and the quiet assumption that DNS will keep working because it always has.
The Resolver Is the Soft Underbelly of a Hardened Network
DNS vulnerabilities rarely receive the same popular attention as browser zero-days or Exchange bugs, but defenders know the truth: a recursive resolver is infrastructure in the purest sense. When it fails, users do not experience “a DNS issue.” They experience the internet as broken.CVE-2026-33278 matters because Unbound is not obscure lab software. It is a widely deployed validating, recursive, caching DNS resolver used in Linux distributions, BSD systems, network appliances, home labs, Pi-hole-style setups, hosting environments, and security-conscious enterprise networks. It also runs on Windows, which makes it relevant to WindowsForum readers even though the bug is not a Windows DNS Server vulnerability in the traditional Microsoft sense.
The affected component is the DNSSEC validator, the part of the resolver that decides whether signed DNS data can be trusted. That makes the vulnerability awkward. The security feature that exists to prevent spoofed or tampered DNS answers becomes, under carefully arranged conditions, the path toward crashing the resolver or possibly executing code.
The practical impact begins with availability. A resolver crash can cut off name resolution for the clients that depend on it, and in modern environments that often means authentication failures, broken application dependencies, failed updates, unreachable SaaS portals, monitoring noise, and cascading helpdesk pain. But the phrase “possible arbitrary code execution” raises the stakes beyond nuisance downtime. If exploitability is proven in the wild, the resolver becomes a remote attack surface that many administrators forgot to include in their mental model of tier-zero infrastructure.
DNSSEC’s Expensive Guarantees Keep Creating Expensive Failure Modes
DNSSEC has always carried a tradeoff. It provides cryptographic assurance that DNS answers have not been tampered with, but it does so by adding validation logic, signatures, denial-of-existence proofs, trust anchors, algorithm choices, and edge cases that ordinary DNS never had to process.CVE-2026-33278 is rooted in one of those edge cases: validation involving NSEC3, the DNSSEC mechanism commonly used to prove that a name does not exist without trivially exposing an entire zone. NSEC3 is useful, but it is computationally heavier than simpler denial-of-existence schemes. Resolver developers have spent years adding safeguards so that a malicious or pathological signed zone cannot force validators into unbounded work.
That is the backdrop to this bug. Unbound introduced computational budget handling for these validation paths in version 1.19.1. When validation work had to be suspended because an NSEC3 budget was exhausted, Unbound preserved response data across memory-region teardown by deep-copying internal structures. According to vulnerability descriptions, a struct-assignment mistake overwrote a destination pointer with a source pointer. When the original region was later freed, the resumed validator could dereference a dangling pointer.
That is classic use-after-free territory. In the least exciting case, it crashes. In the worst case, heap state, allocator behavior, process privileges, hardening settings, and attacker control align enough to transform memory corruption into code execution. The public language remains careful — “possible” remote code execution — and that caution is appropriate. But defenders should not confuse cautious wording with low priority.
The Attack Does Not Need a Password, Only a Resolver That Believes the Internet
The most important operational detail is that the attacker does not need an account on the resolver. The scenario described publicly involves an adversary controlling a malicious DNSSEC-signed zone and causing a vulnerable Unbound instance to query it. That is not as effortless as firing a packet at an exposed service, but it is also not an exotic precondition.Recursive resolvers exist to ask questions on behalf of clients. If a client, script, phishing page, mail scanner, web proxy, sandbox, monitoring system, or any other network participant causes the resolver to look up attacker-controlled names, the resolver may walk into the malicious validation path. The attacker’s “interaction” with the target is indirect, but recursive DNS is built around indirect interaction.
That distinction matters for risk scoring. Many organizations expose recursive resolvers only internally, then downgrade the danger because “it is not internet-facing.” But internal-only resolvers still resolve internet names. They still process hostile DNS responses from authoritative infrastructure outside the organization. The boundary is not the firewall interface; it is the resolver’s willingness to validate data from the global DNS hierarchy.
This is where DNS bugs are often underestimated. A vulnerable web server has a neat owner and a visible port. A vulnerable resolver may be tucked into a firewall, a container, a domain-services VM, a Linux package pulled in by another product, or a branch-office appliance that nobody has logged into since the last power event. The attack surface is not always visible in asset inventories because DNS is treated as plumbing, and plumbing is noticed only after the floor is wet.
Microsoft’s Listing Is a Signal, Not a Windows DNS Panic
The appearance of CVE-2026-33278 in Microsoft’s security ecosystem may lead some readers to assume this is a Windows Server DNS vulnerability. It is not that, based on the public descriptions available at disclosure time. The affected software is NLnet Labs Unbound.That distinction is not pedantry. Windows Server DNS has had its own memorable crises, including the kind of remote code execution flaws that make domain administrators sit up straight. CVE-2026-33278 belongs to a different family: third-party resolver software, often deployed deliberately by administrators who want DNSSEC validation, privacy features, local caching, or separation from ISP and platform defaults.
Still, Windows shops should not skip the advisory merely because “Unbound” sounds like a Unix-world concern. Unbound can be deployed on Windows. It may also sit upstream or downstream of Windows clients, domain controllers, VPN users, developer workstations, and security tools. If Windows endpoints depend on a vulnerable resolver, the outage is still a Windows outage from the user’s perspective.
There is also a supply-chain angle. Enterprises often consume open-source infrastructure through packages, appliances, managed images, containers, security products, hosting panels, and network distributions. The administrator may never have downloaded Unbound from NLnet Labs, but the code may still be present in the recursive DNS path. The right question is not “Did we install Unbound manually?” It is “Where do we validate DNSSEC, and what resolver code is doing it?”
The Fix Is Boring, Which Is Exactly Why It Should Happen Fast
NLnet Labs fixed CVE-2026-33278 in Unbound 1.25.1. The upgrade guidance is therefore uncomplicated: move affected deployments from 1.19.1 through 1.25.0 to 1.25.1 or to a distribution package that has backported the fix.The trap is that DNS infrastructure often has a lower change velocity than the systems it serves. Administrators may be comfortable patching browsers weekly and Windows monthly, but recursive resolvers are sometimes treated like “set and forget” infrastructure. That instinct is understandable. DNS changes can be noisy, and a bad resolver rollout can break everything at once.
But this is exactly the class of bug where conservative operations should mean staged urgency, not delay. Test the updated resolver in a lab or secondary node, validate forwarding and DNSSEC behavior, confirm monitoring, then roll through redundant resolvers. If the environment has only one resolver, that is a separate architectural problem this advisory should force into the open.
The update also arrived as part of a broader Unbound security release, not a single-issue patch in isolation. That increases the argument for moving quickly. Even administrators who judge the RCE path as uncertain still face a high-impact denial-of-service condition in a critical component, alongside other fixes in the same maintenance window.
Availability Is Not the Lesser Security Outcome
Security teams have a habit of ranking confidentiality and code execution above availability. That hierarchy makes sense when comparing theoretical risk, but it breaks down when the vulnerable component is a resolver. A sustained DNS outage is not a minor inconvenience. It is a denial of access to almost everything users and services need.The severity language around this CVE emphasizes total loss of availability: an attacker may be able to fully deny access to resources in the impacted component, either while the attack continues or potentially in a condition that persists after the attack has stopped. In resolver terms, that means clients keep asking for names and the resolver stops being a reliable answerer.
For small offices and home labs, the symptom may look like the broadband connection died. For enterprises, it can look like a platform outage. Cloud services fail to resolve. Identity providers become unreachable. Package repositories disappear. Security agents cannot phone home. Remote workers blame VPN. Application teams blame the network. The root cause may be one process crashing under crafted DNSSEC validation.
This is why “only DoS” is the wrong frame. Availability bugs in foundational services are leverage bugs. They let an attacker convert a narrow parser or memory-management flaw into a broad operational incident.
Remote Code Execution Remains the Shadow Over the Advisory
The more dramatic possibility is arbitrary code execution. Public advisories describe it as possible, not as demonstrated in the wild. That distinction should remain visible. A use-after-free can be easy to crash and hard to weaponize, especially in modern builds with ASLR, heap hardening, sandboxing, privilege separation, and distribution-specific compiler protections.But resolver operators should not build policy around the hope that exploitation is impractical. The vulnerability is network reachable through normal resolver behavior, requires no authentication, and lives in C code handling attacker-influenced protocol data. Those are the ingredients that keep exploit developers interested.
The likely first wave of exploitation, if it appears, would be crash-oriented. Denial of service is simpler to prove, easier to automate, and useful enough for nuisance actors, extortionists, and botnet operators targeting hosting or gaming-adjacent infrastructure. More sophisticated exploitation would require careful heap shaping and environment-specific work, but the presence of a crash primitive in a critical daemon is not something to leave exposed while waiting for proof-of-concept code to mature.
There is also a defender’s asymmetry. Attackers need to find one overlooked resolver. Administrators need to find all of them, including the forgotten ones in containers, appliances, and nonproduction networks that quietly serve real users.
The Hidden Estate Is Where This Bug Will Linger
The most exposed organizations may not be the ones with the largest DNS teams. They may be the ones with the most informal DNS sprawl.Unbound is popular in precisely the places that can escape enterprise patch discipline: homegrown recursive resolvers, developer lab networks, branch office boxes, Kubernetes sidecars, Pi-hole companions, BSD firewalls, hosting control panels, and small appliances that bundle open-source components. Many of those deployments are stable for years, which is another way of saying they can remain vulnerable for years.
Package managers help, but only if someone runs them and only if the distribution has shipped the fix. Ubuntu, Debian, BSDs, appliance vendors, hosting platforms, and container maintainers each move on their own cadence. A version string may show 1.25.0 and be vulnerable, or it may show an older downstream version with a backported patch. Administrators need to check vendor advisories rather than relying solely on upstream version comparisons.
Windows-heavy organizations face a particular inventory blind spot. Their central tooling may know everything about Windows Update compliance and almost nothing about the Linux VM running recursive DNS for a lab, the pfSense or OPNsense box doing local resolution, or the container image a developer copied from a tutorial. The network does not care which asset class owns the resolver. It only cares whether name resolution works.
The fix, therefore, starts with discovery. Query the resolver fleet, identify Unbound instances, confirm package provenance, and determine whether DNSSEC validation is enabled. Then patch or replace. If the resolver is embedded in an appliance, pressure the vendor for a fixed build and apply compensating controls while waiting.
Disabling DNSSEC Is a Tempting but Bad Long-Term Answer
Some administrators will look at the vulnerable path and ask whether turning off DNSSEC validation is the quickest mitigation. In a narrow emergency, reducing exposure to a crashing validation path may be a reasonable temporary decision if no patch is available and the resolver is actively being attacked. But as a strategic response, it is unsatisfying.DNSSEC exists because DNS without validation is vulnerable to classes of spoofing and cache-poisoning attacks that the industry has spent decades trying to contain. Disabling validation trades one risk for another, and it does so silently. Users will not know that an integrity check disappeared. Applications will not know that signed DNS answers are no longer being verified.
A better mitigation is patching. If patching must wait, limit who can use the resolver, remove open-recursive exposure, ensure redundant resolvers are available, monitor for crashes, and consider temporarily forwarding through a trusted, patched resolver. These are operational bridges, not destinations.
This is also a reminder that DNSSEC validation should not be a boutique setting hidden in a single fragile node. If an organization depends on it, the resolver architecture should be redundant, observable, and routinely patched. If it does not depend on it, administrators should be honest about that too, rather than discovering the policy only during an incident.
The Patch Window Should Start With the Resolver Map
For IT teams, the immediate response should be practical rather than theatrical. This is not a reason to declare every DNS lookup suspicious. It is a reason to verify resolver software, patch quickly, and treat DNS as a first-class part of the security estate.Start by asking which systems answer recursive DNS for users, servers, VPN clients, labs, and appliances. Then determine whether any of them run Unbound in the affected range. If the answer is yes, prioritize the upgrade to 1.25.1 or a vendor-fixed package, with redundancy and rollback plans in place.
Monitoring deserves attention as well. Resolver crashes, service restarts, spikes in SERVFAIL responses, unusual queries into obscure signed zones, and repeated validation failures can all provide clues. None of those signals alone proves exploitation, but together they can shorten the time between “users say the internet is down” and “we know which daemon is falling over.”
Security teams should also update vulnerability management logic to include indirect DNS exposure. A resolver does not need to be open to the internet to process malicious authoritative responses from it. If internal clients can trigger lookups, the resolver can be pulled toward attacker-controlled zones.
The Lesson Is Written in a Dangling Pointer
CVE-2026-33278 is a small implementation bug with a large architectural message. DNS security has become complicated enough that validation code is now a premium target, and availability of the resolver is as important as the correctness of the answers it returns.The uncomfortable part is that the bug appeared in software many administrators chose because they wanted a more secure DNS posture. That does not make the choice wrong. It means secure infrastructure is still software, and software that parses hostile input at internet scale needs fast patch paths.
This vulnerability also shows why open-source infrastructure needs operational respect. Unbound’s maintainers shipped a fix, distributions began moving updates, and the public advisory gave defenders enough detail to act. The remaining risk is not lack of information. It is delay, inventory gaps, and the quiet assumption that DNS will keep working because it always has.
The Resolver Checklist That Actually Matters This Week
The operational story is narrow enough to act on and broad enough to justify urgency. The organizations that handle this well will be the ones that already know where their recursive resolvers live; the ones that struggle will be discovering them under pressure.- Unbound versions 1.19.1 through 1.25.0 should be treated as vulnerable unless a trusted vendor confirms a backported fix.
- Unbound 1.25.1 contains the upstream fix for CVE-2026-33278 and should be the target version for direct upstream deployments.
- Internal-only recursive resolvers still face risk because clients can cause them to query attacker-controlled signed zones on the public internet.
- A resolver crash can become a broad business outage because authentication, updates, SaaS access, monitoring, and application dependencies all rely on DNS.
- Disabling DNSSEC validation may reduce exposure in a short emergency, but patching and resilient resolver design are the durable answers.
- Windows environments should check non-Windows DNS infrastructure too, because Windows clients and servers often depend on resolvers running Linux, BSD, appliances, or containers.
References
- Primary source: MSRC
Published: 2026-05-23T01:39:45-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: securityonline.info
NLnet Labs Issues Urgent Security Release for Unbound Resolver
NLnet Labs patches a critical Unbound DNSSEC validation vulnerability allowing unauthenticated remote code execution. Update to 1.25.1.
securityonline.info
- Related coverage: dbugs.ptsecurity.com
CVE-2026-33278 — Unbound+1 | dbugs
Details on CVE-2026-33278: Unbound+1. Includes CVSS score, affected versions, and references.dbugs.ptsecurity.com
- Official source: microsoft.com
CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments | Microsoft Security Blog
A high-severity Linux vulnerability, “Copy Fail” (CVE-2026-31431), enables root privilege escalation across cloud environments and Kubernetes workloads. With a working exploit already in the wild, organizations should act quickly to detect, mitigate, and reduce risk.www.microsoft.com - Related coverage: sentinelone.com
CVE-2026-33826: Windows Active Directory RCE Vulnerability
CVE-2026-33826 is a remote code execution vulnerability in Windows Active Directory. Learn about its impact, affected versions, and mitigation methods.www.sentinelone.com
- Related coverage: cyber.gov.au
- Related coverage: threataft.com
Unbound 1.25.1: 11 CVEs Fixed, DNSSEC RCE (CVE-2026-33278) | ThreatAft
NLnet Labs Unbound 1.25.1 fixes 11 CVEs including DNSSEC RCE (CVE-2026-33278) and cache poisoning (CVE-2026-42960). Upgrade your resolver now.threataft.com - Related coverage: nsrc.org