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 allows any unprivileged local user to hijack ownership of arbitrary system files when an operator runs an SSH key management playbook as root. Given that Red Hat Enterprise Linux commands 43.1% of the enterprise Linux server market and Ansible is the de facto standard for infrastructure automation across those environments, the blast radius of CVE-2026-11837 extends to a significant portion of enterprise IT operations that rely on automated SSH key provisioning.

Technical Information

The Vulnerable Component

The vulnerability lives in the keyfile() function within the ansible.posix collection's authorized_key module, specifically in the file plugins/modules/authorized_key.py. This function is responsible for ensuring that a user's ~/.ssh directory and authorized_keys file exist with the correct ownership and permissions. The source code makes calls to os.chown(sshdir, uid, gid) for the SSH directory and os.chown(keysfile, uid, gid) for the key file itself.

Root Cause: os.chown() Follows Symlinks

The core issue 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 is applied to the symlink's target, not the symlink itself. The symlink safe alternative, os.lchown(), operates on the link itself and does not follow it to the target.

Compounding this, the module opens files without the O_NOFOLLOW flag. When O_NOFOLLOW is passed to open(), the kernel returns an ELOOP error if the path resolves to a symbolic link, effectively blocking the symlink following attack at the file open level. Without this flag, both the open and chown operations blindly follow attacker controlled symlinks.

Attack Flow

The exploitation sequence is straightforward and requires minimal sophistication:

Step 1: Pre-staging. An unprivileged local user creates a symbolic link within their own ~/.ssh directory, pointing 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 requires no elevated privileges.

Step 2: Trigger. An Ansible operator runs a playbook containing an ansible.posix.authorized_key task targeting that user's account. This is the standard operational pattern for managing SSH keys, and these tasks typically execute as root to ensure 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, the ownership of /etc/shadow (or whatever the symlink target is) is changed to the unprivileged user's UID and GID.

Step 4: Privilege Escalation. With ownership of /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 exact 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 pattern applies directly here.

The tension with Ansible is particularly notable: the platform's core value proposition involves running privileged operations across fleets of hosts. The authorized_key module is designed to be run as root. This means 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. Specific affected version ranges have not been published by the vendor as of June 10, 2026.

Any system where the following conditions are met is vulnerable:

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

Red Hat Ansible Automation Platform 2.6 is specifically referenced in the security advisory RHSA-2026:13508. 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, reflecting the inherent complexity of an automation platform that executes privileged operations across diverse environments. Recent notable Ansible CVEs include:

The pattern of vulnerabilities around insecure file handling and information disclosure suggests that Ansible's module ecosystem has areas where security hardening remains an ongoing effort. Red Hat maintains a dedicated Ansible Automation Platform CVEs Addressed Report and publishes an annual Product Security Risk Report, demonstrating institutional commitment to transparency. However, the volume of CVEs underscores the broad attack surface inherent in widely used automation tooling.

For CVE-2026-11837 specifically, the Bugzilla ticket (2487424) remains 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