CVE-2026-126644: Ansible.posix: authorized_key module follows a parent-directory symlink allowing writes outside the intended directory
A link-following flaw was found in the authorizedkey module of the ansible.posix collection, residual to the fix for CVE-2026-11837. That fix guards only the final path component (os.chown with followsymlinks=False and ONOFOLLOW in safeopenwrite()). When an unprivileged local user replaces their ~/.ssh directory with a symlink to a directory they do not own, and an operator subsequently runs the authorizedkey task as root (a common provisioning pattern), the module resolves its path operations through the symlink: atomicmove() writes the temporary file in the symlink target and renames it to <target>/authorizedkeys, creating or overwriting a file in the attacker-chosen directory, and os.chmod(sshdir, 0o700) follows the symlink and changes the target directory's permissions. The written file is chowned to the unprivileged user, so this is not a privilege escalation, but it allows an attacker to create or overwrite files (for example in /etc/apt/apt.conf.d/, which APT reads regardless of file ownership) to cause integrity and availability impacts.
Other sources
The fix for CVE-2026-11837 (PR #760) addresses the final-component symlink attack by replacing os.chown() with followsymlinks=False and adding ONOFOLLOW to safeopenwrite(). Both protections operate on the last path component only; the parent-directory symlink case is not guarded and remains exploitable on 2.2.2. When an unprivileged local user replaces their ~/.ssh directory with a symlink to any root-owned directory, and an operator subsequently runs the authorizedkey task as root (the typical deployment pattern), the module resolves all path operations through the symlink and operates inside the target directory: atomicmove() (line 532) writes a temp file in dirname(keysfile) — the symlink target — then renames it to <target>/authorizedkeys, creating or overwriting an authorizedkeys file in the attacker-chosen root-owned directory; os.chmod(sshdir, 0o700) (line 374) has no followsymlinks argument and follows the symlink, changing permissions on the target directory to 0700; os.chown(keysfile, uid, gid, followsymlinks=False) operates on the final component without following it, but by that point the file has already been written inside the target directory. This was discussed during PR #760 review (an assertsymlink guard on sshdir was proposed but would require a force option to preserve existing behaviour; the final policy was "keep existing behaviour except for the CVE fix"). This is not a privilege escalation: the written file is chowned to the unprivileged user; /root/.ssh/ is rejected by sshd StrictModes and /etc/sudoers.d/ by sudo ownership/syntax checks (both tested non-exploitable). The demonstrated impact is integrity/availability, strongest case /etc/apt/apt.conf.d/ where APT reads all files regardless of name or ownership. Confirmed affected: ansible.posix 2.2.2 (latest). Reporter: Rick Kuipers (@rskuipers); reporter noted parts of the write-up were AI-generated but states he reproduced the behaviour.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems are exposed when an unprivileged local user can replace their ~/.ssh directory with a symlink and an operator later runs an ansible.posix authorized_key task as root for that user. This is particularly relevant to root-run provisioning workflows that manage users' authorized_keys files.
What does an attacker need to exploit it?
The attacker needs local access as an unprivileged user and must be able to replace their ~/.ssh directory with a symlink to an attacker-chosen directory they do not own. They also need a privileged operator to subsequently run the affected authorized_key task.
What is the impact of successful exploitation?
The module can create or overwrite authorized_keys in the symlink target and can change that target directory's permissions to 0700. The resulting file is owned by the unprivileged user, so the described behavior is not a privilege escalation, but it can affect integrity and availability, such as by writing into an APT configuration directory.