Yes. CISA added CVE-2022-40799 to its Known Exploited Vulnerabilities catalogue on 5 August 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. D-Link DNR-322L contains a download of code without integrity check vulnerability that could allow an authenticated attacker to execute OS level commands on the device.
What “exploited in the wild” means for this CVE
For a CVE like this, “in the wild” is not a vague claim, it means there is credible evidence that attackers are actively using the flaw outside the lab. In practice, the strongest public signal is inclusion in CISA’s Known Exploited Vulnerabilities catalogue, alongside vendor advisories, exploitation reports, and incident telemetry that support the same conclusion.
That distinction matters because many vulnerabilities are public long before they are operationally dangerous. A code download flaw on a network device can sit unnoticed until someone has a reason to target exposed appliances at scale. Once exploitation is confirmed, the question shifts from “could this be abused?” to “is any instance still reachable, unpatched, or already compromised?”
How to confirm whether your D-Link DNR-322L is exposed
Start with asset confirmation, not patch work. You need to know whether the device exists anywhere in your environment, whether it is still powered on, whether it is reachable from untrusted networks, and whether anyone can still authenticate to the management interface. For internet-facing or remotely administered appliances, exposure often persists long after owners forget the device is there.
Then validate whether the configuration and management path make exploitation feasible. Check whether the device is still in service, whether it is isolated behind VPN or administrative controls, and whether any unsupported or end-of-life instance is being kept alive because of stored data or legacy backups. The CISA Known Exploited Vulnerabilities Catalog and the CVE Program are the authoritative places to anchor the record and remediation status of the issue.
If your team tracks internet exposure or device inventory centrally, correlate this CVE against that inventory rather than relying on generic vulnerability scans alone. The practical question is not just whether the model name appears in a database, but whether a live instance is reachable in a way an attacker could exploit.
Containment, remediation, and compromise checks
The remediation priority is simple: remove the exposure path, apply the vendor fix or mitigation, and treat any externally reachable device as a possible compromise candidate until proven otherwise. For a flaw that can lead to OS level command execution, delaying action increases the chance that an attacker can establish persistence, alter stored data, or use the device as a foothold into adjacent systems.
If patching must wait, place the device behind strict access controls, limit management access to trusted networks, and restrict all unnecessary inbound paths. For a storage appliance, containment should also include review of shared folders, admin accounts, and any credentials that may have been used to manage the device from other systems. If the device has been reachable from the internet, perform a compromise assessment before returning it to normal service.
Where evidence suggests unauthorized access, rotate any credentials that were used on or through the device, including administrative logins, backup credentials, and adjacent account material that may have been exposed through the management plane. Review logs for unexpected command execution, configuration changes, file access, new accounts, altered shares, or outbound connections that do not fit normal NAS behaviour.
Risk and Threat Considerations
Devices like network storage appliances are attractive targets because they often sit at a trust boundary, hold valuable files, and are managed less rigorously than servers or endpoints. Once a flaw enables code execution, attackers can use the appliance for data theft, credential harvesting, lateral movement, or as a staging point for follow-on activity.
Failure mechanism: The vulnerability lets an authenticated attacker bypass integrity expectations for downloaded code and execute commands on the device, which can turn a routine management plane into an execution path.
Impact: A compromised appliance can expose stored data, undermine backups, and create a foothold inside the network, so the business risk is broader than the device itself.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | The question depends on finding exposed DNR-322L assets quickly. |
| ID.RA-01 — Asset vulnerabilities are identified and documented | Active exploitation status makes vulnerability identification and exposure assessment central. | |
| Recommendation — Inventory every DNR-322L instance and map its exposure before remediation. Document the vulnerable appliance, exposure path, and exploitation status for each instance. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue requires timely remediation of an actively exploited flaw. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Compromise checks depend on reviewing logs for malicious activity on the device. | |
| Recommendation — Apply the vendor fix or mitigation and verify vulnerable instances are removed from service. Review appliance and adjacent system logs for signs of command execution or unauthorized access. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV status and exploitability make prioritised vulnerability handling central. |
| CIS-18 — Penetration Testing | Posture validation and compromise checking benefit from targeted verification of exposed devices. | |
| Recommendation — Prioritise this KEV-listed device flaw ahead of non-exploited vulnerabilities. Validate whether the appliance remains reachable and exploitable after containment changes. | ||
Practitioner Guidance
What to prioritise: Confirm whether any DNR-322L units are live, reachable, and still administratively trusted. If one is exposed to untrusted networks, treat it as high priority even before you finish full triage.
What to verify: Validate the exact device population, the current management exposure, and whether any credential used to administer the device has been reused elsewhere. If you cannot verify those three points quickly, assume the blast radius may be larger than the appliance itself.
Common mistake: Teams often patch the firmware and stop there. For an exploited device flaw, that is incomplete unless you also check for persistence, changed settings, and any sign that stored data or credentials were accessed before remediation.
Practitioner takeaway: When a vulnerability is confirmed as exploited in the wild, the operational question becomes containment plus compromise review, not just patching, because the main risk is what the attacker may already have done before you close the hole.
Related resources from NHI Mgmt Group
- Guide: IoT Security Guide
- CVE-2022-40799 (D-Link DNR-322L Download of Code Without Integrity Check)
- How do you patch or mitigate CVE-2025-15556 (Notepad++ Download of Code Without Integrity Check)?
- CVE-2025-15556 (Notepad++ Download of Code Without Integrity Check)
- CVE-2026-3502 (TrueConf Client Download of Code Without Integrity Check)