CVE-2026-11837: Local Privilege Escalation in ansible.posix authorized_key
TL;DR - High-severity local privilege escalation in
ansible.posix.authorized_key. - A local user can abuse symlinks if a root-run Ansible task manages~/.ssh/authorized_keys. - Patch availability appears likely via vendor channels, but exact fixed upstream version is not confirmed from available primary-source text.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-11837 |
| CVSS score | 7.3 (High) |
| Attack vector | Local |
| Auth required | Local unprivileged access required |
| Patch status | Vendor updates likely available; exact fixed version not confirmed from retrieved primary-source text |
What is CVE-2026-11837?
CVE-2026-11837 is a local privilege escalation vulnerability in the ansible.posix collection’s authorized_key module. According to the NVD description, the flaw is in the module’s keyfile() handling, where it uses os.chown() instead of os.lchown() and opens files without O_NOFOLLOW. That combination creates a symlink-following condition during privileged file operations.
In practical terms, the issue matters when an administrator or automation system runs an Ansible task as root and uses ansible.posix.authorized_key to manage a user’s SSH keys. If a local, unprivileged user can pre-stage a malicious symbolic link inside their ~/.ssh path, the privileged task may follow that link and apply ownership or file operations to an unintended target. That can let a low-privilege user influence root-run file handling and potentially escalate privileges.
This is not a remote code execution bug, and it is not a no-auth network exposure. The attacker must already have local access on the host. But for multi-user Linux systems, shared administrative bastions, CI runners, automation hosts, or environments where local shell access is common, that prerequisite may not be much comfort. Any workflow that runs Ansible with elevated privileges against local users should treat this as a meaningful hardening and patching priority.
CVSS and why it matters here
The published base score is 7.3, rated High. The full CVSS vector was not returned in the NVD tool output used for this research, so any detailed vector breakdown beyond the known local nature of the issue would be speculative. What matters for defenders is the combination of local preconditions and privilege impact.
The score makes sense in context. On one hand, the attack is not remote and requires local access plus a privileged automation run. On the other hand, the outcome is privilege escalation through a trusted administrative mechanism. Those are exactly the kinds of bugs that convert a limited foothold into full system compromise, especially on hosts where administrative automation regularly touches user-owned paths.
Quick impact assessment for defenders
The impact is best understood as an abuse of trusted automation. Many teams think of Ansible tasks as harmless configuration plumbing, but modules that manipulate files under privilege boundaries are part of the attack surface. In this case, a local attacker does not need to compromise Ansible itself. They only need a chance to shape the filesystem state before a privileged authorized_key task runs.
That makes the likely blast radius environment-dependent. If your systems never grant local interactive access to untrusted users, the exposure is narrower. If you run shared Linux systems, student or developer shells, ephemeral build workers, or jump boxes where users have home directories and .ssh trees, the risk is much more concrete. A root-run automation task against an attacker-controlled home directory is exactly the kind of condition symlink attacks are built to exploit.
Who is affected?
The confirmed affected component is the ansible.posix collection, specifically the authorized_key module. The NVD entry and Red Hat Bugzilla metadata both support that scope. The bug title in Red Hat Bugzilla explicitly identifies: ansible-collection-ansible-posix: ansible.posix authorized_key: local privilege escalation via symlink-following chown.
What is not confirmed from the retrieved primary-source material is the exact affected version range. The available NVD and Bugzilla text identify the vulnerable module and root cause, but the fetched content did not expose a clean upstream “affected from X through Y” statement. Because of that, defenders should avoid guessing. If your environment uses the ansible.posix collection and the authorized_key module, you should assume exposure until you verify package or collection versions against an official vendor advisory or release note.
Likewise, the exact fixed version number could not be conclusively verified from the source material provided. A Red Hat advisory reference, RHSA-2026:13508, was surfaced during research, which suggests vendor fixes may be available in supported channels. However, without the advisory body or upstream release note text confirming the exact collection version, the only accurate statement is: patch availability appears likely, but the exact fixed version remains unconfirmed from the retrieved primary sources.
Affected versions and fixed version status
Because the exact version range is not exposed in the source text available here, the most defensible statement is:
| Versioning field | Status |
|---|---|
| Confirmed affected product | ansible.posix collection |
| Confirmed affected module | authorized_key |
| Confirmed affected range | Unknown from retrieved primary-source text |
| Confirmed fixed version | Unknown from retrieved primary-source text |
| Defender assumption | Treat installed ansible.posix versions as potentially affected until checked against official advisory data |
This is one of those cases where precision matters more than completeness. Inventing a version range would be worse than stating uncertainty. If you are responsible for remediation, pull the installed collection version directly from your control nodes and execution environments, then compare it against official vendor guidance as soon as that guidance is accessible in full.
Technical Notes
You can identify installed Ansible collection versions with commands such as:
ansible-galaxy collection list | grep ansible.posix
If you use Execution Environments or containerized automation, verify from within the image:
podman run --rm -it <your-ee-image> ansible-galaxy collection list | grep ansible.posix
For RPM-based packaging contexts, you may also want to inspect related packages:
rpm -qa | grep -Ei 'ansible|ansible-collection|automation'
Exploitation status: in the wild, PoC, and KEV
At the time of writing, exploitation in the wild is not confirmed from the available primary sources. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog. That does not prove nobody is exploiting it, but it does mean there is no public U.S. government confirmation of active exploitation in the sources reviewed here.
A public proof of concept is also not confirmed from the retrieved materials. No verified exploit repository, advisory with exploit steps, or vendor-authored reproduction sequence was present in the source set. Defenders should interpret that conservatively: lower public visibility may reduce opportunistic abuse, but symlink attacks are a well-understood class, and local attackers with enough familiarity may not need a polished public PoC.
Operationally, the absence of a known PoC or KEV listing should moderate panic, not action. This is still a high-severity privilege escalation path tied to common automation patterns. If your environment meets the prerequisites, patching and mitigation should proceed on a normal high-priority timeline.
What defenders should do next
First, identify every place ansible.posix.authorized_key is used, especially in playbooks that run as root. Second, verify installed ansible.posix versions on control nodes, automation controllers, and execution environment images. Third, compare those versions against official vendor guidance as soon as you can retrieve the advisory or upstream release note containing the fixed version.
If you cannot immediately verify version status, assume potential exposure and implement compensating controls. That means checking for symlink abuse in user .ssh directories, pausing risky key-management workflows on shared systems, and adding preflight validation to reject symlinked authorized_keys paths. Even if exploitation is not confirmed in the wild, these are sensible hardening steps for any environment that automates privileged file operations.
How to detect exposure and possible abuse
Start by identifying where ansible.posix.authorized_key is used in your playbooks, roles, and execution environments. This is one of the clearest exposure indicators. If the module is not used at all, the CVE may be irrelevant to your estate. If it is used, focus on tasks that run with become: true, become_user: root, or equivalent elevated execution.
Next, review which systems allow local users to create or control ~/.ssh contents before administrative automation runs. The attack described by NVD depends on pre-staged symlinks. That means suspicious symbolic links inside user .ssh directories, especially links named authorized_keys or links pointing outside the expected home directory, deserve immediate attention.
Technical Notes
A simple hunt for suspicious symlinks under home directories:
find /home -path '*/.ssh/*' -type l -ls
A narrower check for authorized_keys symlinks:
find /home -path '*/.ssh/authorized_keys' -type l -exec ls -l {} \;
If you have Linux auditd enabled, watch for symlink creation in .ssh paths and ownership changes triggered by Ansible-related processes. Example audit rules:
auditctl -w /home -p wa -k home_ssh_watch
auditctl -w /root/.ansible -p wa -k ansible_activity
Then query audit logs for suspicious sequences:
ausearch -k home_ssh_watch | grep -E '\.ssh|authorized_keys|symlink'
ausearch -k ansible_activity
Example log pattern to review in shell history, EDR telemetry, or process execution logs:
ansible-playbook ... authorized_key ...
chown ...
/home/<user>/.ssh/authorized_keys -> /etc/passwd
If you collect filesystem telemetry with Sysmon for Linux, auditbeat, or EDR, alert on a symlink under ~/.ssh/authorized_keys whose target resolves outside the user’s home directory. A practical detection idea is:
Condition:
file.path matches /home/*/.ssh/authorized_keys
AND file.type == symlink
AND symlink.target NOT LIKE /home/*/.ssh/*
Mitigation and patching
The preferred mitigation is to install the vendor-provided fix as soon as you can verify the updated package or collection version from an official advisory. Because the exact fixed version is not confirmed in the available source text, your immediate task is inventory first, upgrade second, and validation third. If you consume Red Hat-supported Ansible or Automation Platform content, check the relevant errata and update channels tied to your subscription.
Until patching is complete, reduce exploitability by avoiding root-run authorized_key operations against attacker-controlled home directories. If possible, temporarily suspend playbooks that manage SSH keys for local users on shared systems. Another practical workaround is to validate that target authorized_keys paths are regular files, not symlinks, before any privileged key-management task runs.
Technical Notes
To update collections from Ansible Galaxy or an internal mirror, use your normal content source. Example:
ansible-galaxy collection install ansible.posix --upgrade
If you rely on locked requirements, update the pinned version only after checking the official fixed release:
# requirements.yml
collections:
- name: ansible.posix
version: "<official fixed version here>"
Then apply:
ansible-galaxy collection install -r requirements.yml --force
For Red Hat-managed environments, use your supported package workflow to apply errata once the advisory is validated in your environment:
sudo dnf update -y
As a temporary pre-task workaround, fail playbook execution if authorized_keys is a symlink:
- name: Check authorized_keys path
stat:
path: "/home/{{ target_user }}/.ssh/authorized_keys"
follow: false
register: ak_stat
- name: Refuse to manage symlinked authorized_keys
fail:
msg: "Refusing to manage symlinked authorized_keys for {{ target_user }}"
when: ak_stat.stat.islnk is defined and ak_stat.stat.islnk
You can also enforce directory and file sanity before key deployment:
- name: Ensure .ssh directory exists with safe ownership
file:
path: "/home/{{ target_user }}/.ssh"
state: directory
owner: "{{ target_user }}"
group: "{{ target_user }}"
mode: "0700"
- name: Remove symlinked authorized_keys if found
file:
path: "/home/{{ target_user }}/.ssh/authorized_keys"
state: absent
when: ak_stat.stat.islnk is defined and ak_stat.stat.islnk
References
- NVD CVE record: CVE-2026-11837
- Red Hat CVE page: Red Hat CVE
- Red Hat Bugzilla: Bugzilla Entry
- Red Hat advisory reference surfaced in research: RHSA-2026:13508
- CISA KEV catalog: CISA KEV
For additional information on security practices, consider reading about what is PCI DSS and who must comply and the uncomfortable truth about MDR outsourcing.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.