Description

A flaw was found in the ansible-core user module. When generate_ssh_key is enabled, User.ssh_key_gen() guards the key files against symlinks but checks the ~/.ssh directory only with os.path.exists(). An unprivileged user on a managed node who replaces their ~/.ssh with a symlink to an existing root-writable directory causes the privileged module to write the generated key pair through the symlink and then chown both files to that user. Because such files can be dropped into directories processed by schedulers (e.g. /etc/cron.daily) or dynamic MOTD (/etc/update-motd.d), the user can escalate to root on the managed node. This is an incomplete fix of CVE-2024-9902.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.7",
  "pubDate": "2026-11-06T06:16:42.243Z",
  "pubdate": "2026-11-06T06:16:42.243Z",
  "executiveSummary": "A symlink race condition vulnerability exists within the ansible-core user module's SSH key generation process, specifically when the generate_ssh_key parameter is enabled.\nThis flaw is an incomplete mitigation of CVE-2024-9902 and affects the module's ability to safely manage SSH key creation on managed nodes.\nAn unprivileged local attacker can exploit this condition to achieve privilege escalation to root.\nThe vulnerability occurs because the User.ssh_key_gen() function fails to adequately secure the target directory from symlink-based redirection before performing file operations with elevated privileges.\nBy manipulating the ~/.ssh directory, an attacker can trick the privileged ansible-core process into writing SSH keys into sensitive system locations.\nSuccessful exploitation allows for the placement of arbitrary files or the modification of ownership of sensitive system files, leading to full system compromise.\nThis vulnerability is restricted to the managed node environment and requires local access, though it represents a critical security oversight in privileged task execution.",
  "technicalDetails": "The vulnerability resides in the ansible-core user module, specifically within the User.ssh_key_gen() function, which is responsible for generating and configuring SSH keys when the generate_ssh_key flag is active.\nThe root cause is a race condition arising from insufficient symlink verification. While the module attempts to guard key files against symlinks, it verifies the existence of the ~/.ssh directory using the non-atomic os.path.exists() method.\nBecause os.path.exists() does not distinguish between a directory and a symlink pointing to a directory, an unprivileged attacker can replace their ~/.ssh directory with a symbolic link pointing to a root-writable system directory (e.g., /etc/cron.d/ or /etc/update-motd.d/) immediately after the check is performed but before the file write operation occurs.\nThe attack flow proceeds as follows: 1) An attacker monitors or predicts the execution of an Ansible playbook that invokes the user module with key generation. 2) The attacker replaces the target ~/.ssh path with a symlink targeting a sensitive system directory. 3) The privileged ansible-core module initiates the key generation process. 4) The module passes the insecure existence check. 5) The module writes the generated SSH public/private key pair to the location defined by the symlink, effectively writing into a system-critical directory. 6) The module subsequently performs an os.chown() call on these files to transfer ownership to the attacker-controlled user.\nBy writing files into directories such as /etc/cron.daily or /etc/update-motd.d, the attacker can force the execution of arbitrary commands with root privileges when the scheduler or dynamic MOTD service processes these files.\nThe vulnerability is characterized by a time-of-check to time-of-use (TOCTOU) logic error. Because the ansible-core module runs with elevated privileges on the managed node, it implicitly trusts the destination directory. The final chown operation acts as a secondary vector, potentially allowing an attacker to change the ownership of existing sensitive files if the path manipulation is orchestrated correctly.\nThis issue is identified as an incomplete fix for CVE-2024-9902, indicating that previous attempts to address symlink handling in the user module were insufficient to prevent this bypass.\nExploitation requires no network exposure but necessitates local user access to the managed node and the ability to trigger the specific ansible-core module execution."
}