CVE-2026-55074: 
Python vulnerability analysis and mitigation

CVE-2026-55074 is a jail escape vulnerability in the ansible-jailexec Ansible connection plugin (pip package ansible-jailexec) caused by improper symlink resolution during file transfers. Through version 1.3.0, the put_file method resolved destination paths on the jail host and executed mkdir -p and mv as root outside the jail's chroot, allowing a symlink planted inside the jail to redirect root-privileged writes to arbitrary host filesystem locations. The vulnerability was disclosed on June 10, 2026, published to the GitHub Advisory Database on August 12, 2026, and affects all versions before 2.0.0. It carries a CVSS v4.0 base score of 7.7 (High) (GitHub Advisory, Security Advisory).

The root cause is CWE-59 (Improper Link Resolution Before File Access — 'Link Following'). In affected versions, put_file computed the destination as <jail_root> + <in-jail path> and then ran mkdir -p and mv on that host-side path as root, without confining the operation to the jail's chroot. Because mv follows symbolic links, an attacker who can create a symlink inside the jail (e.g., making /usr/local/etc inside the jail point to /etc on the host) can cause the host-side root mv to write an attacker-controlled file to an arbitrary host path. The preconditions are: (1) the operator runs any Ansible task that invokes put_file (copy, template, etc.) against the jail, and (2) the attacker can place a symlink at or above the task's destination inside the jail before the transfer executes (GitHub Advisory, Security Advisory).

Successful exploitation constitutes a full FreeBSD jail escape, granting an attacker the ability to perform arbitrary root-owned writes on the host system outside the jail's chroot. Such writes can be trivially escalated to full host compromise by overwriting sensitive files such as /etc/cron.d entries, rc.d scripts, or authorized_keys files. The confidentiality, integrity, and availability of the host system are all fully compromised, and any other jails or services running on the same host are at risk of lateral compromise (GitHub Advisory, Patch Commit).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the advisory publication date. The vulnerability requires low privileges (control over content inside a managed jail) and no user interaction, but does require the specific precondition that an Ansible put_file-based task is run against the jail. The CVE status is listed as Reserved, and it does not appear in the CISA Known Exploited Vulnerabilities catalog. Qualys has added detection for this vulnerability (detection ID 5016877) (GitHub Advisory, Feedly).

1. Gain access inside the jail: Obtain the ability to create files or symlinks inside a FreeBSD jail managed by an Ansible playbook using the ansible-jailexec plugin (version ≤ 1.3.0). This could be achieved as the jail's root user or as any process with write access to a directory that an Ansible task will later target.
2. Identify the target Ansible task: Determine which Ansible tasks use copy, template, or similar modules that invoke put_file, and identify the destination path inside the jail (e.g., /usr/local/etc/nginx/nginx.conf).
3. Plant a symlink: Before the Ansible task runs, create a symbolic link inside the jail at or above the task's destination path that points to a sensitive host-side location. For example, create a symlink so that /usr/local/etc inside the jail resolves to /etc on the host: ln -sf /etc /jail/web-jail/usr/local/etc.
4. Trigger the Ansible task: Wait for or cause the operator to run the Ansible playbook. The put_file method resolves the destination as <jail_root> + <in-jail path> on the host and executes mkdir -p and mv as root, following the planted symlink.
5. Achieve host-side root write: The mv command writes the attacker-controlled file content to the symlink target on the host (e.g., /etc/nginx/nginx.conf becomes an attacker-controlled file, or a cron job or authorized_keys entry is injected).
6. Escalate to full host compromise: Use the root-owned write to establish persistence or escalate privileges on the host, for example by injecting an SSH public key into /root/.ssh/authorized_keys or adding a cron job that executes a reverse shell (GitHub Advisory, Security Advisory).

• File System: Unexpected symbolic links inside managed jails pointing to host-side paths (e.g., /jail/<name>/etc → /etc, /jail/<name>/usr/local/etc → /etc); newly created or modified files in sensitive host directories (/etc/cron.d/, /root/.ssh/authorized_keys, /etc/rc.d/) with timestamps correlating to Ansible playbook runs; unexpected files in /tmp with names matching ansible-jailexec-* that were not cleaned up.
• Logs: Ansible verbose logs (-vvv) showing put_file operations resolving to unexpected host-side paths; doas/sudo logs recording mv or mkdir commands operating on paths outside the expected jail root; SSH authentication logs showing new key-based logins from unknown sources following a playbook run.
• Process: Root-owned mv or mkdir processes with arguments referencing paths outside the jail root directory during Ansible playbook execution; unexpected cron jobs or rc.d scripts executing shell commands or network connections.

The vendor has released version 2.0.0 of ansible-jailexec, which fixes the vulnerability by rewriting file transfers to execute entirely inside the jail via jexec (mkdir -p && cat > for put_file; cat < for fetch_file), ensuring all path resolution occurs within the jail's chroot. There are no workarounds available for affected versions (≤ 1.3.0); upgrading to 2.0.0 is the only remediation. After upgrading, operators should also trim their doas/sudoers rules to allow only jexec (removing previously required rules for jls, mkdir, mv, and rm) and remove any ansible_jail_root inventory variables, which are now deprecated and ignored (GitHub Advisory, Patch Commit).

The vulnerability was credited to researcher Marsam2489 in the GitHub Advisory. A social media post referencing the CVE appeared on a Mastodon instance (burningboard.net) shortly after initial disclosure in June 2026. No significant broader media coverage or notable researcher commentary beyond the official advisory has been identified (GitHub Advisory).