Background

During my ethical hacking studies, I was analyzing Windows applications for common privilege escalation issues. One of the techniques I focused on was DLL search order hijacking, a well known issue that, despite its age, still appears in modern software.

While testing TR VISION HOME (Thermalright) in a local lab environment, I identified a vulnerability that allows privilege escalation through insecure DLL loading. This issue has since been assigned CVE-2026-4255.

How it works

What makes this case interesting is not the complexity of the vulnerability, but how easily it can be exploited once the conditions are in place.

At its core, the application loads a DLL named Ftd2xx.dll without specifying a fixed or trusted path. Instead, it relies on the default Windows DLL search order. This means that when the application attempts to load the library, Windows will search through a sequence of directories, including locations that are writable by a standard user. From a functional perspective, this behavior is expected. From a security perspective, it introduces an implicit trust in locations that should not be trusted.

The following screenshot illustrates how the application resolves Ftd2xx.dll at runtime. Using Process Monitor, we can observe that the application searches through multiple directories, including user-controlled paths.

This confirms that the DLL search order is not restricted to trusted locations and that unsecured directories are part of the resolution process.

Exploitation

If an attacker places a malicious DLL with the same name in one of these directories, the application will load that file instead of the legitimate one. Because the application runs with administrative privileges, any code inside the malicious DLL will inherit those privileges. At that point, the boundary between a low-privileged user and full system access effectively disappears.

In this example, a crafted Ftd2xx.dll is placed inside a writable directory that is part of the system PATH, such as a Python installation directory.

This demonstrates how trivial it is for an attacker to introduce a malicious library into a location that will be trusted by the application during DLL resolution.

From an attacker's perspective, exploitation is straightforward. There is no need for advanced techniques or complex payloads. The attacker simply abuses how the application resolves its dependencies. By placing a crafted Ftd2xx.dll in a directory included in the user PATH, execution becomes a matter of waiting for the application to start and load the wrong file.

Once the DLL is executed, the attacker effectively gains administrative access to the system. This opens the door to a wide range of follow-up actions, such as installing additional tooling, modifying system configurations, accessing sensitive data, or preparing for lateral movement within a network. Although the vulnerability requires local access, it rarely exists in isolation and can be used as part of a broader attack chain.

In this scenario, a malicious DLL was created to demonstrate the impact by making the target system initiate a connection to an attacker-controlled interface. Once executed, the payload establishes this connection, confirming successful exploitation. For demonstration purposes, the behavior was made visible, however, in a real-world scenario, this would typically run silently in the background without the user ever knowing it is happening.

The following screenshot demonstrates that the compromised session is running with elevated privileges. This is evident from the whoami /groups output, which shows membership in high-privilege groups such as BUILTIN\Administrators and indicates a High Mandatory Level. These indicators confirm that the malicious DLL was executed within the context of an application running with administrative rights. With this level of access, arbitrary commands can be executed on the system, enabling full control over its behavior and resources.

The root cause of the issue lies in how the application handles trust. By relying on the default DLL search order and not enforcing strict control over where dependencies are loaded from, it allows untrusted code to become part of its execution flow. This aligns with CWE-829, where functionality is included from an untrusted control sphere.

Impact

This vulnerability enables privilege escalation from a standard user to an administrator. In real world environments, this can lead to full system compromise, increased attack surface within the network, and access to sensitive information.

Preventing this type of issue is relatively straightforward in theory, but requires consistency in practice. Applications should load DLLs from explicitly defined, trusted locations rather than relying on search order behavior. Validating the integrity of loaded libraries and avoiding unnecessary elevated privileges further reduces risk.

Conclusion

This case highlights something that comes up frequently during testing. Many impactful vulnerabilities are not new, but the result of known issues being reintroduced through small implementation decisions. DLL hijacking has been understood for years, yet it remains relevant because it is easy to overlook and difficult to detect without targeted analysis.

Disclosure timeline

A proof-of-concept demonstrating the issue is available on GitHub: github.com/Ard33/CVE-2026-4255