dnsmasq CVE-2026 QA Verification Tool

Automated black-box tool for verifying 6 dnsmasq vulnerabilities (May 2026). Sends attack packets to a live DUT and reports PASS/FAIL — no source code access needed.

Quick Start

# Set DUT DNS to your laptop's WAN IP via GUI first, then:
sudo python3 dnsmasq_cve_verify.py --laptop <YOUR_WAN_IP> --dut <DUT_LAN_IP> --dut-pass <SSH_PASS>

# Example:
sudo python3 dnsmasq_cve_verify.py --laptop 10.0.0.211 --dut 192.168.1.1 --dut-pass '12345Asdf@'

CVEs Tested

How Each Test Works

CVE-2026-2291 (Critical — Heap Overflow in extract_name)

Root cause: union bigname declares char name[MAXDNAME] but escaped characters can expand a name to 2*MAXDNAME+1 bytes, causing heap overflow.

Test method: Sends DNS queries containing domain names with high-bit characters (0x80+) that get \DDD escaped internally (4 bytes per input byte). If dnsmasq crashes or stops responding, it's vulnerable.

Patched behavior: Rejects oversized names gracefully (FORMERR/REFUSED) or uses enlarged buffer.

CVE-2026-5172 (High — OOB Read in extract_addresses)

Root cause: Falsified rdlen field lets extract_name() advance pointer past record end. Remaining-bytes underflow produces a huge value → massive OOB read → crash.

Test method: Sends DNS responses with CNAME records where rdlen is smaller than the actual encoded name. If dnsmasq crashes, it's vulnerable.

Patched behavior: Validates that pointer stays within declared rdlen boundary after extract_name().

CVE-2026-4890 (High — DNSSEC NSEC Infinite Loop)

Root cause: NSEC type bitmap parsing advances by p[1] instead of p[1]+2 (missing window header size). With bitmap_length=0, pointer never advances → infinite loop.

Test method: Sends a crafted NSEC record with window=0, bitmap_length=0. If dnsmasq stops responding to ALL queries (hangs, not crashes), it's vulnerable. Exploitable BEFORE RRSIG validation.

Patched behavior: Advances by p[1]+2 and skips zero-length bitmaps.

CVE-2026-4891 (Moderate — RRSIG Heap OOB Read)

Root cause: rdlen in RRSIG not validated against minimum size (18 + signer name). Calculated signature length underflows negative → treated as huge → OOB read.

Test method: Sends RRSIG records with rdlen=10 (way below minimum 31+ bytes). Crash = vulnerable.

Patched behavior: Validates rdlen >= fixed_fields + signer_name_length before computing signature length.

CVE-2026-4892 (High — DHCPv6 CLID Local Root)

Root cause: DHCPv6 CLIDs (up to 65535 bytes) get hex-encoded via sprintf("%.2x") into daemon->packet (5131 bytes). 3000-byte CLID → 6000-byte hex string → overflow. Helper process runs as root.

Test method: Sends DHCPv6 SOLICIT with 3000-byte Client Identifier. Requires IPv6 adjacency and --dhcp-script configured. Helper crash = vulnerable.

Patched behavior: Truncates or validates CLID length before hex encoding.

Note: Some builds compile with -DNO_DHCP6 and are NOT affected by this CVE.

CVE-2026-4893 (Moderate — ECS Source Validation Bypass)

Root cause: process_reply() passes OPT record length (~23 bytes) instead of full packet length to check_source(). All bounds checks fail → function always returns 1 (valid).

Test method: Sends DNS queries with EDNS Client Subnet option containing spoofed source prefixes. If dnsmasq echoes ECS back without validation, it's vulnerable.

Patched behavior: Passes full packet length to check_source(), enabling proper bounds checks per RFC 7871 Section 9.2.

Remediation

Upgrade to dnsmasq 2.92rel2 (recommended)

• Source: https://thekelleys.org.uk/dnsmasq/dnsmasq-2.92rel2.tar.xz
• Upstream patches: https://thekelleys.org.uk/dnsmasq/CVE/

