Yes. CISA added CVE-2024-40890 to its Known Exploited Vulnerabilities catalogue on 11 February 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Multiple Zyxel DSL CPE devices contain a post-authentication command injection vulnerability in the CGI program that could allow an authenticated attacker to execute OS commands via a crafted HTTP request.
What “being exploited in the wild” means for this Zyxel flaw
CVE-2024-40890 is not just a theoretical weakness in Zyxel DSL CPE, it has crossed into confirmed exploitation territory. For practitioners, that changes the question from “is there a bug?” to “is this device exposed, reachable, and already being targeted?” The practical task is to identify affected internet-facing appliances, validate administrative exposure, and treat the issue as an active incident-response priority.
Because the vulnerability is post-authentication command injection in a web-facing CGI path, the immediate concern is whether an attacker can already authenticate, reuse a stolen session, or reach the management plane through weak access controls. That means exposure is often broader than the initial bug description suggests, especially on edge devices that were left with permissive management access or weak operational oversight.
If you need a broader playbook for these devices, the Edge Device Security Guide is the right companion reference because it focuses on appliance hardening, management exposure, logging, and end-of-life planning for internet-facing equipment.
How to confirm exposure and respond without waiting for compromise
Start by inventorying every Zyxel DSL CPE instance, including remote sites, branch offices, and any forgotten lab or secondary WAN equipment. Then verify whether the management interface is reachable from untrusted networks, whether administrative accounts are still active, and whether the device is running a version addressed by the vendor advisory and CISA KEV entry. CISA’s inclusion is the operational signal that this is no longer a watchlist item.
If the device cannot be patched immediately, reduce attack surface first: restrict management access to trusted networks, remove unnecessary remote administration, and rotate any credentials that can reach the appliance or downstream services. For edge devices, delaying patching is only defensible when you can also contain access and monitor for abnormal command execution attempts.
When the situation requires prioritisation across many findings, use the Vulnerability Management Guide to anchor the decision in KEV status, asset criticality, exposure, and verification rather than in scan noise or CVSS alone.
For practitioners who want a deeper read on why confirmation and response speed matter after an exploit enters KEV, the Zero-Day and Exploited Vulnerabilities Guide explains the triage logic for exploited flaws, including emergency mitigation and compromise assessment.
What to look for if the device may already be compromised
Command injection on a network appliance can leave subtle traces, so a clean-looking device is not proof of safety. Review configuration drift, unexpected shell-like activity in logs where available, new user accounts, altered startup scripts, unexplained outbound connections, and any changes to DNS, VPN, forwarding, or remote management settings. If logs are sparse, assume visibility is limited and compensate with network telemetry and firmware integrity checks.
Failure often comes from assuming that a post-authentication bug only matters if administrative credentials were obviously stolen. In practice, attackers may get there through reused passwords, weak remote access hygiene, or a different foothold on the same management path. If you find signs of abuse, treat adjacent credentials and sessions as potentially exposed too, not just the appliance itself.
The Web Application Attacks Guide is useful here because command injection is one of the clearest examples of how a crafted request can cross from input handling into operating-system command execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | CVE-2024-40890 affects authenticated access paths on a device service interface. |
| AC-6 — Least Privilege | Command injection impact depends on overbroad administrative reach on the appliance. | |
| SI-2 — Flaw Remediation | The question centers on an actively exploited vulnerability requiring rapid remediation. | |
| Recommendation — Enforce strong service-to-service authentication and restrict management-plane access paths. Limit admin and management privileges to the minimum required for device administration. Prioritise patching and mitigation for vulnerabilities with confirmed exploitation. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed exploitation requires prioritised discovery, validation and remediation. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Reducing management exposure and hardening the appliance are central mitigations. | |
| Recommendation — Track the device in continuous vulnerability management and accelerate remediation. Harden the appliance configuration and remove unnecessary administrative exposure. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | The flaw enables OS command execution through a crafted request. |
| T1190 — Exploit Public-Facing Application | The vulnerability is exploited through a web-reachable device interface. | |
| Recommendation — Map observed activity to command execution techniques and hunt for spawned shell activity. Monitor internet-facing services for exploitation attempts and initial access abuse. | ||
Practitioner Guidance
What to prioritise: Treat confirmed exploitation as a response problem, not a patch-only problem. The first decision is whether the appliance is internet reachable or reachable from broad internal segments, because that determines how quickly compromise can recur even after remediation.
What to verify: Confirm the exact appliance model, management exposure, and whether the device has any business-critical role that would make reboot or replacement operationally risky. Also verify whether logs are adequate enough to support a compromise assessment, because weak logging often means you need to rely more heavily on network-level evidence.
Decision rule: If the device has any exposed administrative path and you cannot patch immediately, isolate it first, then rotate any credentials or sessions that may have been usable through that path. If you can patch quickly, still perform targeted hunting before declaring the issue closed.
Practitioner takeaway: Once a device vulnerability is in KEV, the question is no longer whether exploitation is possible, but whether the organisation can prove the appliance was contained before adversaries could turn it into persistent access.