CVE-2026-11837: Ansible Privilege Escalation Vulnerability

CVE-2026-11837 Overview

CVE-2026-11837 is a local privilege escalation vulnerability in the ansible.posix collection's authorized_key module. The module's keyfile() function calls os.chown() instead of os.lchown() and opens files without the O_NOFOLLOW flag when managing SSH authorized keys. An unprivileged local user can pre-stage symbolic links inside their ~/.ssh directory to redirect file ownership changes to arbitrary paths. When an operator executes the authorized_key task as root, the module follows the attacker-controlled symlink and changes ownership of sensitive system files. This vulnerability is classified under [CWE-59] Link Following.

Critical Impact
A local unprivileged user can escalate to root by tricking a privileged Ansible run into transferring ownership of arbitrary files via symlink redirection.

Affected Products

ansible.posix collection — authorized_key module
Red Hat distributions shipping the affected ansible.posix collection
Ansible deployments running the authorized_key task with elevated privileges against managed nodes

Discovery Timeline

2026-06-10 - CVE-2026-11837 published to NVD
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-11837

Vulnerability Analysis

The authorized_key module manages SSH authorized_keys files on remote hosts. Its keyfile() helper function ensures the target user's ~/.ssh directory and authorized_keys file exist with correct ownership and permissions. The function performs two unsafe operations on attacker-reachable paths. First, it invokes os.chown(), which dereferences symbolic links, rather than os.lchown(), which operates on the link itself. Second, it opens files without the O_NOFOLLOW flag, allowing the open call to traverse symlinks placed in the target directory.

When an operator runs the task as root against a host where the destination user is untrusted, the module touches paths inside that user's home directory. Any symlink the user planted before the run is followed by the privileged process. The result is that ownership of arbitrary system files — such as /etc/shadow, /etc/sudoers.d/, or a SUID binary — can be transferred to the unprivileged user, who then modifies them to gain root.

Root Cause

The root cause is unsafe filesystem handling on a path that crosses a privilege boundary. The module trusts the layout of ~/.ssh while executing as root. Because os.chown() and open() without O_NOFOLLOW follow symlinks, the privileged process honors filesystem objects controlled by the unprivileged target user. This is a classic link-following weakness [CWE-59].

Attack Vector

The attacker needs an existing local account on the managed node and prior knowledge that an operator will run the authorized_key module against that account. The attacker replaces ~/.ssh or ~/.ssh/authorized_keys with a symbolic link pointing at a sensitive target file. When the Ansible task runs as root, the chown call follows the link and reassigns ownership of the target to the attacker's UID. User interaction by the operator is required to trigger the privileged run.

No verified public exploit code is available. Technical details are described in the Red Hat CVE-2026-11837 Advisory and the associated Red Hat Bug Report #2487424.

Detection Methods for CVE-2026-11837

Indicators of Compromise

Symbolic links inside ~/.ssh directories of unprivileged users pointing to files outside the home directory, such as /etc/shadow, /etc/sudoers, or /etc/sudoers.d/*.
Unexpected ownership changes on system files where the new owner matches a non-root local user account.
Ansible run logs showing authorized_key tasks executed as root against accounts owned by untrusted users.

Detection Strategies

Audit filesystem activity for chown syscalls executed by root against paths under user-writable directories, correlated with Ansible process ancestry.
Compare expected ownership of critical system files against current state and alert on drift, particularly when the new UID is a non-system account.
Review Ansible controller logs for authorized_key invocations and validate that target users are trusted.

Monitoring Recommendations

Enable Linux audit rules on chown, fchown, lchown, and openat syscalls invoked by privileged processes touching user home directories.
Monitor for creation of symbolic links inside ~/.ssh whose targets resolve outside the user's home directory.
Track Ansible playbook execution telemetry and alert when authorized_key runs with become: yes or as root against multi-tenant systems.

How to Mitigate CVE-2026-11837

Immediate Actions Required

Update the ansible.posix collection to the patched release referenced in the Red Hat CVE-2026-11837 Advisory.
Avoid running the authorized_key module as root against accounts controlled by untrusted users until patched.
Inspect target hosts for malicious symlinks inside user ~/.ssh directories before executing privileged playbooks.

Patch Information

Red Hat tracks the fix and downstream package updates in the Red Hat CVE-2026-11837 Advisory and Red Hat Bug Report #2487424. The fix replaces os.chown() with os.lchown() and adds O_NOFOLLOW to file open operations so the module no longer follows attacker-controlled symbolic links.

Workarounds

Run the authorized_key task using become_user set to the target account rather than root, so the operation executes with the same privileges as the file owner.
Pre-create and validate the ~/.ssh directory and authorized_keys file with correct ownership and a sticky-permission policy before invoking the module.
Restrict use of the authorized_key module to trusted user accounts and review playbooks that elevate privileges across multi-tenant hosts.

bash

# Configuration example: update the ansible.posix collection
ansible-galaxy collection install --upgrade ansible.posix

# Verify installed version
ansible-galaxy collection list ansible.posix