Automated Defect Verification Tool (dnsmasq_cve_verify.py)

The primary QA tool. Runs on the testing laptop, sends attack packets to the DUT, and reports clear PASS/FAIL for each CVE. No modification of the DUT is needed beyond read-only SSH access for state inspection.

Network Topology

┌─────────────────────────────────────────────────────────────────────┐
│                        Testing Laptop                                │
│                                                                      │
│   LAN interface                   WAN interface                      │
│   <LAPTOP_LAN_IP>                 <LAPTOP_WAN_IP>                   │
│        │                               │                            │
│        │                          ┌────┴──────────────┐             │
│        │                          │ Malicious DNS     │             │
│        │                          │ Server (port 53)  │             │
│        │                          └────┬──────────────┘             │
│        │                               │                            │
└────────┼───────────────────────────────┼────────────────────────────┘
         │ LAN subnet                    │ WAN subnet
         │                               │
┌────────┼───────────────────────────────┼────────────────────────────┐
│        │                               │                            │
│   LAN: <DUT_LAN_IP>              WAN: <DUT_WAN_IP>                  │
│   (LAN gateway)                   (WAN uplink)                      │
│                                                                      │
│              DUT (Linksys Router)                                    │
│              dnsmasq (any version < 2.92rel2)                        │
│                                                                      │
│   resolv-file=/etc/resolv.conf                                      │
│   → nameserver <LAPTOP_WAN_IP>  ← set via GUI, forwards to us      │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Data flow:
  1. Tool sends DNS query to DUT LAN IP (port 53)
  2. DUT's dnsmasq can't resolve locally → forwards upstream to LAPTOP_WAN_IP
  3. Our malicious server on WAN interface replies with exploit payload
  4. DUT's dnsmasq processes the malicious response → crash/hang/survive
  5. Tool checks DUT state via SSH (read-only)

Example setup (your IPs will differ):

The key requirement: Laptop WAN IP and DUT WAN IP must be on the same subnet, so the DUT can reach the laptop as an upstream DNS server.

How It Works

┌──────────┐     ┌───────────┐     ┌──────────────────┐     ┌──────────┐
│  SETUP   │ ──► │  TRIGGER  │ ──► │  STATE INSPECT   │ ──► │  VERDICT │
│          │     │           │     │                  │     │          │
│ Start    │     │ Send DNS  │     │ SSH to DUT:      │     │ PASS:    │
│ malicious│     │ query to  │     │ - pidof dnsmasq  │     │ survived │
│ DNS srv  │     │ DUT→DUT   │     │ - PID changed?   │     │          │
│ on WAN   │     │ forwards  │     │ - dmesg crash?   │     │ FAIL:    │
│ interface│     │ to us→we  │     │ - /var/log/msg   │     │ crashed/ │
│ (10.0.0. │     │ reply w/  │     │                  │     │ hung     │
│  211:53) │     │ exploit   │     │ Liveness query   │     │          │
│          │     │ payload   │     │ (version.bind)   │     │          │
└──────────┘     └───────────┘     └──────────────────┘     └──────────┘

NOTE: Tool does NOT modify DUT settings. User must set DNS to 10.0.0.211 via GUI.

QA Test Procedure

Prerequisites

• Testing laptop with two network interfaces (LAN + WAN)
• Python 3.6+ with paramiko installed (pip install paramiko)
• SSH access to DUT (root credentials)
• DUT admin GUI accessible

Step 1: Physical Connection

Connect the testing laptop to the DUT with two cables:

After connecting, note your laptop's IPs:

# Find your IPs
ip addr show | grep "inet "
# Example output:
#   inet 192.168.1.254/24 ...  ← this is your LAN IP
#   inet 10.0.0.211/24 ...     ← this is your WAN IP (use this for --laptop)

Step 2: Set DUT DNS to Laptop via GUI

1. Open a browser and go to the DUT admin page:
   • e.g., http://192.168.1.1 or http://myrouter.local
2. Log in with admin credentials
3. Navigate to: Connectivity → Internet Settings → Edit (next to IPv4)
4. Under DNS: select Static DNS
5. Set DNS 1 to your laptop's WAN IP (e.g., 10.0.0.211)
6. Click Apply
7. Wait 5-10 seconds for settings to take effect

