Skip to content

CVE-2022-23748

mDNSResponder.exe is vulnerable to DLL Sideloading attack.

High Known exploited
Severity
7.8 / 10
High · CVSS 3.1
Exploit chance (EPSS)
8.33%
Chance of exploitation in the next 30 days. Higher than 94.95% of scored vulnerabilities.
Known exploited
Yes
In CISA's catalog since Feb 6, 2025
Weakness
CWE-114 Process Control
CWE-426 Untrusted Search Path
Fix
None yet
No fixed version published
Exploited in the wild. Dante Discovery Process Control Vulnerability (Audinate Dante Discovery). Required action: Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. Due for U.S. federal agencies by Feb 27, 2025.

Description

mDNSResponder.exe is vulnerable to DLL Sideloading attack. Executable improperly specifies how to load the DLL, from which folder and under what conditions. In these scenarios, a malicious attacker could be using the valid and legitimate executable to load malicious files.

How to fix

No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.

Severity breakdown

CVSS 3.1 7.8

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack vector
Local
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-114: Process Control

Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.

How to prevent it
  • Architecture and Design: Libraries that are loaded should be well understood and come from a trusted source. The application can execute code contained in the native libraries, which often contain calls that are susceptible to other security problems, such as buffer overflows or command injection. All native libraries should be validated to determine if the application requires the use of the library. It is very difficult to determine what these native libraries actually do, and the potential for malicious code is high. In addition, the potential for an inadvertent mistake in these native libraries is also high, as many are written in C or C++ and may be susceptible to buffer overflow or race condition problems. To help prevent buffer overflow attacks, validate all input to native calls for content and length. If the native library does not come from a trusted source, review the source code of the library. The library should be built from the reviewed source before using it.

CWE-426: Untrusted Search Path

The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.

How to prevent it
  • Architecture and Design, Implementation: Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.
  • Implementation: When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.
  • Implementation: Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.
  • Implementation: Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory.
  • Implementation: Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of it, while execl() and execv() require a full path.

References

Timeline

  1. Published
  2. Added to CISA's Known Exploited Vulnerabilities catalog
  3. Remediation due for U.S. federal agencies
  4. Last updated by the source
  5. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-46pr-c5wc-xffx
vm2 crypto builtin loads attacker native code through setEngine
Critical Same weakness, CWE-114
GHSA-35c7-w35f-xwgh
Kube-proxy may unintentionally forward traffic
Medium Same weakness, CWE-114
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor