CVE-2026-49174

What it actually does

This vulnerability is a local authentication-bypass/tampering flaw in Microsoft Windows DNS. A locally authenticated attacker with low privileges can access a DNS-related critical function that should require stronger authorization and modify DNS data or DNS service configuration. The primary security impact is high integrity loss: DNS answers, zones, records, or resolver/server behavior may be altered without proper administrative approval. Confidentiality impact is limited and availability impact is not the primary concern, but DNS manipulation can indirectly enable traffic redirection, credential interception, service impersonation, or follow-on compromise.

Why it matters to the business

If exploited on a Windows system running DNS services or managing DNS configuration, an attacker could redirect users, applications, or servers to attacker-controlled destinations, causing outages, fraud risk, credential exposure, or loss of trust in internal name resolution. The vulnerability currently has low EPSS, no known CISA KEV listing, no ransomware association, and no public exploit maturity reported, which lowers immediate internet-scale urgency; however, because DNS is a foundational service, successful local exploitation on domain infrastructure or critical servers can have outsized operational impact.

How an attack unfolds

An attacker first needs valid local access to an affected Windows host, such as through a compromised user account, malware running under a standard user context, or another vulnerability that provides local code execution. The attacker then invokes the vulnerable Windows DNS functionality that fails to enforce authentication or authorization checks for a critical operation. Instead of being blocked as a non-administrative user, the attacker tampers with DNS-related state, such as records, zones, forwarding behavior, or service configuration, depending on the exposed function and system role. After modifying DNS behavior, the attacker can redirect internal names to malicious infrastructure, intercept authentication flows, break access to legitimate services, or create durable name-resolution persistence. Because the attack is local and requires prior access, it is most likely to be used as a post-compromise technique rather than an initial entry vector.

How to fix it

Apply the relevant Microsoft security update or cumulative update for all affected Windows versions as soon as it is available through Windows Update, Microsoft Update Catalog, WSUS, Microsoft Configuration Manager, or other patch-management tooling. Prioritize Windows DNS servers, domain controllers that provide DNS, administrative workstations with DNS management tools, and servers where local user compromise would create material DNS risk. Because no exact fixed build numbers were provided, validate against Microsoft’s official security update guidance for the affected products: Windows 10 1809, 21H2, and 22H2; Windows 11 24H2, 25H2, and 26H1; Windows Server 2019, 2022, and 2025. As compensating controls, restrict local interactive and remote logon rights, remove unnecessary local users, enforce least privilege for DNS administration, monitor and control use of DNS management tools, enable DNS Server audit logging where applicable, and use application control to limit unauthorized execution of administrative utilities and scripts.

How to confirm the fix worked

Confirm that each affected host has received the applicable Microsoft security/cumulative update by checking Windows Update compliance, WSUS/management-console status, installed update history, or build/revision information. Verify that systems running the DNS Server role have been patched first. Review local group membership and DNS administration permissions to ensure standard users cannot modify DNS configuration. Where practical in a test environment, attempt DNS record or configuration changes from a non-administrative local account and confirm the operation is denied after patching. Validate that DNS Server audit logging, PowerShell logging, process creation logging, and configuration-change monitoring are enabled so future unauthorized changes are visible.

Typical attack path

1. Obtain valid local access to an affected Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, or Windows Server 2025 system.
2. Determine whether the host runs or manages Microsoft Windows DNS functionality.
3. Invoke the vulnerable DNS-related critical function from a low-privileged local context.
4. Modify DNS records, zones, forwarding behavior, or related configuration without the authorization normally required.
5. Redirect selected hostnames or services to attacker-controlled IP addresses or disrupt legitimate resolution.
6. Use the DNS tampering to support credential capture, service impersonation, lateral movement, persistence, or operational disruption.
7. Attempt to blend changes into normal administrative DNS activity or remove command/history artifacts.

How to detect it

Look for evidence of unauthorized DNS tampering after local access to affected Windows systems. Useful log sources include Microsoft-Windows-DNSServer/Audit, Microsoft-Windows-DNSServer/Analytical if enabled, Windows Security logs for process creation and logon activity, PowerShell Operational logs, Sysmon process/file/registry events, EDR command-line telemetry, DNS zone-transfer/change records, and configuration-management baselines. Investigate DNS changes made by standard users, newly created or modified records pointing to unusual IP addresses, changes to forwarders or conditional forwarders, changes outside approved maintenance windows, and DNS configuration edits followed by authentication failures, proxy redirects, certificate warnings, or traffic to unfamiliar infrastructure. Correlate suspicious DNS changes with local logons, privilege changes, execution of DNS management utilities, PowerShell DNS cmdlets, and modifications under Windows DNS file or registry locations. No public exploit-specific indicators are known from the provided data, so detection should focus on behavioral evidence of unauthorized DNS administration and DNS configuration drift.

• dnscmd.exe
• dnscmd /RecordAdd
• dnscmd /RecordDelete
• dnscmd /ZoneAdd
• dnscmd /ZoneDelete
• dnscmd /Config
• Add-DnsServerResourceRecord
• Set-DnsServerResourceRecord
• Remove-DnsServerResourceRecord
• Add-DnsServerPrimaryZone
• Set-DnsServerPrimaryZone
• Remove-DnsServerZone
• Set-DnsServerForwarder
• Add-DnsServerConditionalForwarderZone
• Remove-DnsServerConditionalForwarderZone
• Get-DnsServerZone
• Get-DnsServerResourceRecord
• %SystemRoot%\System32\dns\
• C:\Windows\System32\dns\
• HKLM\SYSTEM\CurrentControlSet\Services\DNS
• Microsoft-Windows-DNSServer/Audit
• Microsoft-Windows-DNSServer/Analytical

What your security team should do

• Inventory all affected Windows client and server versions, with special priority for systems running the DNS Server role or used to administer DNS.
• Patch Windows DNS servers, domain controllers providing DNS, and DNS administration hosts first, then complete rollout across remaining affected Windows endpoints.
• Treat this as a post-compromise privilege/authorization-abuse risk: review local access paths, remote logon rights, local administrator membership, and service accounts on DNS-relevant systems.
• Enable or verify DNS Server audit logging, PowerShell Script Block logging, PowerShell Module logging, Windows Security process creation auditing, and Sysmon process/file/registry telemetry where available.
• Monitor for unauthorized DNS record, zone, forwarding, and server-configuration changes, especially changes made by non-DNS-administrator accounts.
• Search for suspicious use of dnscmd.exe, PowerShell DnsServer cmdlets, WMI/CIM DNS management activity, and direct edits to DNS configuration files or registry locations.
• Review recent DNS changes for records that redirect high-value names such as authentication, update, proxy, email, file-sharing, identity, or administrative portals.
• Use change control to reconcile all recent DNS modifications against approved administrative tickets or maintenance windows.
• Because EPSS is currently low and there is no KEV listing or known public exploit maturity, prioritize based on DNS criticality and local-compromise exposure rather than emergency internet-facing exploitation risk.