Step 3: Run the Tool

cd /path/to/dnsmasq-cve-2026/

# Run all 6 CVE tests:
sudo python3 dnsmasq_cve_verify.py --laptop <YOUR_WAN_IP> --dut <DUT_LAN_IP> --dut-pass <SSH_PASSWORD>

# Example:
sudo python3 dnsmasq_cve_verify.py --laptop 10.0.0.211 --dut 192.168.1.1 --dut-pass '12345Asdf@'

The tool will:

1. Connect to DUT via SSH (read-only)
2. Start a malicious DNS server on your laptop's WAN IP
3. Verify DUT is forwarding DNS queries to it
4. Send exploit payloads for each CVE
5. Check if dnsmasq crashed or hung
6. Report PASS/FAIL per CVE

Step 4: Read Results

• PASS = DUT is safe (feature not active, or survived the attack)
• FAIL = dnsmasq crashed or hung (vulnerable!)
• ERROR = Could not connect or DUT not forwarding

Step 5: Restore DUT DNS

1. Go back to DUT admin GUI
2. Connectivity → Internet Settings → Edit
3. Under DNS: select Automatic (from ISP) or remove the static entry
4. Click Apply

Troubleshooting

Test Results (2026-05-31)

dnsmasq 2.78 platform (OVERALL: PASS)

dnsmasq 2.90 platform (OVERALL: PASS)

Conclusion

All Linksys routers tested are not practically exploitable for any of the 6 CVEs in their production build configurations. The dangerous features (DNSSEC, DHCPv6-via-dnsmasq) are either not compiled or not configured. Patches are still recommended as defense-in-depth.

Expected Results

Pre-fix (dnsmasq 2.78, no-DNSSEC build):

Pre-fix (dnsmasq 2.90 with DNSSEC enabled):

Post-fix (dnsmasq 2.92rel2 or backport patches applied): All 6 CVEs → PASS

Requirements

• Python 3.6+ with paramiko (pip install paramiko)
• Root/sudo on laptop (to bind DNS on port 53)
• SSH access to DUT (read-only — used for process state checks)
• Laptop connected to DUT's LAN (192.168.1.x network)

Options Reference

Other Tools

Remote Black-Box Tester (test_dnsmasq_cve_remote.py)

Lightweight version check only — queries version.bind to determine if dnsmasq version is below the fix. No SSH, no setup, no exploit payloads.

python3 test_dnsmasq_cve_remote.py 192.168.1.1

On-Device Script (test_dnsmasq_cve_on_device.sh)

Runs directly on the DUT via SSH/serial. Checks binary version and compile options.

scp test_dnsmasq_cve_on_device.sh [email protected]:/tmp/
ssh [email protected] "sh /tmp/test_dnsmasq_cve_on_device.sh"

Malicious DNS Server (malicious_dns_server.py)

Standalone exploit server for manual testing. Run it, point DUT's upstream DNS at it, then trigger queries to crash-5172.evil.test, crash-2291.evil.test, etc.

sudo python3 malicious_dns_server.py --port 53
# Then on DUT: configure upstream → this host
# Then trigger: dig @192.168.1.1 crash-5172.evil.test

Verifying After Fix

After applying patches and flashing new firmware, re-run:

sudo python3 dnsmasq_cve_verify.py --laptop <YOUR_WAN_IP> --dut <DUT_LAN_IP> --dut-pass <SSH_PASS>
# Expected: all 6 PASS

Requirements Summary

References

• ISPreview: https://www.ispreview.co.uk/index.php/2026/05/string-of-dnsmasq-vulnerabilities-threatens-uk-broadband-routers.html
• Help Net Security: https://www.helpnetsecurity.com/2026/05/12/dnsmasq-vulnerabilities-cve/
• Upstream patches: https://thekelleys.org.uk/dnsmasq/CVE/
• dnsmasq changelog: https://thekelleys.org.uk/dnsmasq/CHANGELOG