Bug 2571732 (CVE-2026-126644)

Summary: CVE-2026-126644 ansible.posix: authorized_key module follows a parent-directory symlink allowing writes outside the intended directory
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A link-following flaw was found in the authorized_key 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 follow_symlinks=False and O_NOFOLLOW in _safe_open_write()). 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 authorized_key task as root (a common provisioning pattern), the module resolves its path operations through the symlink: atomic_move() writes the temporary file in the symlink target and renames it to <target>/authorized_keys, 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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-11-11 14:34:03 UTC 
The fix for CVE-2026-11837 (PR #760) addresses the final-component symlink attack by replacing os.chown() with follow_symlinks=False and adding O_NOFOLLOW to _safe_open_write(). 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 authorized_key task as root (the typical deployment pattern), the module resolves all path operations through the symlink and operates inside the target directory: atomic_move() (line 532) writes a temp file in dirname(keysfile) — the symlink target — then renames it to <target>/authorized_keys, creating or overwriting an authorized_keys file in the attacker-chosen root-owned directory; os.chmod(sshdir, 0o700) (line 374) has no follow_symlinks argument and follows the symlink, changing permissions on the target directory to 0700; os.chown(keysfile, uid, gid, follow_symlinks=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 _assert_symlink 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.