Because the underlying Python open() call follows these links, the application writes the payload into the host filesystem with the privileges of the Termux user, bypassing the intended rootfs isolation. This allows for the overwriting of shell startup files (such as ~/.bashrc or ~/.profile), resulting in persistent code execution upon the next shell session. This vulnerability also impacts the helpers/docker.py component via the _apply_layer function.

Attack Chain

1. The attacker crafts a malicious tar archive containing a symbolic link with an absolute target path (e.g., /data/data/com.termux/files/home).
2. The attacker includes a subsequent regular file member in the tarball that uses the symlink path as a directory prefix.
3. The victim executes proot-distro install <malicious_archive> or proot-distro reset.
4. The _extract_plain_tar() function in proot_distro/commands/install.py processes the symlink and creates it on the host filesystem without validating the target destination.
5. The extraction process reaches the regular file member and follows the attacker-controlled symlink.
6. The application writes the file content into the host filesystem location defined by the symlink.
7. The user's environment is modified, leading to persistent command execution when the user later initiates a session or modifies shell configuration.

Impact

Successful exploitation allows for arbitrary file write on the host Android device within the Termux sandbox boundaries. By overwriting shell initialization scripts like ~/.bashrc or ~/.profile, attackers can achieve persistent code execution. This vulnerability affects all users of proot-distro on Termux who process untrusted or potentially compromised rootfs archives, with confirmed impact on the Termux app version 0.119.0-beta.3 and proot-distro 5.0.2.

Recommendation

• Upgrade to a patched version of proot-distro immediately.
• Implement the _is_safe_symlink validation guard as described in the brief to reject symlinks with absolute targets or those that resolve outside the rootfs_dir.
• Audit existing tar extraction logic in other tools to ensure member.linkname is validated against absolute paths and directory traversal.
• Monitor for the deployment of malicious tar archives that may attempt to utilize the SHA-256 hash provided in the IOC section.