{
"title": "Unpatched DNS Bug Haunts Windows Apps — Here’s How to Protect Your PC from CVE-2022-4904",
"content": "A dormant memory corruption flaw in a core internet library is still lurking inside Windows software more than a year after it was fixed, security experts warn. The bug, catalogued as CVE-2022-4904, sits in the c-ares asynchronous DNS resolver and can crash applications or open the door to remote code execution when software parses a malicious configuration string. Despite a clean, well-documented patch, many programs continue to ship with the vulnerable code.

What Is c-ares and Why Should Windows Users Care?

c-ares is a lean, cross-platform C library that handles non-blocking DNS lookups. It’s the silent engine inside hundreds of programs you likely run on your Windows machine: the curl command-line tool, the Node.js JavaScript runtime, network protocol analyzer Wireshark, and many commercial backup, monitoring, and VPN clients. Every time one of these tools resolves a domain name in the background, there’s a good chance c-ares is doing the work.

Because c-ares is often statically linked—meaning its code gets baked directly into an application’s executable—a vulnerability in the library becomes a vulnerability in every program that bundles it. And since many Windows applications download updates on their own schedule, a patch in the open-source project doesn’t automatically protect end users.

The Bug: A Simple Copy Gone Wrong

The vulnerability lives in a function called aressetsortlist. Administrators can use this function to specify a custom order for DNS results—for example, to prefer certain subnets. The function takes a text string, breaks it into tokens (IP addresses and netmasks), and copies those substrings into small, fixed-size buffers on the stack.

In c-ares versions before 1.19.0, the copying happened without any length check. If an attacker could feed a string with an overly long token into aressetsortlist, the memcpy operation would write past the buffer, corrupting the stack. That corruption reliably crashes the program (denial of service) and, depending on memory layout and compiler protections, can let an attacker hijack execution flow to run arbitrary code.

The fix, applied in early 2023 and shipped in version 1.19.0, adds explicit bounds checks. Now, overly long tokens make the parser return an error (ARESEBADSTR) instead of silently overflowing. The change is minimal, safe, and doesn’t alter normal behavior for legitimate configurations.

Real-World Risk: More Than a Theoretical Threat

At first glance, this might sound like a low-risk issue. After all, aressetsortlist is meant to be called during application setup with a value set by a system administrator, not by random internet input. But software is messy.

  • Home users might run a popular freeware tool that bundles an old c-ares. If that tool ever reads a DNS configuration file from a network share or accepts commands via a web interface, the bug could be triggered. Automatic updates from the software vendor are your best defense, but you can’t know which programs use c-ares without checking.
  • Power users and developers who install Node.js, use curl, or build cross-platform apps are directly exposed. If you compile an application that statically links a vulnerable c-ares (via vcpkg, for example), you’ve baked the bug into your binary. Recompiling with an updated library immediately removes the risk.
  • IT administrators face the broadest impact. Any server appliance, monitoring agent, or internally developed tool that bundles c-ares before 1.19.0 is a potential entry point—especially if it exposes a management UI where configuration strings can be set. A malicious insider or a compromised admin interface could inject a crafted sortlist and crash the service.
Microsoft’s security advisory for CVE-2022-4904 assigns a CVSS score of 8.6 (High), indicating a network-accessible attack vector with high availability impact. Other vendors have echoed the severity, though some contextual assessments lower the urgency by emphasizing the API’s typical trust model. The National Vulnerability Database (NVD) also rates it High.

Nevertheless, real-world exploitability depends entirely on how an application exposes the vulnerable function. The bug itself is the same everywhere; what differs is whether untrusted data can reach it.

A Patch in 2023, Yet the Risk Persists

The timeline is instructive. The flaw was responsibly disclosed in a GitHub issue in late 2022. Within days, the c-ares maintainers reviewed the problem and merged a fix. The commit (9903253c) landed in January 2023, and version 1.19.0, which included the fix, was tagged and released shortly after. Major Linux distributions backported the patch into their package repositories, and downstream projects like Node.js and curl updated their bundled copies.

So why is Windows still affected in 2025? Software distribution is fragmented. Many Windows applications are not managed through a centralized package manager that can force a library update. Vendors of commercial tools often take months to integrate upstream changes, and users rarely check the component versions inside their executables. Statically linked binaries are particularly stubborn: you can’t just swap a DLL; you need a whole new build from the vendor.

What To Do Now: Your Action Plan

The good news is that verifying and fixing this vulnerability is straightforward—once you know where to look.

1. Find Where c-ares Lives on Your Systems

  • On your own Windows PC: If you’re a developer, check your project dependencies. npm ls c-ares will show you the version used by Node.js applications. For other tools, a quick search of the install folder may reveal a c-ares.dll or version strings inside the binary (strings app.exe | findstr c-ares).
  • For IT environments: Use your inventory tool to scan for the c-ares library. Look at software bills of materials (SBOMs) if they exist, or ask vendors directly whether their products ship c-ares and which version.

2. Update or Replace Vulnerable Software

  • If you find c-ares 1.18.x or earlier, check the vendor’s website for an update that bundles 1.19.0 or later (1.20.0, 1.21.0 are also safe).
  • For open-source tools you compile yourself, pull the latest source or update the library through your package manager (vcpkg, Chocolatey, etc.).
  • If a vendor hasn’t released a fix, consider substituting the tool with an alternative that uses a more recent c-ares, or isolate its management interface behind a firewall.

3. Harden Configurations Immediately

Even before you patch, reduce exposure:
  • Restrict which users and systems can change DNS configuration in applications.
  • Apply network segmentation so that management interfaces are not reachable from untrusted networks.
  • Enable compiler-level defenses on your own code: stack canaries (/GS on MSVC), Address Space Layout Randomization (ASLR), and Data Execution Prevention (DEP) are standard on Windows and will make exploitation much harder.

4. Monitor for Signs of Exploitation

After the fix, watch for application logs that show ARESEBADSTR errors—that’s a sign the new bounds checks blocked a malformed string. Before patching, unexplained crashes during configuration changes, especially in applications that log DNS initialization steps, could indicate an attempted overflow.

Beyond This Bug: The Bigger Picture

CVE-2022-4904 isn’t an isolated incident. The c-ares library has seen similar memory safety bugs in the past (e.g., CVE-2020-22217). DNS parsing code, written in memory-unsafe languages like C, remains a rich target for attackers because it’s so widely embedded. Fuzzing—an automated technique that throws random data at an API—helped uncover this bug, but it’s a game of whack-a-mole.

For Windows users and administrators, this episode underscores three hard truths:

  • Dependencies are invisible. Most people don’t know what libraries their software uses. SBOMs are becoming more common, but adoption is slow.
  • Static linking increases risk. When a library is compiled into an executable