Is CVE-2022-23748 (Dante Discovery Process Control) being exploited in the wild?

What CISA’s KEV listing tells you about exploitation

CVE-2022-23748 should be treated as actively exploited, not merely theoretically risky. CISA’s KEV catalogue is a practical signal that defenders should prioritise this issue as an urgent exposure, especially because the vulnerable component sits in a process-control path and enables DLL sideloading. For a running installation, the question is no longer whether exploitation is plausible, but whether exposure still exists.

Because the direct answer already confirms active exploitation, the first practitioner move is exposure confirmation. Identify where dante discovery process control is deployed, whether the affected executable is present, and whether any dependent services or management hosts still trust the vulnerable binary chain. If the product exists anywhere in the estate, treat it as a live remediation item rather than a backlog task.

To verify the condition in a defensible way, use the vendor advisory alongside the CISA Known Exploited Vulnerabilities Catalog and the CVE Program record. The point is to confirm the specific product and remediation path from authoritative sources, then map that to your own asset inventory and deployment scope.

Why this vulnerability is operationally serious

The key issue is not only that the flaw is exploitable, but that it affects a process-control component that can be abused through DLL sideloading. That attack pattern turns a legitimate execution path into a trust abuse opportunity, which often gives an attacker stealthier execution than a conventional exploit that trips obvious alarms. If the vulnerable component is present on systems that participate in operational workflows, the blast radius can extend beyond one host.

The practical risk is that an attacker who can place or influence a malicious DLL may gain code execution within the trusted application context. Once that happens, defenders may see normal process names, expected parent-child relationships, and benign-looking service behaviour even though the execution chain has been subverted. That is why exploited process-control vulnerabilities often become persistence or lateral-movement footholds, not just single-system incidents.

For broader vulnerability triage, the NIST National Vulnerability Database and FIRST EPSS remain useful for context, but CISA KEV should drive urgency here. When KEV and local exposure align, operational priority should move ahead of ordinary maintenance cadence.

What to do if remediation must wait

If you cannot remediate immediately, reduce the chance that the vulnerable process can be abused to load an untrusted library. Focus on limiting write access to directories and paths the application searches for DLLs, restricting who can launch or manage the process, and isolating hosts that run the software from unnecessary administrative access. Where the product is embedded in a critical workflow, the compensating control should be containment, not optimism.

Use the delay to look for signs of earlier compromise. Review process creation, unexpected module loads, unusual child processes, new scheduled tasks, new services, and any tampering near the application’s working directories. If you have endpoint telemetry, search for DLL sideloading patterns around the affected binary and inspect for recent changes in local administrators, service configuration, or startup paths.

If the system contains credentials, tokens, or service accounts that could have been accessible through the compromised process, rotate them after containment. That step is most important when the application runs with elevated trust or touches adjacent systems, because an apparently narrow code-execution flaw can still expose broader authentication material.

Risk and Threat Considerations

This vulnerability matters because active exploitation plus DLL sideloading creates a low-friction path from software flaw to trusted execution. The main threat is not only initial code execution, but abuse of the application’s normal trust boundary to hide malicious activity and broaden access.

Failure mechanism: An attacker leverages the vulnerable process-control behaviour in mDNSResponder.exe so a malicious DLL is loaded in place of a legitimate library, enabling execution under a trusted process context.

Impact: The resulting compromise can support persistence, stealthy malware execution, credential access, or follow-on lateral movement, especially where the product runs on systems with operational importance.

Practitioner Guidance

What to verify: Confirm every instance of Dante Discovery Process Control in your estate, then verify whether those hosts allow writable search paths, weak local admin practices, or other conditions that make DLL sideloading easier.

Decision rule: If the product is present and remediation is available, prioritise it as an urgent exploited-vulnerability fix; if remediation must wait, treat containment and path-hardening as temporary compensating controls rather than a complete answer.

What good looks like: The vulnerable binary is either removed, corrected by the vendor fix, or isolated so that untrusted code cannot influence its load path, and you have evidence that no suspicious module loads or related post-exploitation activity occurred before remediation.

Practitioner takeaway: A KEV-listed flaw with confirmed active exploitation should be handled as an exposure-management problem, not a patch-ticket problem, because the real question is whether the vulnerable trust path is still reachable.

Related resources from NHI Mgmt Group

• Guide: Zero-Day and Exploited Vulnerabilities Guide
• How do you patch or mitigate CVE-2022-23748 (Dante Discovery Process Control)?
• CVE-2022-23748 (Dante Discovery Process Control)
• Is CVE-2022-44877 (CWP Control Web Panel OS Command Injection) being exploited in the wild?
• Is CVE-2021-25337 (Samsung Mobile Devices Improper Access Control) being exploited in the wild?