REDHAT-BUG-2571732: Low severity vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ansible.posixto a version that resolves this vulnerability.Patch CVE-2026-11837
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 the authorized_key task as root. This is described as the typical deployment pattern.
What does an attacker need to do to exploit it?
The attacker needs local unprivileged access and must replace their ~/.ssh directory with a symlink to a root-owned directory of their choosing. A subsequent root-run authorized_key task resolves operations through that symlink.
What is the impact if the condition is triggered?
The task can create or overwrite authorized_keys in the attacker-selected root-owned target directory. It can also change permissions on that target directory to 0700 because chmod follows the parent-directory symlink.
How can operators check for the vulnerable condition before running the task?
Check whether the target user's ~/.ssh path is a symlink rather than a real directory, particularly if it resolves to a root-owned directory. The remaining issue affects parent-directory symlinks even though final-component symlink protections were added.