CVE-2026-75038 in LACT
Summary
by MITRE • 08/25/2026
UNIX symbolic link (symlink) following vulnerability in ilya-zlobintsev/LACT allows for local denial-of-service. This issue affects LACT: through 0.10.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified within the Linux Advanced Control Tool, specifically versions up to and including 0.10.0 developed by ilya-zlobintsev, represents a classic local denial-of-service condition rooted in improper handling of symbolic links. This software serves as a graphical interface for managing NVIDIA GPU settings on Linux systems, allowing users to configure performance profiles, fan speeds, and power limits. The core technical flaw lies in the application's failure to validate or restrict file paths when processing configuration files or user inputs that involve symbolic link references. By exploiting this oversight, an attacker with local access can manipulate the system into following a symlink to a target location outside of intended boundaries, leading to unintended file operations such as overwriting critical system configurations or consuming excessive resources through recursive linking loops.
From a technical perspective, this issue is categorized under CWE-59 Improper Link Resolution Before File Access, commonly known as a symbolic link following vulnerability. When the application attempts to read or write configuration data, it does not sufficiently verify that the resolved path remains within an expected directory structure. This lack of canonicalization allows for path traversal attacks where relative paths containing dot-dot sequences are used to escape sandboxed directories. In the context of LACT, this could result in the modification of system-wide NVIDIA driver configurations or other sensitive files if the application runs with elevated privileges, although even without root access, the ability to disrupt local services constitutes a significant security risk. The vulnerability enables an attacker to cause a denial-of-service by forcing the application into infinite loops or crashing it through malformed input that triggers unexpected behavior in file handling routines.
The operational impact of this vulnerability is primarily localized but can have broader implications depending on the deployment context. For individual users, exploiting this flaw could lead to the corruption of GPU configuration files, resulting in system instability, loss of custom performance settings, or complete failure of the graphical interface to launch properly. In multi-user environments or systems where LACT might be integrated into automated management scripts, an attacker with local shell access could degrade system reliability by repeatedly triggering crashes or resource exhaustion conditions. While direct remote code execution is not indicated in this specific report, the ability to manipulate file states locally can serve as a stepping stone for privilege escalation if combined with other vulnerabilities that rely on predictable configuration files being present and writable.
Mitigation strategies should focus on both immediate remediation and long-term secure coding practices. The most effective solution is to upgrade LACT to version 0.10.1 or later, where the developer has presumably addressed this path validation logic. For systems unable to update immediately, administrators can implement file integrity monitoring tools such as AIDE or Tripwire to detect unauthorized changes to configuration directories associated with NVIDIA drivers. Additionally, restricting user permissions on these specific directories using mandatory access control frameworks like SELinux or AppArmor can limit the blast radius of any exploitation attempt by preventing non-privileged processes from writing to critical paths regardless of symlink manipulation. Developers should also adopt strict input validation techniques that resolve all symbolic links before performing file operations and ensure that only whitelisted absolute paths are accepted for configuration management tasks, thereby aligning with OWASP guidelines on path traversal prevention.