CVE-2026-59680 in yast2-users
Summary
by MITRE • 09/01/2026
An OS command injection vulnerability was found in yast2-users. When displaying the "Password Settings" tab of a user, get_password_term() in src/include/users/dialogs.rb read the shadowLastChange and shadowExpire fields with GetString(), which performs no numeric validation, and passed the resulting string to format_days_after_epoch(). That helper interpolated the value into a shell command executed via Ruby backticks without quoting or escaping.
Impact: an administrator who manages users against an external/federated LDAP directory via `yast2 users` triggers root command execution the moment they view or edit that particular user's "Password Settings" tab. No "join domain" or trust setup is required, just browsing/editing one user entry.
This issue affects yast2-users through 5.0.8.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in yast2-users represents a critical OS command injection flaw rooted in improper input validation and unsafe execution of system commands within the Ruby-based YaST framework. The core technical defect resides in the get_password_term() function located in src/include/users/dialogs.rb, which is responsible for processing password expiration data when an administrator accesses the Password Settings tab for a specific user account. This function retrieves values from the shadowLastChange and shadowExpire fields using GetString(), a method that fails to enforce any numeric validation or type checking on the retrieved strings. Consequently, if these LDAP attributes contain maliciously crafted input rather than expected integer values, the raw string data is passed directly to format_days_after_epoch().
The severity of this flaw is amplified by how the output from format_days_after_epoch() is handled in subsequent operations. The helper function interpolates its result into a shell command string without applying any quoting or escaping mechanisms. This interpolated string is then executed via Ruby backticks, which invoke an external system shell to perform the calculation. Because there are no safeguards against special characters such as semicolons, pipes, or ampersands within the input data, an attacker can inject arbitrary OS commands into this execution context. The lack of sanitization means that any non-numeric content in the shadow attributes is treated as part of the command syntax rather than as data to be processed numerically.
The operational impact of this vulnerability is severe because it allows for remote code execution with root privileges under specific but common administrative conditions. An attacker who has compromised or manipulated an external federated LDAP directory can inject malicious payloads into the shadowLastChange or shadowExpire fields associated with any user account managed by yast2-users. When a system administrator logs in and navigates to view or edit that particular user's Password Settings tab, the vulnerable code path is triggered automatically. This action results in the immediate execution of the injected commands as root on the target Linux machine. Notably, this exploitation does not require complex domain join procedures or trust setups; it only requires the administrator to browse or edit a single user entry within the YaST interface, making it highly accessible and difficult to detect through standard monitoring tools that do not inspect LDAP attribute values for command injection patterns.
From a classification perspective, this vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command, commonly known as OS Command Injection. The failure to validate input types corresponds closely to CWE-20 Improper Input Validation, while the execution context involving Ruby backticks highlights risks associated with unsafe system command invocation. In terms of adversary tactics, this flaw facilitates lateral movement and privilege escalation within a network environment where centralized identity management is used but endpoint security controls are insufficiently configured to monitor YaST activity or validate LDAP data integrity before consumption by administrative tools.
Mitigation strategies must address both the immediate technical defect and broader architectural weaknesses. The primary remediation involves patching yast2-users to version 5.0.9 or later, where developers have implemented proper numeric validation for shadowLastChange and shadowExpire fields before they are passed to formatting functions. Until patches can be applied, administrators should restrict access to the YaST user management interface to trusted personnel only and consider disabling direct editing of password expiration settings if feasible. Additionally, organizations relying on federated LDAP directories should implement strict schema enforcement at the directory level to ensure that shadow attributes contain only valid numeric data, thereby preventing malicious payloads from being stored in a form that can be exploited by downstream applications like YaST. Regular auditing of administrative actions and monitoring for unusual shell command executions originating from Ruby processes can also help detect exploitation attempts early.