CVE-2026-126644 · Package
NO FIX YET
The authorized_key module in the ansible.posix collection follows a symlink placed at a user's ~/.ssh path when run as root, so it writes or overwrites an authorized_keys file and changes permissions in a directory the attacker chooses. The file is chowned to the unprivileged user, so the impact is integrity and availability damage, such as planting files in /etc/apt/apt.conf.d/, rather than privilege escalation.
first public Nov 12, 2026 · 1 source
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Teams that run Ansible playbooks as root with the authorized_key task against user accounts on systems where local unprivileged users exist. Exposure requires a local attacker who can replace their own ~/.ssh with a symlink before the task runs; hosts with only trusted users and no shared local access are less exposed. The sources do not name a fixed version of ansible.posix.
Not affected if no-authorized-key-task, no-root-ansible-runs, single-user-hosts
Who cares ansible, ansible-posix, linux, provisioning
ansible.posix collection is installed and its version, for example with ansible-galaxy collection list ansible.posix.authorized_key task with become/root against user home directories on shared or multi-user hosts.No fix yet, per the sources.
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.
This page as .md · .json · CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:L
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.