ansible-jailexec CVE-2026-55074
HIGH
GHSA-cxgv-hp74-jj7r
Severity by source
Attacker must have write access inside the jail (AV:L, PR:L); Ansible operator must trigger a file-transfer task (UI:R); jail escape changes scope to host (S:C); arbitrary root host writes yield full C/I/A impact.
Estimated by vuln.today — no official severity rating has been published for this CVE yet.
Lifecycle Timeline
3DescriptionCVE.org
Through version 1.3.0, the jailexec connection plugin's put_file resolved a transfer's destination to a path on the jail host (<jail filesystem root> + <destination>) and ran mkdir -p and mv there as root on the host. Those commands follow symbolic links, and the path was operated on outside the jail, so a symlink existing inside the jail was followed by the host-side, root-privileged mv.
A party controlling content inside a managed jail (the jail's root, or any process able to create a symlink in a directory an Ansible task later writes to) can therefore cause an arbitrary root-owned write on the host, outside the jail - a full jail escape. Arbitrary root-owned host writes are readily escalated to host compromise (e.g. cron, rc.d, authorized_keys).
Preconditions: the operator runs a copy/template/fetch-style task (anything using put_file) against the jail, and the attacker can place a symlink inside the jail at or above the task's destination before the transfer runs.
Patches: Fixed in 2.0.0. File transfers now run inside the jail via jexec (mkdir -p <dir> && cat > <dest> for put_file; cat < <src> for fetch_file), so every path resolves within the jail's chroot. An in-jail symlink can at most redirect within the same jail and can no longer reach the host.
Workarounds: None in affected versions; upgrade to 2.0.0.
Resources:
- https://github.com/chofstede/ansible_jailexec/blob/main/docs/security/advisory-2.0.0-jail-escape.md
- https://github.com/chofstede/ansible_jailexec/pull/6
AnalysisAI
Symlink-following jail escape in the ansible-jailexec FreeBSD connection plugin (versions through 1.3.0) allows a party controlling content inside a managed jail to achieve arbitrary root-owned file writes on the jail host. The put_file method resolves transfer destinations as the jail's filesystem root concatenated with the task's target path, then executes mkdir -p and mv on the host as root - outside the jail's chroot - enabling any symlink planted inside the jail to redirect those writes to arbitrary host paths. An attacker already present inside a managed jail who can anticipate or observe Ansible playbook execution can thereby escape the jail boundary entirely, writing cron jobs, rc.d scripts, or authorized_keys entries to the host and achieving full host compromise. No public exploit has been identified at time of analysis; vendor-released patch 2.0.0 is available.
Technical ContextAI
The ansible-jailexec plugin (pkg:pip/ansible-jailexec) is an Ansible connection plugin for FreeBSD jails that SSH-es to the jail host and wraps commands in jexec, eliminating the need for the jail to have its own sshd or network address. In versions through 1.3.0, the put_file method computed the destination path by concatenating the jail's on-host filesystem root (obtained via jls) with the task-supplied destination, then ran mkdir -p and mv against that concatenated path on the host as a root-privileged user. Because these standard UNIX commands resolve symbolic links transparently before operating, and because the operations occurred outside the jail's chroot on the host filesystem, any symlink inside the jail at or above the destination directory was followed with host-root privileges. CWE-59 (Improper Link Resolution Before File Access - 'Link Following') precisely describes this root cause: the software resolves a path referencing a link without restricting resolution to stay within the intended filesystem boundary. The 2.0.0 fix moves all file-transfer operations inside the jail via jexec - using 'mkdir -p && cat >' piped through jexec rather than host-side mv - so every path resolves within the jail's chroot and cannot traverse to host paths.
RemediationAI
Upgrade ansible-jailexec to version 2.0.0 immediately; the vendor advisory (https://github.com/chofstede/ansible_jailexec/security/advisories/GHSA-cxgv-hp74-jj7r) explicitly states that no workarounds exist in affected versions and that upgrading is the only fix. The patch commit is available at https://github.com/chofstede/ansible_jailexec/commit/6e80eecb2db7aebd1258fded6ae5c3aba1dd4123. After upgrading, operators should remove the now-unnecessary doas/sudo rules for mkdir, mv, rm, and jls from doas.conf or sudoers, as version 2.0.0 requires only a jexec privilege rule on the host. Note that the 2.0.0 release changes file-transfer ownership behavior: files are now written as ansible_jail_user inside the jail rather than as root on the host, so tasks that previously relied on copying to root-owned paths while ansible_jail_user was non-root will require adding 'become: yes' to those tasks. The ansible_jail_root inventory variable, if set, will generate deprecation warnings in 2.0.0 and should be removed, as the on-host jail path is no longer used for any operation.
Same weakness CWE-59 – Improper Link Resolution Before File Access
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today