EUVD-2026-35982
GHSA-49qh-h4vj-mrgf
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local shell on managed host
-
DeliveryStage malicious symlink in ~/.ssh/authorized_keys
-
ExploitWait for operator to run authorized_key as root
-
ExecutionModule chowns symlink target to attacker UID
-
PersistAttacker rewrites sensitive file (sudoers/shadow)
-
ImpactEscalate to root
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Symlink resolution safety
|
| Exploitation Conditions | Requires (1) an unprivileged local shell on a host managed by Ansible, (2) write access to the target user's ~/.ssh directory so an attacker-controlled symlink can be staged before the playbook runs, (3) an operator (or scheduled automation) that invokes the ansible.posix authorized_key module as root - explicitly or via become - against the attacker-controlled account, and (4) that the playbook does not use become_user to drop to the target user before the file operations. Exploitation is limited by the need to win or induce that operator-driven run (UI:R) and is not reachable remotely or without local access; hosts where authorized_key is only ever run against system accounts with operator-controlled ~/.ssh are not exploitable. |
| Impact | The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H reflects a realistic but constrained scenario: the attacker needs a local account (PR:L) on the managed node and must wait for, or induce, an operator to run an authorized_key task as root against their account (UI:R). EPSS and CISA KEV signals are not provided in the input, and no public exploit code is referenced, so exploitation is currently theoretical rather than observed. However, the bug class is trivially weaponizable once a target operator workflow is known - symlink-race chowning of arbitrary paths to a chosen UID is a classic root-to-arbitrary-write primitive - so for environments that routinely run authorized_key as root against user-controlled accounts (shared bastions, multi-tenant Linux hosts, CI runners), this should be treated as a real priority rather than a CVSS-inflated theoretical issue. Note: no CVSS-vs-description conflict is present; the local vector and required interaction are consistent with the described workflow. |
| Exploit ScenarioDerived | A low-privileged user on a managed host that is periodically configured by Ansible pre-creates ~/.ssh/authorized_keys as a symlink pointing to a sensitive system path such as /etc/shadow or /etc/sudoers.d/attacker. When an operator next runs a playbook that invokes ansible.posix.authorized_key as root for that user, the module's os.chown() follows the symlink and reassigns ownership of the target file to the attacker's UID, after which the attacker rewrites it to gain root. No public POC is referenced in the supplied intelligence, but the technique is straightforward to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 10, 2026
Local privilege escalation in the ansible.posix collection's authorized_key module allows an unprivileged local user to redirect root-owned file ownership changes to arbitrary system paths via symlink attacks in ~/.ssh. The module's keyfile() function calls os.chown() instead of os.lchown() and omits O_NOFOLLOW when opening files, so a pre-staged symlink is followed during privileged execution. No public exploit identified at time of analysis, but the technique is a well-understood TOCTOU/symlink class with a moderate-to-high CVSS (7.3).
RemediationAI
Upgrade the ansible.posix collection to the fixed release identified in the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-11837 (cross-reference https://bugzilla.redhat.com/show_bug.cgi?id=2487424 for the precise patched version, which is not independently confirmed in the data provided here). Until the patched collection is deployed, mitigations include: avoiding running the authorized_key module as root against accounts whose home directories are writable by the target user (use become_user to the target account so symlinks fall under the user's own UID, at the cost of needing the target user to exist with a usable shell); pre-creating and locking ~/.ssh and ~/.ssh/authorized_keys with correct ownership and immutable attributes (chattr +i) so symlink substitution fails (trade-off: future legitimate edits must temporarily clear the immutable bit); or restricting which operators can run playbooks containing authorized_key on multi-tenant hosts. Generic 'apply defense in depth' guidance is not sufficient here - the chown-follows-symlink primitive bypasses normal permission checks.
Affected ProductsAI
The affected component is the ansible.posix Ansible collection, specifically the authorized_key module's keyfile() implementation. Exact fixed versions are not enumerated in the provided intelligence; the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-11837 and Bugzilla entry https://bugzilla.redhat.com/show_bug.cgi?id=2487424 should be consulted for the authoritative version matrix. No CPE strings were provided in the input. All deployments that execute authorized_key as root against accounts whose ~/.ssh is writable by an untrusted local user are in scope, regardless of the Ansible controller version.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
ansible.posix is a Red Hat-maintained Ansible collection providing POSIX-oriented modules, including authorized_key for managing SSH ~/.ssh/authorized_keys files on managed hosts. The flaw is rooted in CWE-59 (Improper Link Resolution Before File Access / 'Link Following'): when the keyfile() helper ensures the target user's authorized_keys file exists with correct ownership and permissions, it uses os.chown() (which follows symlinks) rather than os.lchown() (which operates on the link itself), and opens the file without the O_NOFOLLOW flag. Combined, these two issues mean any symlink the target user controls inside ~/.ssh is silently dereferenced by the module running as root, causing chown/open operations to apply to whatever path the symlink points to.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
A local privilege escalation vulnerability was found in the ansible.posix authorized_key module. The module's keyfile() function uses os.chown() instead of os.lchown() and opens files without O_NOFOLLOW when managing SSH authorized keys. An unprivileged local user can pre-stage symbolic links in their ~/.ssh directory to redirect file ownership changes to arbitrary system paths when an operator runs the authorized_key task as root, leading to local privilege escalation.
Executive ViewAI
CVE-2026-11837 affects the ansible.posix collection's authorized_key module, enabling unprivileged local users to escalate privileges to root via symlink attacks on SSH directories. No public exploit identified at time of analysis, but the vulnerability methodology is well-understood, creating material risk for organizations using Ansible to manage infrastructure. Vendor patches are not currently available, requiring immediate compensating controls on affected systems.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) Restrict local system access to trusted administrative accounts; (2) Implement filesystem monitoring and alerting on SSH directory modifications (ownership, permissions); (3) Deploy SELinux or AppArmor mandatory access controls to prevent unprivileged processes from following symlinks in sensitive paths; (4) Minimize local user accounts with system-level privileges; (5) Verify SSH authorized_keys integrity through out-of-band channels; (6) Audit Ansible execution contexts and eliminate unnecessary privilege escalation where feasible.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB