CVE-2017-14491: dnsmasq heap buffer overflow via crafted DNS response

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 18 September 2026. Confidence: high.

critical priorityCVSS 9.8 with network reachability, no authentication or user interaction, and a very high EPSS score make this a top remediation priority despite no KEV listing.

What it is

dnsmasq before 2.78 contains a heap-based buffer overflow (CWE-787 out-of-bounds write) triggered by a crafted DNS response. Because dnsmasq is widely embedded in routers, Linux distributions, and enterprise appliances, a single malformed reply can crash the resolver or, in the worst case, allow code execution on the host.

Impact

A remote attacker can cause a denial of service by crashing dnsmasq, or potentially execute arbitrary code in the context of the dnsmasq process. Given the CVSS 3.1 vector (C:H/I:H/A:H), full loss of confidentiality, integrity, and availability is possible on affected systems.

Attack surface

Reachable over the network (AV:N) with no authentication (PR:N) and no user interaction (UI:N); the attacker only needs to deliver a crafted DNS response to a dnsmasq instance that is resolving or forwarding queries. Any host or device running a vulnerable dnsmasq build and accepting DNS traffic is exposed.

Exploitation

Not listed in CISA KEV, but EPSS is 0.84925 (99.7th percentile), indicating a high modeled likelihood of exploitation, and a public exploit reference exists (packetstormsecurity.com/files/144480). No ransomware groups are documented as using it in this record.

What to do

• Upgrade dnsmasq to version 2.78 or later; apply the vendor patch referenced in the dnsmasq changelog and git commit.
• Apply distribution and vendor advisories (Red Hat RHSA-2017:2836 through 2841, Ubuntu USN-3430-1/2/3, Debian DSA-3989, SUSE/openSUSE, Aruba, Huawei, NVIDIA, Synology) for all affected products.
• Restrict DNS traffic to trusted resolvers and block untrusted inbound DNS responses at network boundaries where feasible.
• Run dnsmasq with least privilege and, where supported, enable sandboxing or process isolation to limit the impact of a successful overflow.
• Inventory embedded and appliance deployments (routers, POS, industrial devices) that may not receive automatic updates and schedule manual patching.

Detection

• Monitor dnsmasq process crashes or restarts and correlate with DNS query/response logs for malformed or oversized responses.
• Use network IDS/IPS signatures for the known dnsmasq heap overflow exploit (e.g., Packet Storm reference) and anomalous DNS response patterns.
• Check installed dnsmasq versions across hosts and appliances against the fixed 2.78 baseline and flag any older builds.
• Watch for unexpected outbound connections or process behavior from dnsmasq that could indicate post-exploitation code execution.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.