Quick Look: CVE-2026-11837 — Symlink Following in Ansible Posix authorized_key Enables Local Privilege Escalation

Introduction

A classic symlink-following flaw in the Ansible Posix authorized_key module lets any unprivileged local user hijack ownership of arbitrary system files when an operator runs an SSH key management playbook as root. Red Hat Enterprise Linux holds 43.1% of the enterprise Linux server market, and Ansible is the de facto standard for infrastructure automation in those environments. CVE-2026-11837 therefore reaches a significant portion of the enterprise IT operations that rely on automated SSH key provisioning.

Technical Information

The Vulnerable Component

The vulnerability is in the keyfile() function of the ansible.posix collection's authorized_key module, in the file plugins/modules/authorized_key.py. This function makes sure that a user's ~/.ssh directory and authorized_keys file exist with the correct ownership and permissions. It calls os.chown(sshdir, uid, gid) on the SSH directory and os.chown(keysfile, uid, gid) on the key file itself.

Root Cause: os.chown() Follows Symlinks

This is a textbook CWE-59 (Improper Link Resolution Before File Access) violation. Python's os.chown() follows symbolic links: if the path argument is a symlink, the ownership change applies to the symlink's target, not to the symlink itself. The symlink-safe alternative, os.lchown(), operates on the link itself and does not follow it to the target.

The module also opens files without the O_NOFOLLOW flag. When open() receives O_NOFOLLOW, the kernel returns an ELOOP error if the path resolves to a symbolic link, so the attack is blocked at the moment the file is opened. Without this flag, both the open and the chown operations blindly follow attacker-controlled symlinks.

Attack Flow

The exploit is straightforward and takes very little skill:

Step 1: Pre-staging. An unprivileged local user creates a symbolic link in their own ~/.ssh directory that points to a sensitive system file. For example:

ln -s /etc/shadow ~/.ssh/authorized_keys

The attacker has full control over their own home directory, so creating this symlink needs no elevated privileges.

Step 2: Trigger. An Ansible operator runs a playbook with an ansible.posix.authorized_key task that targets the user's account. This is the standard way to manage SSH keys, and these tasks usually run as root so they can write to any user's home directory.

Step 3: Ownership Redirection. The module's keyfile() function calls os.chown() on ~/.ssh/authorized_keys. Because os.chown() follows the symlink, ownership of /etc/shadow (or whatever the symlink points to) changes to the unprivileged user's UID and GID.

Step 4: Privilege Escalation. Now owning /etc/shadow, the attacker can read password hashes, replace them, or add new root credentials. The same technique works against /etc/passwd, cron directories, or any other file where ownership grants meaningful access.

Vulnerability Characteristics

Why This Pattern Matters

This is not an isolated incident. The same root cause, using chown instead of lchown and omitting O_NOFOLLOW, appeared in at least two other 2026 CVEs: CVE-2026-31979 in Akamai's Himmelblau project and CVE-2026-41091 in Microsoft Defender's Malware Protection Engine. The fix for CVE-2026-31979 explicitly "updates write_bytes_to_file to include the O_NOFOLLOW flag in the open() system call" so that "the kernel will now refuse to open a path that [is a symlink]." The same remediation applies directly here.

The tension with Ansible stands out: the platform exists to run privileged operations across fleets of hosts, and the authorized_key module is meant to run as root. So the vulnerable code path is not an edge case. It is the expected operational mode.

Affected Systems and Versions

The vulnerability affects the ansible.posix collection's authorized_key module. The current documented version of the collection is 2.2.0. The vendor has not published specific affected version ranges as of June 10, 2026.

A system is vulnerable when all of these conditions are met:

1. The ansible.posix collection is installed (standalone or as part of Red Hat Ansible Automation Platform)
2. The authorized_key module is used in playbooks
3. The playbook tasks run as root (the typical configuration)
4. Unprivileged users have local shell access to managed hosts

The security advisory RHSA-2026:13508 specifically references Red Hat Ansible Automation Platform 2.6. Tenable has published a Nessus plugin (ID 312090) for detecting vulnerable installations on RHEL 10 and RHEL 9.

Vendor Security History

The Ansible product family has accumulated 328 CVEs according to OpenCVE, which reflects the complexity of an automation platform that runs privileged operations across diverse environments. Recent notable Ansible CVEs include:

These vulnerabilities cluster around insecure file handling and information disclosure, which points to parts of Ansible's module ecosystem that still need security hardening. Red Hat maintains a dedicated Ansible Automation Platform CVEs Addressed Report and publishes an annual Product Security Risk Report. Even so, the volume of CVEs reflects the broad attack surface of widely used automation tooling.

For CVE-2026-11837 specifically, the Bugzilla ticket (2487424) is still in "NEW" status with high severity and high priority, assigned to the Product Security DevOps Team. No target milestone has been set as of publication. Red Hat has published the CVE on its customer portal and issued RHSA-2026:13508 for Ansible Automation Platform 2.6.

References

• NVD: CVE-2026-11837
• Red Hat CVE Entry: CVE-2026-11837
• Red Hat Bugzilla: Bug 2487424
• RHSA-2026:13508 Security Advisory
• ansible.posix authorized_key.py Source Code
• ansible.posix Releases on GitHub
• ansible.posix.authorized_key Module Documentation
• CWE-59: Improper Link Resolution Before File Access
• CVE-2026-31979: Symlink Root Privilege Escalation in Himmelblau (Akamai)
• Ansible CVEs on OpenCVE
• Tenable Nessus Plugin 312090: Ansible Automation Platform 2.6
• Red Hat Ansible Automation Platform CVEs Addressed Report