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.