GPU VulnDB

Database/Control plane, storage & DevOps

ansible.posix authorized_key: a symlink under a user's ~/.ssh redirects a root chown to any path

CVE-2026-11837Control plane, storage & DevOpscurated

Impact

The module's keyfile() helper calls os.chown() instead of os.lchown() and opens files without O_NOFOLLOW, so a symlink an unprivileged user plants in their own ~/.ssh redirects the ownership change to any path on the system when an operator runs the task as root. Owning a root-owned file is a short walk to root. Fleet-wide SSH key rollout via authorized_key is routine on GPU and HPC clusters, which is what makes this reachable: login and head nodes, and GPU nodes that give tenants real shell accounts with persistent home directories, are the exposed shape. Nodes that only ever run containers, with no unprivileged home directories the module writes into, are much harder to hit. The attacker has to wait for or induce an operator play run.

Who can reach it

Local unprivileged user with a home directory on an Ansible-managed host, who must wait for an operator to run an authorized_key task as root against that host.

What to do

Update the ansible.posix collection wherever it executes - the control node and every execution-environment image that bundles it, which means rebuilding and redeploying those images rather than patching a running daemon. Red Hat lists affected RHEL 8/9/10 and OpenStack 17.1/18.0 streams; take fixed versions from their CVE page or VEX record, as the NVD entry names none. No GPU node reboot is involved. Until updated, avoid running authorized_key as root against hosts where untrusted users hold accounts.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.