Qualys has identified a vulnerability (CVE-2026-3888) in the interaction between snap-confine and systemd-tmpfiles in Ubuntu, allowing an unprivileged user to gain root access to the system. The issue manifests in Ubuntu in the default configuration starting from release 24.04. In Ubuntu versions 16.04-22.04, the vulnerability can be exploited in non-standard configurations mimicking the behavior of newer distribution versions. In Ubuntu, a fix is available in yesterday's snapd package update. The problem has been addressed in snapd version 2.75. <\/p>\n
The vulnerability arises from the improper interaction between the utilities snap-confine and systemd-tmpfiles, which are executed with elevated privileges. The snap-confine utility creates a sandbox environment for running snap applications, while systemd-tmpfiles performs automatic cleanup of temporary files and directories. By default, systemd-tmpfiles is configured to delete all old files and directories in \/tmp, which can be exploited by an attacker to substitute the \/tmp\/.snap directory immediately after it is removed by systemd-tmpfiles but before it is recreated by snap-confine. <\/p>\n
The attack involves waiting for the cleaning process of temporary files to start, replacing the directory \/tmp\/.snap after its deletion, and placing a modified copy of the libraries \/tmp\/.snap\/usr\/lib\/x86_64-linux-gnu.exchange. The attacker may need to wait several days for the systemd-tmpfiles to run, as in Ubuntu 24.04 the cleaning process runs every 10 days, while in newer releases \u2014 every 30 days. After replacing the directory, the attacker aims to initialize a new sandbox environment using snap-confine. <\/p>\n
During the initialization of the sandbox environment in the temporary directory \/tmp\/.snap, the attacker waits for the right moment and renames \/tmp\/.snap\/usr\/lib\/x86_64-linux-gnu.exchange to \/tmp\/.snap\/usr\/lib\/x86_64-linux-gnu, thus substituting the libraries and ensuring their bind mount with root privileges. Consequently, the attacker gains control over the shared libraries and the ld.so loader running in the snap sandbox environment and can achieve arbitrary code execution with root privileges by launching any suid program that utilizes dynamic linking. <\/p>\n
With root access in the sandbox environment, isolated via AppArmor and a seccomp-based syscall filter, the attacker can copy \/bin\/bash to the directory \/var\/snap\/$SNAP\/common\/ and set its permissions to \u201804755\u2019 (suid root). Although the permissions are changed inside the sandbox environment, the file with changed permissions is accessible in the main system, so to gain full root access, it is sufficient to run \/var\/snap\/\/common\/bash as a regular unprivileged user from the standard system environment. <\/p>\n
Additionally, a vulnerability was discovered in the uutils coreutils toolkit (Rust Coreutils), which is an analogue of the GNU Coreutils package written in Rust. The vulnerability allows an unprivileged user to gain root privileges in the system. The issue was identified during the review of changes in Ubuntu 25.10 and was bypassed before the release of Ubuntu 25.10 by providing \/usr\/bin\/gnurm instead of uutils rm. The problem in the uutils package was addressed in the uutils coreutils 0.3.0 release, without noting the vulnerability fix in the changelog (it was mentioned that a safe path workaround was implemented in rm, du, chmod, and chgrp). <\/p>\n
The issue is caused by a race condition in the \u2018rm\u2019 utility, allowing a local user to replace the contents of a directory with a symbolic link while the \u2018rm\u2019 process, running with root privileges, is deleting a user-controlled file. Among other things, the vulnerability can be exploited during the daily execution of the cron script \/etc\/cron.daily\/apport, which runs with root privileges and recursively deletes the contents of the \/var\/crash directory, writable by all users in the system. <\/p>\n