This command injection in the DWR-M961's formTracerouteDiagnosticRun interface is as severe as the 9.8 CVSS suggests—and the root cause should concern you more than the specific endpoint. The diagnostic handler constructs shell commands directly from user-supplied host and ipVer parameters without sanitization, then executes them through system() or equivalent. The web server runs as root, so successful injection gives immediate full device compromise with no privilege escalation required.
What matters most: this is almost certainly not an isolated flaw. The form-based handler pattern that passes unsanitized input to shell invocation is a signature of reference designs in this product class. If your D-Link device has a traceroute diagnostic feature, examine whether it uses the same handler architecture—even if the field names differ. The same vulnerability class has appeared in D-Link, Netgear, and Linksys devices for over fifteen years, which tells you the template persists even when individual CVEs are patched.
Audit priority: locate every form handler in your firmware that accepts user input and invokes shell commands. Focus on diagnostic interfaces, as those are the most common vector. Don't assume version 1.1.5 fixes this permanently—verify what the patch actually does. If it only adds input validation to this endpoint without refactoring the handler architecture, the underlying pattern remains exploitable through other fields or future features. Check whether the web binary still contains the shell-invocation code path even if it's now guarded; embedded firmware patches frequently conditionalize rather than remove dangerous capabilities.
If you're defending a fleet: map which device models share the same reference design, because the same flaw likely exists across all of them. The exposure window here isn't just CVE-to-patch—it's CVE-to-end-of-life, since embedded devices typically stop receiving updates years before they're retired from service.