CVE-2026-50495 is a Windows DNS Client tampering vulnerability that allows a locally authenticated attacker to alter protected behavior through improper access control. Microsoft fixed the flaw in its July 14, 2026 security updates for supported Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025 systems.
Detailed in Microsoft’s Security Update Guide and subsequently published by the National Vulnerability Database, the vulnerability carries a CVSS 3.1 base score of 6.1. Microsoft classifies it as Important, while the numerical score falls within the medium-severity range.
The distinction matters. CVE-2026-50495 is not a drive-by DNS attack that an unauthenticated adversary can launch directly across the internet. Exploitation requires an attacker to have local access and low-level privileges on the affected Windows machine, but it does not require user interaction once those conditions are met.
Microsoft describes CVE-2026-50495 in unusually concise terms: improper access control in Microsoft Windows DNS allows an authorized attacker to perform tampering locally. The associated weakness is CWE-284, the broad category used when software fails to enforce intended restrictions on access to a resource or operation.
The CVSS vector is
That profile makes tampering the central risk. An attacker is not primarily using the vulnerability to read protected information or immediately execute code remotely. The concern is that a user or process already present on the machine could manipulate DNS Client-related state or behavior that should remain protected from that privilege level.
Microsoft has not publicly documented the exact resource, configuration object, registry location, service interface, or validation path involved. It has also not explained what DNS information can be altered or whether the modification persists across a reboot. Administrators should therefore avoid assuming that the flaw is limited to a familiar setting such as the configured resolver address or local DNS cache.
The absence of those details is deliberate vulnerability-disclosure restraint, not evidence that the issue is theoretical. Microsoft is the CVE Numbering Authority for the record, identifies the affected builds, assigns CWE-284, and has shipped corrected Windows components. The NVD currently marks the record as awaiting its own enrichment, meaning its displayed severity data comes from Microsoft rather than an independent NIST assessment.
That prerequisite still describes several realistic enterprise conditions. An adversary may obtain a standard user session through stolen credentials, malicious software, an exposed remote-access service, or exploitation of another vulnerability. Shared workstations, jump hosts, development machines, virtual desktop infrastructure, and servers allowing interactive logons warrant particular attention because low-privilege access may be available to more people or processes.
This is why local vulnerabilities are frequently useful in an attack chain. A phishing attachment or browser exploit might establish initial access, after which a flaw such as CVE-2026-50495 could weaken DNS-related controls or interfere with name resolution. The available advisory does not establish a specific chain, but the high integrity rating makes post-compromise manipulation the practical scenario administrators should consider.
DNS changes can have consequences beyond a failed lookup. Windows applications routinely depend on name resolution to reach identity services, software repositories, management platforms, web applications, file services, and security infrastructure. If an attacker can redirect, suppress, or otherwise alter that process, protections at higher layers may become more important.
TLS validation and application-level authentication can prevent some DNS manipulation from becoming a complete compromise. They do not make malicious name resolution harmless: connections can still be redirected, interrupted, delayed, or sent toward infrastructure designed to capture poorly protected protocols and legacy authentication attempts.
Microsoft has not claimed that CVE-2026-50495 defeats DNSSEC, encrypted DNS, TLS, Windows Zero Trust DNS, or certificate validation. Those outcomes should not be inferred from the generic “DNS Client Tampering Vulnerability” title.
Administrators should verify the installed cumulative update or operating-system build rather than checking only that Windows Update ran recently. A device can report successful update activity while still awaiting a restart, holding a failed cumulative update, or sitting behind an approval ring that has not released the July package.
Because Windows cumulative updates supersede earlier packages, installing a later applicable cumulative update should also include the fix. Organizations do not need to locate a standalone DNS Client hotfix, but they do need to ensure each machine has crossed the secure build boundary for its Windows release.
A high-confidence assessment means the vendor or credible research has established that the vulnerability exists and has identified enough of its cause or impact to support the record. It does not mean exploitation is widespread, easy from the internet, or certain to cause a full system compromise. Conversely, limited public technical detail does not make a vendor-confirmed issue less real.
For CVE-2026-50495, confidence is supported by Microsoft’s acknowledgement, the published affected-version ranges, the assigned access-control weakness, and corrected Windows builds. Public knowledge remains limited at the exploit-mechanics level: Microsoft has not supplied proof-of-concept code, detailed attack steps, or a description of the exact DNS Client object being modified.
As of July 15, 2026, the public material reviewed for the CVE does not identify active exploitation or public disclosure before the fix. That lowers the immediate emergency level compared with July’s actively exploited vulnerabilities, but it does not justify leaving systems unpatched—especially machines where untrusted users can obtain interactive sessions.
Security teams can pair deployment with monitoring for unexplained resolver changes, unusual local DNS configuration activity, suspicious modifications to name-resolution policy, and processes attempting to alter network settings outside normal management workflows. Existing endpoint telemetry may help identify such behavior, although Microsoft has not published a CVE-specific event ID or indicator of compromise.
CVE-2026-50495 is not the most severe vulnerability in the unusually large July 2026 Patch Tuesday release, which BleepingComputer reports addressed hundreds of flaws and multiple zero-days. Its practical risk is narrower: an attacker must already hold a local foothold.
The fix nevertheless closes an access-control boundary around a Windows component that almost every networked application relies upon. For administrators, the actionable milestone is straightforward: move every affected endpoint and server to its July 14 corrected build or later, then investigate any machine where DNS behavior remains inconsistent after patching.
Detailed in Microsoft’s Security Update Guide and subsequently published by the National Vulnerability Database, the vulnerability carries a CVSS 3.1 base score of 6.1. Microsoft classifies it as Important, while the numerical score falls within the medium-severity range.
The distinction matters. CVE-2026-50495 is not a drive-by DNS attack that an unauthenticated adversary can launch directly across the internet. Exploitation requires an attacker to have local access and low-level privileges on the affected Windows machine, but it does not require user interaction once those conditions are met.
The CVSS Vector Points to Integrity Damage
Microsoft describes CVE-2026-50495 in unusually concise terms: improper access control in Microsoft Windows DNS allows an authorized attacker to perform tampering locally. The associated weakness is CWE-284, the broad category used when software fails to enforce intended restrictions on access to a resource or operation.The CVSS vector is
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L. Broken down, it says exploitation requires local access and low privileges, has low attack complexity, and requires no action from another user. A successful attack is expected to have a high impact on integrity and a low impact on availability, with no direct confidentiality impact reflected in the score.That profile makes tampering the central risk. An attacker is not primarily using the vulnerability to read protected information or immediately execute code remotely. The concern is that a user or process already present on the machine could manipulate DNS Client-related state or behavior that should remain protected from that privilege level.
Microsoft has not publicly documented the exact resource, configuration object, registry location, service interface, or validation path involved. It has also not explained what DNS information can be altered or whether the modification persists across a reboot. Administrators should therefore avoid assuming that the flaw is limited to a familiar setting such as the configured resolver address or local DNS cache.
The absence of those details is deliberate vulnerability-disclosure restraint, not evidence that the issue is theoretical. Microsoft is the CVE Numbering Authority for the record, identifies the affected builds, assigns CWE-284, and has shipped corrected Windows components. The NVD currently marks the record as awaiting its own enrichment, meaning its displayed severity data comes from Microsoft rather than an independent NIST assessment.
Local Access Keeps the Door Narrow, Not Closed
TheAV:L and PR:L metrics sharply reduce the likelihood of CVE-2026-50495 being the first step in an intrusion. An attacker needs to be able to execute actions locally under an authorized, low-privilege account before attempting the tampering operation.That prerequisite still describes several realistic enterprise conditions. An adversary may obtain a standard user session through stolen credentials, malicious software, an exposed remote-access service, or exploitation of another vulnerability. Shared workstations, jump hosts, development machines, virtual desktop infrastructure, and servers allowing interactive logons warrant particular attention because low-privilege access may be available to more people or processes.
This is why local vulnerabilities are frequently useful in an attack chain. A phishing attachment or browser exploit might establish initial access, after which a flaw such as CVE-2026-50495 could weaken DNS-related controls or interfere with name resolution. The available advisory does not establish a specific chain, but the high integrity rating makes post-compromise manipulation the practical scenario administrators should consider.
DNS changes can have consequences beyond a failed lookup. Windows applications routinely depend on name resolution to reach identity services, software repositories, management platforms, web applications, file services, and security infrastructure. If an attacker can redirect, suppress, or otherwise alter that process, protections at higher layers may become more important.
TLS validation and application-level authentication can prevent some DNS manipulation from becoming a complete compromise. They do not make malicious name resolution harmless: connections can still be redirected, interrupted, delayed, or sent toward infrastructure designed to capture poorly protected protocols and legacy authentication attempts.
Microsoft has not claimed that CVE-2026-50495 defeats DNSSEC, encrypted DNS, TLS, Windows Zero Trust DNS, or certificate validation. Those outcomes should not be inferred from the generic “DNS Client Tampering Vulnerability” title.
July’s Builds Define the Patch Boundary
The CVE record identifies specific Windows build thresholds. Systems below the corresponding corrected build remain in the affected range:- Windows 10 Version 1809 and Windows Server 2019 are affected before build 17763.9020.
- Windows 10 Version 21H2 is affected before build 19044.7548.
- Windows 10 Version 22H2 is affected before build 19045.7548.
- Windows Server 2022 is affected before build 20348.5386.
- Windows 11 Version 24H2 is affected before build 26100.8875.
- Windows 11 Version 25H2 is affected before build 26200.8875.
- Windows 11 Version 26H1 is affected before build 28000.2269.
- Windows Server 2025 is affected before build 26100.33158.
Administrators should verify the installed cumulative update or operating-system build rather than checking only that Windows Update ran recently. A device can report successful update activity while still awaiting a restart, holding a failed cumulative update, or sitting behind an approval ring that has not released the July package.
winver provides a quick manual build check on a workstation. At scale, Microsoft Intune, Configuration Manager, Windows Update for Business reports, PowerShell inventory, or an endpoint-management platform should be used to compare deployed builds with the corrected thresholds.Because Windows cumulative updates supersede earlier packages, installing a later applicable cumulative update should also include the fix. Organizations do not need to locate a standalone DNS Client hotfix, but they do need to ensure each machine has crossed the secure build boundary for its Windows release.
The Confidence Metric Is Not a Severity Score
The text accompanying Microsoft’s record discusses confidence in a vulnerability’s existence and in the available technical information. That metric should not be confused with CVSS, exploitability, or patch priority.A high-confidence assessment means the vendor or credible research has established that the vulnerability exists and has identified enough of its cause or impact to support the record. It does not mean exploitation is widespread, easy from the internet, or certain to cause a full system compromise. Conversely, limited public technical detail does not make a vendor-confirmed issue less real.
For CVE-2026-50495, confidence is supported by Microsoft’s acknowledgement, the published affected-version ranges, the assigned access-control weakness, and corrected Windows builds. Public knowledge remains limited at the exploit-mechanics level: Microsoft has not supplied proof-of-concept code, detailed attack steps, or a description of the exact DNS Client object being modified.
As of July 15, 2026, the public material reviewed for the CVE does not identify active exploitation or public disclosure before the fix. That lowers the immediate emergency level compared with July’s actively exploited vulnerabilities, but it does not justify leaving systems unpatched—especially machines where untrusted users can obtain interactive sessions.
Patch First, Investigate Unexpected DNS Changes Second
There is no vendor-published workaround that offers the same protection as installing the July cumulative updates. Disabling the Windows DNS Client service would create broad compatibility and connectivity problems and should not be treated as a routine mitigation based solely on the limited CVE description.Security teams can pair deployment with monitoring for unexplained resolver changes, unusual local DNS configuration activity, suspicious modifications to name-resolution policy, and processes attempting to alter network settings outside normal management workflows. Existing endpoint telemetry may help identify such behavior, although Microsoft has not published a CVE-specific event ID or indicator of compromise.
CVE-2026-50495 is not the most severe vulnerability in the unusually large July 2026 Patch Tuesday release, which BleepingComputer reports addressed hundreds of flaws and multiple zero-days. Its practical risk is narrower: an attacker must already hold a local foothold.
The fix nevertheless closes an access-control boundary around a Windows component that almost every networked application relies upon. For administrators, the actionable milestone is straightforward: move every affected endpoint and server to its July 14 corrected build or later, then investigate any machine where DNS behavior remains inconsistent after patching.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
