A Qualys company has identified a vulnerability (CVE-2026-3888) in the operation of the snap-confine and systemd-tmpfiles interaction in Ubuntu, allowing an unprivileged user to gain root access to the system. The issue is present in Ubuntu with the default configuration starting from release 24.04. In Ubuntu 16.04-22.04, the vulnerability can be exploited in non-standard configurations that mimic the behavior of newer versions of the distribution. A fix is available in yesterday's update of the snapd package in Ubuntu. The issue has been resolved in snapd version 2.75.
The vulnerability arises from incorrect interaction between the snap-confine and systemd-tmpfiles utilities, which are executed with elevated privileges. The snap-confine utility creates a sandbox environment for running the snap application, while systemd-tmpfiles performs automatic cleanup of temporary files and directories. By default, systemd-tmpfiles is configured to remove all old files and directories in /tmp, which can be exploited by an attacker to replace the /tmp/.snap directory after its deletion 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 it has been deleted, and placing a modified copy of the libraries in /tmp/.snap/usr/lib/x86_64-linux-gnu.exchange. The attacker may have to wait several days for systemd-tmpfiles to execute, as in Ubuntu 24.04 the cleanup process runs every 10 days, and in newer releases every 30 days. After replacing the directory, the attacker initiates a new sandbox environment using snap-confine.
During the preparation 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 replacing the libraries and ensuring their bind mount with root privileges. In this way, the attacker gains control over the shared libraries and the loader ld.so used in the snap sandbox environment, and can execute arbitrary code with root privileges by launching any SUID program that utilizes dynamic linking.
A root access in a sandbox environment, isolated through AppArmor and a seccomp-based system call filter, allows an attacker to copy /bin/bash to the directory /var/snap/$SNAP/common/ and set its permissions to "04755" (suid root). Although the permissions are changed within the sandbox environment, the file with the modified permissions is also accessible in the main system, so to gain full root access, it is enough to run /var/snap//common/bash as a regular unprivileged user from the standard system environment.
At the same time, a vulnerability was discovered in the uutils coreutils (Rust Coreutils) toolkit, an analogue of the GNU Coreutils package written in Rust. The vulnerability allows an unprivileged user to gain root rights in the system. The issue was identified during the review of changes in Ubuntu 25.10 and was mitigated in a workaround prior to the release of Ubuntu 25.10 by providing /usr/bin/gnurm instead of uutils rm. In the uutils package, the problem was fixed in the uutils coreutils 0.3.0 release, without a mention in the changelog regarding the vulnerability fix (it was noted that a safe method for bypassing paths was implemented in rm, du, chmod, and chgrp).
The problem is caused by a race condition in the 'rm' utility that allows a local user to replace the contents of a directory with a symbolic link while a user-controlled file is being deleted by the 'rm' process with root privileges. Among other things, the vulnerability can be exploited during the daily run from the cron script /etc/cron.daily/apport, which is executed with root privileges and recursively deletes the contents of the /var/crash directory, which is writable by all users in the system.
When recursively deleting directories, the rm utility first checks all directories and then sequentially removes them in reverse order by calling the rmdir() function. If a parent directory is replaced with a symbolic link immediately after checking that directory, but before checking its nested child directories, the operation will lead to the deletion of the directory pointed to by the symbolic link. This can not only result in the deletion of any file in the system but also privileges escalation via the deletion of the directory /tmp/snap-private-tmp/$SNAP/tmp/.snap to replace the contents of the sandbox environment of the snap package (the method of gaining root privileges is similar to the first vulnerability).
Forrás: opennet.ru
