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.
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.
The attack involves waiting for the temporary file cleanup process to start, replacing the /tmp/.snap directory after its deletion, and placing a modified copy of the libraries in /tmp/.snap/usr/lib/x86_64-linux-gnu.exchange. The attacker may need to wait several days for systemd-tmpfiles to run, as in Ubuntu 24.04, the cleanup process is executed every 10 days, and in newer releases, every 30 days. After replacing the directory, the attacker aims to initialize a new sandbox environment using snap-confine.
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.
With root access in a sandbox environment isolated by AppArmor and a seccomp-based syscall filter, an attacker can copy /bin/bash to the directory /var/snap/$SNAP/common/ and set its permissions to '04755' (suid root). Despite the permissions being changed within the sandbox environment, the file with altered permissions is also accessible in the main system, so to gain full root access, it is sufficient to launch /var/snap//common/bash as a regular unprivileged user from the standard system environment.
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).
The issue is caused by a race condition in the 'rm' utility, allowing a local user to replace the contents of a directory with a symbolic link while removing a user-controlled file with the 'rm' process running as root. Among other things, the vulnerability can be exploited when executed daily from a 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.
When recursively deleting directories, the rm utility first checks all directories and then removes them in reverse order, invoking the rmdir() function. If the parent directory is replaced with a symbolic link immediately after checking this directory, but before checking its nested child directories, the operation will result in the deletion of the directory pointed to by the symbolic link. This can lead not only to the deletion of any file in the system but also to privilege escalation by removing the directory /tmp/snap-private-tmp/$SNAP/tmp/.snap to replace the contents of the snap package's sandbox environment (the method of gaining root is similar to the first vulnerability).
Source: opennet.ru
