CVE-2026-11837: Ansible Posix authorized_key Local Privilege Escalation

Technical summary

The ansible.posix authorized_key module contains an insecure file handling vulnerability in its keyfile() function. The vulnerability has two components: (1) the function uses os.chown() rather than os.lchown(), causing it to follow symbolic links and modify the target file's ownership rather than the link itself, and (2) files are opened without the O_NOFOLLOW flag, allowing symlink-based attacks. When an operator executes an authorized_key task with root privileges, an unprivileged local user who has pre-staged symbolic links in their ~/.ssh directory can cause arbitrary files elsewhere on the system to be chown'd to their ownership. This breaks the intended isolation between user and system-owned resources, enabling privilege escalation. The vulnerability is classified under CWE-59 (Improper Link Resolution Before File Access, also known as 'Link Following').

Business impact

This vulnerability enables direct privilege escalation from an unprivileged local account to root on systems running affected Ansible versions. Organizations using Ansible for infrastructure automation—particularly those running authorized_key tasks as part of provisioning, configuration management, or incident response workflows—face a material risk: any administrator who executes an authorized_key task can inadvertently grant root-level file access to a local attacker. This is especially dangerous in shared hosting, multi-tenant, or DevOps environments where developers or build agents may have local account access. Compromise can lead to unauthorized system modifications, data theft, malware persistence, or lateral movement within the infrastructure.

Affected systems

This vulnerability affects the ansible.posix collection's authorized_key module. The vulnerability manifests when: (1) an unprivileged local user has an account on the system, (2) Ansible runs the authorized_key task with elevated (root) privileges, and (3) the module attempts to manage SSH key files in user home directories. Systems where Ansible is deployed for configuration management, infrastructure provisioning, or automated key rotation are at risk. The vulnerability does not require network access to exploit—it is purely local—but requires user interaction in the sense that an administrator must trigger an authorized_key task while the attacker's symbolic links are in place.

Exploitability

Exploitability is straightforward for a local attacker. The attack requires: (1) a valid local user account (low barrier in shared environments), (2) knowledge of when an authorized_key task will run (often predictable in automated systems), and (3) ability to create symbolic links in ~/.ssh (standard file system permissions). The CVSS vector (AV:L/AC:L/PR:L/UI:R) reflects that local access and low complexity are required, but user interaction (UI:R) is needed—specifically, an administrator must run the authorized_key task. In environments with automated, regularly scheduled Ansible runs, the timing becomes less of a barrier. No authentication bypass or complex exploitation technique is required; the vulnerability is a straightforward symlink race condition.

Remediation

Remediation requires updating ansible.posix to a patched version that corrects the authorized_key module's file handling. The fix involves replacing os.chown() with os.lchown() and adding O_NOFOLLOW when opening files, ensuring the module operates directly on the target file and does not follow symbolic links. Additionally, organizations should audit their Ansible automation to identify which tasks run with elevated privileges and restrict execution to trusted operators. Where possible, use Ansible execution environments or containerization to limit local account access on systems running Ansible playbooks. Review logs for any authorized_key tasks executed during the vulnerability exposure window to detect potential exploitation.

Patch guidance

Check the ansible.posix collection release notes and advisory channels for patched versions. Updates will be released through the standard Ansible Galaxy and pip distribution channels. Verify against the vendor advisory for specific version numbers addressing this flaw. Organizations should test patches in a non-production environment before deployment to ensure compatibility with existing playbooks and configurations. Consider coordinating patch deployment with change management processes to minimize disruption to automation workflows.

Detection guidance

Monitor for unauthorized_key tasks running with elevated privileges, particularly any that execute outside of expected maintenance windows or with unexpected frequency. Audit system logs and Ansible execution logs for evidence of chown() operations on unexpected files, especially in critical system directories (e.g., /etc, /root). Check for the presence of symbolic links in user .ssh directories that do not point to expected files—this may indicate an attempted exploitation setup. Host-based file integrity monitoring (FIM) can alert on unexpected ownership changes to sensitive files. In security investigations, correlate Ansible task execution timestamps with sudden privilege level changes or suspicious file ownership modifications.

Why prioritize this

This vulnerability merits prompt attention due to its direct path to root privilege escalation combined with the commonality of local user accounts in production environments. The CVSS 7.3 HIGH score reflects the severity, and although KEV status is not currently assigned, the combination of high impact (compromise of system integrity and confidentiality), low attack complexity, and the widespread use of Ansible in infrastructure automation makes this a strong candidate for rapid patching. Organizations managing many systems via Ansible should prioritize this in their patch queue, especially if running playbooks as root.

Risk score, explained

The CVSS 3.1 score of 7.3 (HIGH) is derived from: Attack Vector: Local (AV:L)—requires local system access; Attack Complexity: Low (AC:L)—no special conditions needed beyond predictable task execution; Privileges Required: Low (PR:L)—an unprivileged local account suffices; User Interaction: Required (UI:R)—an administrator must trigger the authorized_key task; Scope: Unchanged (S:U)—the impact is confined to the affected system; Confidentiality: High (C:H)—attacker can read sensitive files after escalation; Integrity: High (I:H)—attacker can modify critical files; Availability: High (A:H)—attacker can delete or disable services. The overall score reflects a serious vulnerability that an insider or low-privileged local user can exploit reliably to gain full system control, but that does require administrator action to trigger.

Frequently asked questions