Symbolic Name not Mapping to Correct Object

This vulnerability occurs when a program uses a fixed symbolic name (like a constant or identifier) to refer to an object, but that name can later point to a different, unintended object during execution.

At its core, this flaw is a mismatch between a developer's assumption and the runtime environment's behavior. Developers often use symbolic names—think of environment variables, registry keys, fixed file paths, or named constants—believing they reliably point to one specific resource or piece of data. However, if the system or application state changes, that same symbolic name can resolve to a completely different object. This breaks the program's logic and can lead to dangerous scenarios where the code processes untrusted data thinking it's something safe. The risk emerges because the symbolic reference is not securely bound to its intended target. For example, an application might use a constant like `CONFIG_FILE` pointing to `/etc/app/config.json`. If an attacker can create a symlink with that same name or modify environment variables, the program could be tricked into loading a malicious file. To prevent this, developers should avoid relying on unvalidated symbolic mappings. Instead, use direct object references, verify the object's integrity before use, or implement proper locking mechanisms to ensure the binding between name and object cannot be hijacked.