CVE-2022-23748 is a process control vulnerability in Audinate Dante Discovery. CISA added it to the Known Exploited Vulnerabilities catalogue on 6 February 2025, which means attackers have used it in real attacks. Dante Discovery contains a process control vulnerability in mDNSResponder.exe that all allows for a DLL sideloading attack.
What this vulnerability means for Dante Discovery
CVE-2022-23748 is dangerous because a process control weakness inside a discovery component can let an attacker hijack trusted execution flow rather than breaking in through a normal login path. In practice, that shifts the problem from ordinary software failure to code execution or payload loading through a process the system already expects to run.
When a Windows process can be influenced so it loads an attacker-controlled library, the security boundary is the process itself, not just the application feature exposed to users. That makes the issue especially important in environments that rely on the product for device discovery, network visibility, or service coordination.
Why DLL sideloading is such a serious abuse path
DLL sideloading works because Windows may load a library from a location the attacker can influence if the application resolves dependencies unsafely. Once that happens, malicious code can run with the same trust context as the legitimate process, which often makes the activity harder to spot than a direct executable drop.
For defenders, the danger is not only initial execution. Sideloading can become a staging method for follow-on actions such as persistence, credential access, internal recon, or lateral movement, depending on what the compromised process can reach. The key security lesson is that a process-control flaw can create a much wider blast radius than the vulnerable component itself.
Reader context on this pattern is easier to see in broader exploitation coverage, including Gladinet Hard-Coded Keys RCE Exploitation and Vulnerability Management Guide, which both show how exploited vulnerabilities move from disclosure into active abuse and prioritisation.
How organisations assess exposure and likely impact
Exposure checking starts with inventory, because a CVE matters only where the affected product is actually present. Teams should confirm where Dante Discovery is deployed, whether the relevant Windows hosts are internet reachable, and whether any management, discovery, or support tooling places the process in a higher-risk network position.
Vendor advisories and the CISA KEV catalogue are the authoritative places to verify whether the issue is currently being exploited and to obtain the patch guidance for the exact build in use. When a vulnerability is in KEV, organisations should treat it as operationally urgent even before they have full certainty about local exploitation.
Because the primary issue is process control, the impact review should also ask what that process can touch: local files, network paths, service accounts, logging locations, and any adjacent software that trusts the process output. A seemingly narrow discovery component can become a useful foothold if it runs with elevated privileges or sits on a host that other systems implicitly trust.
Useful background on why vulnerable software and active exploitation demand rapid triage is available through CVE Program and NIST National Vulnerability Database.
Remediation and detection priorities after exploitation
The first priority is to remove the exploitation opportunity by applying the vendor fix as soon as possible. If patching must wait, reduce the attack surface by limiting host exposure, restricting write access to directories the process can search or load from, and tightening execution permissions on the affected endpoint.
Detection should look for signs of library hijacking rather than only obvious malware names. That includes unusual DLL loads by the affected process, unexpected file creation near the executable, child processes that do not match normal behaviour, and any outbound activity from a discovery service that should be quiet.
After patching, assume compromise review may still be necessary. An attacker who used sideloading may have planted additional persistence, stolen credentials, or altered local artefacts before the vulnerable component was fixed, so the post-patch work should verify the host state rather than assuming the patch alone restored trust.
Risk and Threat Considerations
Because this CVE is already in CISA’s Known Exploited Vulnerabilities catalogue, the main risk is not theoretical weakness but proven abuse of a trusted process-loading path. That means exposure can become a launch point for malware execution, persistence, and broader compromise if defenders treat it as a routine patch item instead of an active intrusion risk.
Failure mechanism: An attacker places or influences a DLL so mDNSResponder.exe loads it during normal execution, turning a trusted discovery process into the execution vector.
Impact: The attacker may gain code execution in the process context, enabling follow-on actions such as lateral movement, credential theft, or host-level persistence.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | CVE remediation requires timely flaw correction for the affected process-control weakness. |
| SI-3 — Malicious Code Protection | DLL sideloading is a malicious-code execution path that warrants runtime code-loading defenses. | |
| CM-7 — Least Functionality | Limiting what the vulnerable process can access reduces the blast radius of sideloading abuse. | |
| Recommendation — Track the flaw, prioritize the affected asset, and deploy the vendor fix under SI-2. Inspect and restrict untrusted module loading with SI-3. Minimize exposed services and writable execution paths under CM-7. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | The term centers on a known exploited vulnerability that needs inventory, prioritization, and remediation. |
| Recommendation — Prioritize this CVE through your vulnerability management workflow and validate remediation. | ||
| MITRE ATT&CK | T1574.001 — DLL Search Order Hijacking | The vulnerability enables DLL sideloading, a known module-hijacking execution technique. |
| Recommendation — Map alerts and hunting logic to DLL search order hijacking activity. | ||
Related resources from NHI Mgmt Group
- When does on-prem data discovery become a governance risk instead of a control?
- When does app discovery automation become a governance control instead of a reporting tool?
- What breaks when discovery, lifecycle, and audit are forced into one control plane?
- Why does agent discovery matter before access control in AI governance?