Three exploited D-Link flaws filed under "NAS" that resolve to NVR hardware

Two D-Link command-injection and hard-coded-credential flaws plus a Backup Config integrity failure (CWE-494) are in CISA's exploited catalogue; the KEV entries say "NAS" and "DNR-322L", but the CPE match names DNR-series network video recorders.

The identification problem#

If you keep an inventory and match it against advisories, the interesting thing about these three CVEs is not the command injection. It is that CISA's KEV entry for the two 2024 flaws lists the product as "Multiple NAS Devices", and the NVD prose names DNS-320L, DNS-325, DNS-327L and DNS-340L, all network-attached storage. Anyone filtering the catalogue for camera or recorder gear scrolls straight past.

The CPE configuration attached to those same records in this dataset resolves to DNR-202L, DNR-322L and DNR-326. D-Link's DNR line is network video recorders, not storage.

• Fact: KEV labels CVE-2024-3273 and CVE-2024-3272 "Multiple NAS Devices". NVD's descriptions for both name DNS-series storage "up to 20240403". The exploit reference on both records is the same repository, netsecfish/dlink.
• Fact: The CPE-resolved affected-product list in this record enumerates DNR-series recorders for all three CVEs.
• Inference, labelled: When a recorder and a NAS share a firmware base and the same CGI, one CVE can legitimately cover both. A CPE range that sweeps DNR recorders into a bug written up against DNS storage may equally be over-broad. Nothing in these sources confirms that nas_sharing.cgi is present and reachable on a DNR-202L or a DNR-326. Treat the DNR entries as "match your inventory, then check the box for the file", not as proven-vulnerable.

CVE-2022-40799 is the unambiguous one. It was assigned against the DNR-322L directly, and CISA's KEV product field for it reads "DNR-322L". If you run DNR-322L, that one is yours without argument.

What an attacker actually needs#

CVE-2024-3272 (CWE-798, hard-coded credentials) and CVE-2024-3273 (CWE-77, command injection) chain, and both carry CVSS 9.8 with the vector AV:N/AC:L/PR:N/UI:N. PR:N and UI:N mean what they say. The attacker needs the device to answer on HTTP; nothing else of yours is required.

The record names the pieces without giving the full request: an HTTP GET handler on /cgi-bin/nas_sharing.cgi, the argument user with the value messagebus satisfying authentication, and the argument system carrying the injected command. We have not reproduced the exploit and are not publishing a request line we have not verified.

CVE-2022-40799 (CWE-494) sets a higher bar. NVD describes it as a Data Integrity Failure in the Backup Config feature of DNR-322L at or below 2.60B15, allowing an authenticated attacker to execute OS-level commands. CVSS 8.8, vector PR:L. That makes it a valid-credential or post-auth escalation problem rather than a spray-the-internet one, so how much it matters to you turns entirely on who can reach the admin interface.

Impact and blast radius#

Command execution as the web service account on a recorder is command execution on the device that holds your footage. The realistic outcomes are dull and bad. The box joins a botnet, or video is deleted or altered before anyone ever reviews it. A quieter one is a foothold on the camera segment, and camera VLANs are frequently less isolated than the deployment diagram claims: our judgement, not a measurement.

This record carries no exposure count. What it carries is a 9.8 with PR:N on a device class that is routinely port-forwarded so a site manager can watch footage from home. Count your own.

Exploitation evidence#

The three CVEs are not equally well-evidenced, and the difference is worth keeping straight when you rank them.

• CVE-2024-3273 — In KEV since 2024-04-11, remediation due 2024-05-02. EPSS score 0.99997, percentile 0.99989, calculated 2026-09-04: the probability of exploitation activity in the next 30 days, effectively pinned at the ceiling. GreyNoise published in-the-wild observations under the title "CVE-2024-3273 — D-Link NAS RCE exploited in the wild"; we cite it for the fact of observed exploitation, not for its telemetry, which we have not independently reviewed. Public exploit code is referenced from the NVD record.
• CVE-2024-3272 — In KEV since 2024-04-11, remediation due 2024-05-02. EPSS score 0.98038, percentile 0.99907. It is the credential half of the same chain and carries the same exploit reference, so real-world use tracks CVE-2024-3273.
• CVE-2022-40799 — In KEV since 2025-08-05, due 2025-08-26. CISA's inclusion is itself the assertion of exploitation; this record carries no separate in-the-wild report for it. EPSS score 0.31719, but percentile 0.98173. A tenth the probability of the 2024 pair, still above 98% of all CVEs. Lower, not low. A public exploit is referenced on GitLab.

