---
id: "CVE-2026-126644"
page: "https://infrastack.ai/live/CVE-2026-126644"
kind: "vulnerability"
aliases: ["CVE-2026-126644"]
title: "ansible.posix: authorized_key module follows symlinked ~/.ssh when run as root"
severity: "low"
cvss: 3.9
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["ansible", "ansible-posix", "linux", "package", "provisioning"]
not_affected_if: ["no-authorized-key-task", "no-root-ansible-runs", "single-user-hosts"]
published_at: "2026-11-12T11:17:11+00:00"
first_seen_at: "2026-11-12T11:38:05+00:00"
updated_at: "2026-11-12T11:40:07+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-126644", "first_seen_at": "2026-11-12T11:38:05+00:00"}]
exploit_sources: []
---

# ansible.posix: authorized_key module follows symlinked ~/.ssh when run as root

Link for people: https://infrastack.ai/live/CVE-2026-126644 (this .md is for agents)

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.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the `ansible.posix` collection is installed and its version, for example with `ansible-galaxy collection list ansible.posix`.
- Look for playbooks that run the `authorized_key` task with become/root against user home directories on shared or multi-user hosts.

## Timeline

- 2026-11-12T11:38:05+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-126644

## From 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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_