How a Maintenance Tool Can Become a SYSTEM-Level Trap

In industrial environments, the most dangerous code is not always the code that crosses the network. Sometimes it is a trusted utility on a privileged workstation, quietly asking Windows to find a DLL by name. In this case, that ordinary behavior became the center of two vulnerabilities that can let a local attacker load malicious code into an elevated process if an administrator later launches the tool.

Fast Facts

• Two vulnerabilities were assigned CVE-2026-9633 and CVE-2026-9634.
• The issue is tied to incorrect default permissions on directories used in the DLL search path.
• A malicious DLL in a writable location may be loaded when the tool runs with administrator rights.
• The advisory rates the flaws as High severity, not Critical.
• Version 10.01.00 is the vendor fix, and CISA says no known public exploitation has been reported.

The mechanics behind the risk

The technical pattern is a classic one: DLL search-order abuse, sometimes called binary planting or DLL hijacking. When a Windows program loads a library without pinning it to a full path, the operating system checks a series of locations. If one of those directories is writable by a standard user, the attacker may be able to place a lookalike DLL there.

That matters here because the affected Rockwell utility, used to configure redundancy modules, can run with elevated privileges. If an administrator later opens the program, Windows may load the attacker-controlled DLL into that privileged session. The result is local privilege escalation on the host running the tool, not a remote compromise of the product over the internet. CISA specifically says the issue is not remotely exploitable.

Public information does not establish that any customer system was compromised. The available evidence supports a risk analysis, not a claim of observed takeover in the wild.

Why defenders should care

This kind of flaw is easy to underestimate because it does not rely on exotic exploit code or a network-facing service. It depends on two much more ordinary conditions: a writable directory and a privileged launch. In practice, that makes workstation hardening, directory permissions, and operator habits part of the security control plane.

From a defensive perspective, the immediate priority is upgrading to the corrected version. The broader lesson is to treat engineering and maintenance tools as high-value endpoints. If a utility used in industrial workflows can be influenced through the local loader, then patching alone is only part of the answer. Least privilege, strict file permissions, and careful DLL-loading design reduce the chance that a routine admin action becomes a privilege-escalation event.

Conclusion

This case is a reminder that in OT and industrial software, the attack surface often lives on the host itself. A network may be segmented and a controller may be unreachable, yet a single Windows loader decision can still hand an attacker elevated code execution. The lesson is simple: secure the maintenance path as aggressively as the production network.

WIKICROOK

• DLL hijacking: An attack that abuses how Windows searches for dynamic-link libraries to load malicious code.
• Privilege escalation: The act of gaining higher access rights than a user should normally have.
• CWE-276: A weakness category for incorrect default permissions on files or directories.
• Safe DLL Search Mode: A Windows setting that changes DLL lookup order to reduce search-path abuse.
• Least privilege: A security principle that gives users and processes only the permissions they need.