All three carry a KEV ransomware field of "Unknown". That is a gap in CISA's evidence, not a finding that ransomware crews have left these devices alone.

Inference, labelled: an unauthenticated 9.8 with public exploit code and a ceiling EPSS score is, in our judgement, under continuous opportunistic scanning. No source here counts victims and we are not asserting one.

Affected products, and the gaps in the data#

From this record's CPE resolution, by model rather than by CVE, because that is how inventory matching actually runs:

The DNS storage models that NVD's prose and the exploit reference actually name, DNS-320L, DNS-325, DNS-327L and DNS-340L, are not in the CPE-resolved list above. This table is therefore not the complete affected set. It is the slice that matches recorder inventory, and D-Link's SAP10383 announcement covers the NAS side that this record does not reproduce.

The <= 2026-02-05 entries put a date where a firmware string belongs. Read them as a placeholder rather than a fixed-in line, and confirm the running build on the device itself.

There is no patch, but the three do not share a disposition#

CVE-2024-3273 and CVE-2024-3272 are both marked UNSUPPORTED WHEN ASSIGNED, and NVD records that the vendor was contacted, confirmed end-of-life immediately, and directed users to retire and replace. The KEV action for both says the hardware has reached EOL or EOS and should be retired and replaced per vendor instructions.

CVE-2022-40799 carries no EOL marker in this record. Its KEV action reads "Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable," and one of its references is a live dlink.com DNR-322L product page. Do not assume the same disposition for both. No fixed firmware build is named for any of the three here.

Until the hardware is gone:

1. Take it off any network an attacker can reach. No inbound from the internet, no exposed admin plane. If it must keep running, put it on an isolated VLAN with an explicit allowlist to the one or two hosts that pull footage.
2. Block the endpoint upstream if a proxy fronts the device: deny any request to /cgi-bin/nas_sharing.cgi. This does not fix the box. It removes the internet-facing path to the unauthenticated chain.
3. For CVE-2022-40799 specifically, lock down the authenticated admin interface. Unique credentials that are not reused anywhere else, and no external reachability, because that bug needs a session before anything else happens.
4. If you are federal or federally contracted, both KEV due dates have already passed — 2024-05-02 for the 2024 pair, 2025-08-26 for CVE-2022-40799. That is a remediation deadline in the record, not a suggestion, and it is the field most likely to be missed when the product label says NAS.
5. Treat anything internet-exposed since April 2024 as suspect. Inference, labelled: given the EPSS figures and the published in-the-wild reporting, we judge an exposed DNS or DNR box more likely to have been probed than not. That is a judgement about probability, not a detection. Rebuild the footage path off it before you trust the footage.

How to check#

• Fingerprint by response. A live /cgi-bin/nas_sharing.cgi on the device is the tell, and it is cheap to test across your own estate.
• Match on the file and the model, not the KEV product label. If your asset inventory keys off "NAS" against "NVR" categories, this record will not surface against your camera gear. Re-run the match on CPE and on model number, covering DNR-202L, DNR-322L and DNR-326 as well as the DNS-320L, DNS-325, DNS-327L and DNS-340L storage siblings, regardless of whether the advisory called it storage or a recorder.
• Cross-check against D-Link's SAP10383 announcement for the NAS-side model list, which this record does not carry.

Sources

1. D-Link support announcement SAP10383. D-Link
2. CVE-2024-3273 — D-Link NAS RCE exploited in the wild. GreyNoise
3. netsecfish/dlink. netsecfish
4. lu-ka/cve-2022-40799. lu-ka
5. CISA Known Exploited Vulnerabilities Catalog. CISA

Revision history