Use of Incorrectly-Resolved Name or Reference

A name or reference (a hostname, a file path, an object identifier) resolves to something other than what the application intended, because the resolution logic itself is flawed - ambiguous relative paths, a hostname that resolves differently depending on resolver state, or an identifier lookup that matches more broadly than intended. Distinct from subdomain takeover (which is about unclaimed DNS records) - this is about resolution logic itself picking the wrong target even when every referenced name is properly claimed.

Confirming a specific resolution-logic flaw requires understanding exactly how the target application performs the resolution in question and identifying the case where it picks the wrong target - an application-specific investigation rather than a generic signature.

Manual testing and source-level review of the specific resolution logic in question (path resolution, hostname resolution, identifier lookup), probing with deliberately ambiguous inputs.

Tip: This is typically found through installer/updater-specific review — checking exactly how the program resolves library paths, temp file names, and update sources — since the vulnerable behavior is in resolution logic that doesn't show up in normal application testing at all.

Real-World Impact

This family covers a subtle but recurring pattern: a program resolving a name, path, or reference to an actual resource, a file, a library, a function, a URL, in a way an attacker can influence, causing it to load or execute something other than what was intended. Untrusted search-path issues (DLL/library hijacking) let an attacker place a malicious library somewhere earlier in the search order than the legitimate one. Insecure temporary files created predictably or world-writably can be swapped out from under the program that created them. Downloading code without verifying its integrity trusts the delivery channel completely, with no check that what arrived is what was actually published.

The severity ceiling across this family is typically code execution, since the end result of each pattern is the program loading and running something the attacker chose rather than what the developer intended.

These bugs are especially common in installers, updaters, and plugin/extension-loading systems specifically because those components inherently need to resolve and load external code as part of their normal function — which is exactly the operation this whole family exploits.

Prevention and Secure Design

Preventing Use of Incorrectly-Resolved Name or Reference takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Use absolute paths and explicit references, never rely on search-path resolution for anything security-relevant. Load libraries, executables, and includes by fully-qualified path rather than trusting a search order that could be manipulated.

Verify integrity before executing or loading anything obtained externally. A cryptographic signature check on downloaded code, plugins, or updates ensures what arrived is actually what was published, closing off tampering during delivery.

Create temporary files securely. Use the platform's secure temp-file API (which handles unpredictable naming and correct permissions) rather than a predictable name in a world-writable location.

Restrict what a plugin/extension-loading system will load. An explicit allowlist of trusted sources or signed packages prevents the loading mechanism from being pointed at an attacker-supplied alternative.

Audit installers and updaters specifically for this pattern. These components are disproportionately likely to contain this bug family because resolving and loading external code is their core function — review them with that specific risk in mind.