CVE-2024-40890 is an OS command injection vulnerability in Zyxel DSL CPE Devices. CISA added it to the Known Exploited Vulnerabilities catalogue on 11 February 2025, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
What this vulnerability means in practice
OS command injection is dangerous because it can turn a network-facing flaw into operating-system execution on the device itself. On embedded DSL CPE equipment, that can mean an attacker runs commands with the privileges available to the management process, which is often enough to change configuration, weaken defenses, or pivot further into the environment.
Because this is a publicly exploited CVE, the right mental model is not just “patch eventually” but “treat as active exposure now.” The authoritative places to confirm the current record and remediation details are the CVE Program and the NIST National Vulnerability Database.
Why command injection is especially serious in CPE devices
Customer-premises equipment sits on the boundary between an organisation and its provider, so compromise can affect both local operations and upstream trust assumptions. A successful injection in this class of product may expose management interfaces, alter routing or DNS behaviour, or create a foothold that survives normal user activity because the affected device is part of the access path itself.
That is why command injection on edge equipment is rarely just a local bug. It can become a control-plane problem, an availability problem, and in some cases a credential or session exposure problem if the attacker uses the device to observe or redirect management traffic.
How organisations should assess exposure
Exposure starts with knowing whether the vulnerable model is present anywhere in the estate, including branch offices, remote sites, unmanaged locations, and leased equipment. If the device is internet-exposed, remotely managed, or reachable from partner networks, the urgency rises sharply because exploitation can occur without an internal foothold.
For prioritisation, organisations should rely on their asset inventory, vendor advisory, and the KEV status rather than on generic vulnerability scores alone. Where product scope is unclear, compare the exact device model and firmware against the vendor’s guidance, then verify whether the service is reachable from untrusted networks and whether administrative interfaces are segmented.
Remediation, detection, and post-exploitation review
Apply the vendor fix or mitigation as soon as operationally possible, and use compensating controls only as a short-lived bridge. If patching is delayed, isolate the device, restrict administrative reachability, and remove any unnecessary exposure to the internet or broad internal networks.
For detection, look for unexpected command execution patterns, altered device settings, new outbound connections from the device, and logs that show management activity outside normal change windows. After remediation, review whether the device was already used as an initial access point, and rotate any credentials or keys that could have been captured through the appliance or its management path.
Risk and Threat Considerations
This vulnerability is material because attackers who can inject commands into a CPE device may be able to take control of a trusted edge node that sits close to the organisation’s network boundary. That creates both direct operational disruption and a convenient platform for persistence or lateral movement.
Failure mechanism: The injected payload is interpreted by the device’s underlying command execution path, allowing the attacker to run arbitrary OS commands instead of the intended administrative action.
Impact: The attacker may modify configuration, disrupt connectivity, expose management access, or establish a durable foothold that outlives the original exploit attempt.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Asset Inventory | This CVE requires knowing whether the vulnerable CPE is present. |
| PR.IP-12 — Vulnerability Management | KEV-listed exploited flaws require prioritized remediation and verification. | |
| Recommendation — Inventory all Zyxel DSL CPE devices and map them to the affected exposure set. Prioritise remediation of the exploited command injection and verify the fix or mitigation. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The subject is an actively exploited software flaw requiring remediation control. |
| Recommendation — Remediate the vulnerable device software and validate that the flaw is no longer reachable. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation makes timely vulnerability identification and response central. |
| Recommendation — Continuously identify, prioritise, and remediate the exposed device before it remains exploitable. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Command injection is a classic architecture and input-handling failure. |
| Recommendation — Use secure command handling patterns that avoid shell execution of untrusted input. | ||
Practitioner Guidance
Why practitioners should care: Treat KEV-listed command injection on edge equipment as a time-sensitive exposure, not a routine vulnerability-management item. Devices at the network perimeter often have outsized blast radius, so delayed action can preserve an attacker path that is hard to observe once it is in place.
Practitioner takeaway: Prioritise exposure confirmation, rapid remediation, and a compromise review of the device and any adjacent management credentials immediately after the fix is applied.