CVE-2026-55062 in uniget
Summary
by MITRE • 09/17/2026
uniget is a universal installer and updater for (container) tools. Prior to 0.27.6, the hooks edit command in cmd/uniget/hooks.go concatenates an unvalidated hook filename with the selected hooks directory, allowing parent-directory components to escape that directory. The resulting path is passed to the configured editor, which can access or modify files outside the hooks directory with the privileges of the uniget process account. This issue is fixed in version 0.27.6.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the uniget utility represents a critical path traversal flaw inherent in its hook management subsystem. Uniget functions as a universal installer and updater for container-related tools, automating various operational tasks through configurable hooks. The specific defect resides in the command-line interface handler located at cmd/uniget/hooks.go, specifically within the edit functionality. When a user invokes this command to modify an existing hook configuration, the application constructs a file path by concatenating the provided hook filename directly with the designated hooks directory path without performing any validation on the input string. This lack of sanitization allows for the injection of parent-directory traversal sequences, such as dot-dot-slash characters, into the filename argument.
By exploiting this architectural oversight, an attacker or malicious actor can manipulate the resulting file path to reference locations outside the intended sandboxed hooks directory. The operational mechanism relies on the fact that uniget passes the constructed absolute path directly to a user-configured external editor application. Because the operating system resolves these traversal sequences before the editor launches, the text editor opens files located in arbitrary directories on the filesystem rather than restricting access strictly to the hook configuration folder. This behavior effectively bypasses any intended isolation boundaries established by the tool's design for managing its own configuration data.
The security implications of this flaw are significant due to the privilege context under which uniget typically operates. If the utility is executed with elevated privileges, such as root or administrator rights, an attacker can leverage this path traversal to read sensitive system files that would otherwise be inaccessible, leading to unauthorized information disclosure. Furthermore, by modifying configuration files in critical system directories via the editor interface, an attacker could potentially alter system settings, inject malicious scripts into startup processes, or compromise other applications managed by uniget. This constitutes a classic directory traversal vulnerability where input validation failures lead to out-of-bounds file access.
From a classification perspective, this issue aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as the application fails to restrict pathname resolution within expected boundaries. In terms of offensive security frameworks, it maps to ATT&CK technique T1083: File and Directory Discovery, allowing for reconnaissance, and potentially T1546: Event Triggered Execution if modified system files trigger malicious actions upon subsequent reboots or service restarts. The vulnerability highlights the risks associated with passing unsanitized user input directly into external process invocations without rigorous path normalization checks.
To mitigate this risk, it is imperative to upgrade uniget to version 0.27.6 or later, where the developers have implemented proper validation logic to sanitize hook filenames and prevent directory traversal sequences from altering the target file location. In environments where immediate upgrading is not feasible, administrators should enforce strict input filtering on any wrapper scripts that invoke the hooks edit command and ensure that uniget runs with the minimum necessary privileges to limit the blast radius of potential exploitation. Additionally, implementing mandatory access controls or sandboxing mechanisms can provide an additional layer of defense by restricting file system write permissions for the user account executing the tool.