CVE-2025-29635: D-Link DIR-823X Command Injection (RCE)
Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-04-24. Federal agencies must patch by 2026-05-08.
| Field | Value |
|---|---|
| CVE ID | CVE-2025-29635 |
| CVSS score | 7.2 (NVD tool output; exact vector string unknown due to blocked NVD page access in this run) |
| Attack vector | HTTP POST to /goform/set_prohibiting (per NVD description) |
| Auth required | Yes — “authorized attacker” (exact role/privilege level not specified in retrievable sources) |
| Patch status | Unknown — fixed version not verifiable from primary sources in this run (vendor advisory / NVD references were blocked or missing) |
TL;DR - D-Link DIR-823X firmware 240126 and 240802 have a command injection → RCE flaw via POST
/goform/set_prohibiting. - It is CISA KEV-listed, meaning exploitation is confirmed in the wild; treat as actively targeted. - Patch/fixed version is not confirmed from accessible sources; assume you must isolate/replace if you cannot upgrade.
Vulnerability at a Glance (What matters operationally)
CVE-2025-29635 is a command injection vulnerability that can lead to remote code execution (RCE) on D-Link DIR-823X devices. The NVD description specifies exploitation by sending a POST request to /goform/set_prohibiting, which triggers command execution through the corresponding handler/function. While the public details we could retrieve do not include the exact vulnerable parameter names or payload structure, the impact category is clear: an attacker who can hit the vulnerable handler with valid authorization can execute arbitrary commands on the device.
The operational urgency is driven less by the CVSS number (7.2) and more by the CISA Known Exploited Vulnerabilities (KEV) listing. KEV inclusion is a strong signal that defenders should treat this as “not theoretical”—it is being exploited in real environments. For internet-facing routers (or routers reachable from less-trusted internal segments), that typically translates into rapid compromise, persistence, and possible downstream pivoting to the rest of the network.
Technical Notes: Quick reference (evidence-backed)
- Affected firmware versions (as stated in NVD tool output):
240126,240802 - Vulnerable endpoint (as stated in NVD description):
POST /goform/set_prohibiting - Exploit precondition (as stated in NVD description): “authorized attacker” (details unknown)
What Is CVE-2025-29635?
At a technical level, command injection vulnerabilities occur when a web handler accepts attacker-controlled input and passes it into a shell command (or system call) without proper validation/escaping. When successful, the attacker’s input becomes part of the executed command line, enabling arbitrary command execution under the privileges of the web process (often elevated on embedded devices).
In this case, the vulnerable surface is described as the router’s web management interface endpoint /goform/set_prohibiting. “goform” endpoints are commonly used in embedded web UIs for configuration changes. The NVD description indicates that sending a crafted POST request to this path causes the corresponding function to execute attacker-controlled shell commands. We cannot verify the exact code path or parameterization from primary sources during this run because the referenced GitHub write-up was unavailable (404) and the referenced Akamai article was blocked (403). Defenders should therefore assume payloads could be simple shell metacharacter injections (;, &&, |, backticks, $()) and that automated botnets may already have weaponized the bug.
Who Is Affected?
Based on the NVD tool output, the affected product is D-Link DIR-823X, and the affected firmware versions called out are 240126 and 240802. Those version identifiers are important for asset inventory and triage: if you find DIR-823X devices running either of those versions, prioritize them for containment and remediation.
A key nuance: we cannot confirm (from retrievable primary sources in this run) whether only those two firmware releases are vulnerable, or whether they are simply the versions tested/reported. In the absence of a vendor advisory stating an exact affected range (e.g., “all versions before X.Y.Z”), defenders should assume that other nearby builds may also be affected until proven otherwise. Treat any DIR-823X with the /goform/set_prohibiting handler exposed as potentially vulnerable, especially if it is reachable from the internet or untrusted networks.
Technical Notes: How to identify firmware versions
Because environments vary, use whatever management channel you have: - Local UI (Status/System page): record the firmware build string. - If you have centralized inventory, store model + firmware as searchable fields. - If you manage routers via SSH/Telnet (not recommended unless tightly controlled), capture version output (command names differ by vendor and cannot be authoritatively provided here).
CVSS Score Breakdown (And what we can’t verify)
The CVSS score reported in the available NVD tool output is 7.2, which typically lands in “High” severity. That aligns with the impact of RCE, even when authentication is required, because exploitation can result in complete device compromise—configuration tampering, credential theft, traffic interception, and acting as a foothold for lateral movement.
However, the exact CVSS vector string is unknown in this write-up because direct retrieval of the NVD page was blocked (HTTP 403) during research. Without the vector, we cannot precisely confirm components like attack complexity, privileges required granularity, user interaction, scope, or the CIA impacts as NVD scored them. Practically, this means defenders should avoid arguing about the “true” severity based on the number alone and instead prioritize based on (1) KEV exploitation status, (2) edge device role, and (3) exposure of the management interface.
Exploitation Status (In the wild? PoC?)
Exploitation in the wild: confirmed. CVE-2025-29635 is listed in the CISA KEV catalog, which indicates CISA has credible evidence of real-world exploitation. The KEV entry includes:
- dateAdded: 2026-04-24
- dueDate: 2026-05-08
- requiredAction: apply mitigations per vendor instructions or discontinue use if mitigations are unavailable.
Public PoC: unknown from accessible sources. The NVD record references a GitHub URL that appears to be a technical write-up and/or PoC, but it was not retrievable (404) in this run, so we cannot confirm PoC availability or provide payload details. Another NVD reference points to an Akamai blog URL that was blocked (403), preventing verification of any exploitation-campaign specifics (for example, any linkage to Mirai-like botnets suggested by the URL path).
Defender takeaway: even without a verified PoC, KEV status means you should assume commodity exploitation exists and that scanning/exploitation attempts may be widespread and automated.
Additional Resources
For more information on incident response plans, refer to our article on what is an incident response plan.
If you want to learn about securing your network, check our guide on DNS and how it works.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
How to Detect It (Network and log-centric)
Detection for embedded router exploitation is often constrained by limited on-box logging. Your best leverage is network telemetry (reverse proxy logs if you have them, IDS/IPS, firewall logs, SPAN, or upstream web access logs if management is fronted by something). Since the known exploit vector is an HTTP POST to /goform/set_prohibiting, begin by hunting for requests to that path from unexpected sources and at unusual times.
Also look for secondary indicators of compromise consistent with router RCE: outbound connections from the router to unfamiliar IPs/domains, spikes in DNS queries, new NAT/port-forward rules, modified admin credentials, changes to remote-management exposure, or unexpected reboots. If you have EDR for the adjacent management host (jump box) or can capture packet data, you can often validate exploitation attempts even without perfect device logs.
Technical Notes: Concrete detection patterns and queries
1) Web/HTTP access log pattern (generic) If you have any upstream device logging HTTP requests to the router UI (reverse proxy, WAF, or a transparent proxy), hunt for:
POST /goform/set_prohibiting HTTP/1.1
Then pivot on: - Source IPs not in your admin network - Repeated attempts across many devices - Suspicious parameters containing shell metacharacters
2) Suricata/Snort-style signature (defensive starting point) You can create a simple rule to alert on POSTs to the vulnerable path. This will be noisy if legitimate admins use the feature, but it’s valuable for triage during an active campaign.
alert http any any -> $HOME_NET any (
msg:"CVE-2025-29635 suspicious POST to /goform/set_prohibiting";
flow:to_server,established;
http.method; content:"POST";
http.uri; content:"/goform/set_prohibiting"; nocase;
classtype:web-application-attack;
sid:2025296351; rev:1;
)
3) Splunk-style query (proxy logs / firewall with HTTP fields) Field names vary; adjust to your schema.
index=proxy OR index=firewall
( uri_path="/goform/set_prohibiting" OR url="*/goform/set_prohibiting*" )
http_method=POST
| stats count min(_time) as firstSeen max(_time) as lastSeen values(src_ip) as src values(dest_ip) as dst by host
| sort -count
If you don’t have HTTP-layer logs, fall back to L3/L4: - Identify hosts that should never reach router management IPs, then alert on new flows. - Alert on WAN-sourced traffic to the router’s management ports if any exposure exists.
Mitigation and Patching (What to do right now)
1) Patch/upgrade status: treat as unknown until verified
We cannot authoritatively state a fixed firmware version number for CVE-2025-29635 from retrievable primary sources in this run. The research attempt to access vendor/NVD reference material was blocked or missing. That means you should not rely on third-party reposts or forum claims for “fixed in version X” unless you can verify via vendor release notes or a signed firmware advisory.
In practical terms, your response plan should be: - Attempt to obtain an official D-Link advisory or firmware release notes for DIR-823X that explicitly mention CVE-2025-29635 and the fixed build. - If a fixed build exists and you can validate it, schedule an expedited upgrade. - If a fixed build does not exist or cannot be safely applied, follow CISA KEV guidance: discontinue use (replace hardware) or implement compensating controls to reduce exposure as much as possible.
2) Compensating controls: reduce reachability and privilege
Because exploitation requires an “authorized attacker,” tightening authentication and access control matters—but do not treat auth as a complete safeguard. Many router compromises occur after credential reuse, credential stuffing, or harvesting credentials from infected endpoints. Therefore: - Ensure the management UI is not exposed to the internet. - Restrict management access to a dedicated admin VLAN and/or a jump host. - Disable remote administration features you don’t need. - Rotate admin credentials and ensure they are unique, long, and stored in a password manager. - Consider placing the device behind an upstream firewall that can block access to the vulnerable endpoint from non-admin sources.
Technical Notes: Specific mitigation actions (commands/workarounds)
A) Block the vulnerable path at an upstream reverse proxy (Nginx example) If (and only if) you front the router UI with a reverse proxy for remote management, you can block the endpoint outright:
location = /goform/set_prohibiting {
return 403;
}
This is a workaround; it may break legitimate configuration workflows that depend on this handler. Validate with your network team.
B) Block access at the firewall (generic)
Because router platforms differ, here’s a vendor-agnostic approach: restrict access to the router management IP to your admin subnet only. For example, allow TCP 80/443 (or the router’s management ports) from ADMIN_NET and deny others.
If your firewall supports it, additionally block HTTP requests where the path equals /goform/set_prohibiting. Not all firewalls can match on URL paths; when they can, it’s an effective compensating control.
C) Upgrade command: unknown (must follow vendor procedure) A “one-size-fits-all” CLI upgrade command cannot be safely provided for DIR-823X from the sources available here. Assume upgrades occur via the device web UI or vendor-specific tooling. Actionable guidance: - Obtain the official firmware image and instructions from D-Link. - Validate checksums/signatures if provided. - Perform the upgrade during a maintenance window and confirm firmware version after reboot.
If you cannot obtain an official fixed firmware version that explicitly addresses CVE-2025-29635, assume the device remains at risk and proceed with isolation or replacement.
Incident Response Checklist (If you suspect compromise)
Start by assuming a compromised router is an untrusted network device. Preserve evidence where possible, but prioritize containment: 1. Isolate the router from the internet/WAN if feasible, or block inbound management access immediately. 2. Capture network telemetry (pcap, NetFlow) from the upstream switch/firewall around the suspected time window. 3. Check configuration drift: DNS settings, NAT rules, port forwards, admin users, remote management toggles. 4. Rotate credentials used to manage the router and any reused passwords elsewhere. 5. Factory reset + known-good firmware (only if you have a verified clean firmware source); reconfigure from scratch rather than restoring old backups. 6. If no fixed firmware is available, replace the device and treat it as potentially hostile until removed.
References (Primary sources used/attempted)
- CISA KEV catalog entry (confirms exploitation in the wild):
https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-29635 - NVD reference URL (not retrievable in this run; 404):
https://github.com/mono7s/Dir-823x/blob/main/set_prohibiting/set_prohibiting.md - NVD reference URL (not retrievable in this run; 403):
https://www.akamai.com/blog/security-research/2026/apr/cve-2025-29635-mirai-campaign-targets-d-link-devices