Yes. CISA added CVE-2025-29635 to its Known Exploited Vulnerabilities catalogue on 24 April 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. D-Link DIR-823X contains a command injection vulnerability that allows an authorized attacker to execute arbitrary commands on remote devices by sending a POST request to /goform/set_prohibiting via the corresponding function.
What active exploitation means for a command-injection router CVE
For a router issue like this, the practical question is not just whether the flaw exists, but whether it is already part of real attacker tradecraft. Once a device vulnerability is in the KEV catalogue, it should be treated as an active exposure on the internet, especially if the affected device is reachable from untrusted networks or is managed inconsistently across sites.
Command injection on edge hardware is especially dangerous because the attacker does not need a complex chain after reaching the vulnerable function. A single crafted request can become a device-level execution path, which means the router can be used for surveillance, persistence, traffic manipulation, or a foothold into the local network if the device is exposed or lightly segmented.
For operators that manage large fleets of network devices, the issue is not only patch urgency. It is also about whether the device was ever placed in a position where a remote command path would matter, and whether logging, segmentation, and admin access practices are strong enough to show misuse quickly. The IoT Security Guide is useful here because edge and consumer-network devices often fail in the same way, through weak exposure control, weak firmware hygiene, and limited visibility.
What exposure to check before you assume you are safe
Start with asset confirmation, then verify whether the router is actually internet-facing or reachable from any semi-trusted internal zone. Many organisations assume a branch router, small-office gateway, or lab appliance is harmless because it sits outside the server estate, but edge devices are often the easiest path to administrative execution if they were left on default management patterns or loosely exposed support ports.
Next, check whether the vulnerable function is reachable in your deployment pattern, whether remote administration is enabled, and whether the device has been retained in service beyond its intended lifecycle. The key issue is not just whether a device is patched, but whether it still has a reachable management surface that an attacker could use while the device remains trusted by the rest of the network.
If you are triaging exposure across a broader vulnerability programme, use the Vulnerability Management Guide to align this finding with asset scope, verification, and remediation prioritisation. For actively exploited issues, the Zero-Day and Exploited Vulnerabilities Guide is the right model for emergency triage, even when the flaw is no longer technically a zero-day.
What to do if patching is delayed or the device is already suspect
If you cannot remediate immediately, the safest short-term move is to reduce reachability and remove the device from any role that would let a compromise influence other systems. That means tightening management access, restricting source IPs, disabling unnecessary remote admin paths, and isolating the device so a successful command injection does not automatically become lateral movement.
When a KEV-listed flaw is present on a live device, a simple patch-first mindset is not enough. Treat the device as potentially abused until you have checked for configuration changes, strange outbound connections, unexpected admin sessions, altered DNS or routing settings, and any sign that the box is being used as a relay or pivot point. If the router supports logs or telemetry, preserve them before making disruptive changes.
If you see evidence of tampering, rotate any credentials, tokens, or shared secrets that were administered through or stored on the device, and review adjacent systems that trusted it. The most important practical question is whether the device merely needs a software fix, or whether it has already become part of an attacker-controlled path.
Risk and Threat Considerations
Active exploitation turns a router CVE from a maintenance issue into an access-path issue. Edge devices are attractive because they sit at trust boundaries, often have broad network reach, and are frequently less monitored than servers or endpoints.
Failure mechanism: An attacker sends a crafted POST request to the vulnerable function, gains command execution on the device, and can then change settings, create persistence, intercept traffic, or use the router as a foothold into internal systems.
Impact: The exposed device can become a launch point for further compromise, traffic manipulation, or service disruption, and the organisation may miss early signs because network appliances often have weaker detection coverage than user systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation makes rapid exposure discovery and remediation central. |
| Recommendation — Prioritise the device for continuous vulnerability scanning and rapid remediation tracking. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Router command injection becomes worse when management access is broadly reachable. |
| DE.CM-01 — Network Monitoring | Exploit attempts and post-compromise device changes require network visibility. | |
| Recommendation — Restrict administrative access to the device to approved management paths only. Monitor the device and its segment for unusual requests, sessions, and outbound traffic. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue is a remediated vulnerability with active exploitation evidence. |
| AC-17 — Remote Access | The vulnerable path is remote and should be constrained during exposure reduction. | |
| Recommendation — Remediate the flaw promptly and verify that the fix is actually deployed. Limit remote administrative access to the router to tightly controlled channels. | ||
Practitioner Guidance
What to prioritise: Triage the asset as an actively exploited internet-edge exposure, not as a routine patch ticket. If the router is externally reachable, reachable from a third-party segment, or used in a branch or OT-adjacent environment, move it to the front of the queue.
What to verify: Confirm whether the vulnerable management path is reachable, whether any configuration drift or unexpected outbound traffic exists, and whether recent admin changes match known change windows. If the device cannot produce useful logs, compensate with network telemetry from adjacent controls.
Practitioner takeaway: For KEV-listed router flaws, the question is not only whether you have patched, but whether the device has already been used as an execution point or pivot, because that determines whether remediation must include compromise assessment and credential review.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2025-29635 (D-Link DIR-823X Command Injection)?
- CVE-2025-29635 (D-Link DIR-823X Command Injection)
- Is CVE-2025-9377 (TP-Link Archer C7(EU) and TL-WR841N/ND(MS) OS Command Injection) being exploited in the wild?
- Is CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection) being exploited in the wild?