Every Default Ubuntu Desktop Installation Since 24.04 Has a Root Privilege Escalation Bug. Here Is How It Works.

If you are running Ubuntu Desktop 24.04 or anything newer, your system ships with a privilege escalation bug that lets any local user become root. Not a misconfiguration. Not an edge case. The default installation, out of the box, is vulnerable.

The flaw was found by the Qualys Threat Research Unit and is tracked as CVE-2026-3888. It carries a CVSS score of 7.8 (High) and affects every default Ubuntu Desktop installation from 24.04 LTS onward, including 25.10 and the 26.04 development branch. Patches are already available through the standard apt update channel.

The vulnerability is not in a single component. It lives in the gap between two system services that were never designed to interact with each other, and the result is a clean, reliable path from unprivileged user to root.

The Two Components

To understand this bug, you need to know what two pieces of Ubuntu's default stack are doing behind the scenes.

snap-confine is the program that sets up the secure sandbox every time you launch a Snap application. It is a set-user-ID-root (SUID) binary, meaning it runs with root privileges regardless of which user invokes it. That elevated privilege is necessary because building a sandbox involves creating mount namespaces, bind-mounting directories, and setting up cgroups. All of those operations require root. Every Ubuntu Desktop installation since 16.04 includes snapd and snap-confine by default.

systemd-tmpfiles is the cleanup daemon that manages volatile directories like /tmp, /run, and /var/tmp. It creates these directories at boot with the correct ownership and permissions, and it runs periodically to delete stale files that have not been accessed recently. On Ubuntu 24.04, the default cleanup interval for /tmp is 30 days. On 25.10 and later, it is 10 days.

Neither of these components has a bug in isolation. The vulnerability exists because of what happens when they interact.

The Race Condition

Here is the sequence of events that turns a regular user into root.

Phase 1: The Wait

snap-confine uses a temporary directory at /tmp/.snap during sandbox initialization. This directory is created with root ownership and specific permissions. Under normal operation, it exists indefinitely because Snap applications are launched regularly and the directory stays "fresh" in the eyes of the cleanup daemon.

But if no Snap application is launched for 30 days (or 10 days on newer releases), systemd-tmpfiles considers /tmp/.snap stale and deletes it. This is the cleanup daemon doing exactly what it is designed to do. There is no bug here. The problem is what comes next.

Phase 2: Directory Hijack

Once /tmp/.snap is gone, any unprivileged user on the system can recreate it. /tmp is world-writable by design (with the sticky bit set), so any user can create directories inside it. The attacker creates /tmp/.snap and populates it with malicious content: crafted mount configuration files, symlinks, or binaries designed to execute when bind-mounted into a privileged context.

Phase 3: Root Code Execution

The next time any Snap application is launched (by any user on the system, including automated processes), snap-confine initializes the sandbox. As part of that process, it reads the contents of /tmp/.snap and bind-mounts the attacker-controlled files as root. Because snap-confine runs with SUID root privileges, the bind-mount operation happens in a privileged context, and the attacker's payload executes as root.

The attacker now has full root access to the system.

Day 0: /tmp/.snap exists (created by snap-confine, owned by root)
         │
         │  ... 10-30 days pass with no Snap activity ...
         │
Day 30:  systemd-tmpfiles deletes /tmp/.snap (stale file cleanup)
         │
         ▼
Attacker: mkdir /tmp/.snap && populate with malicious payload
         │
         ▼
Any user launches a Snap app (or cron/systemd triggers one)
         │
         ▼
snap-confine runs as root, reads /tmp/.snap
         │
         ▼
Bind-mounts attacker-controlled files as root
         │
         ▼
Attacker payload executes with root privileges
         │
         ▼
Full system compromise

Why This Is Worse Than It Sounds

On the surface, the 10 to 30 day waiting period seems like a significant limitation. But in practice, several factors make this vulnerability highly exploitable.

Shared systems are the primary target. University workstations, developer machines shared between team members, CI/CD build servers, cloud desktops, and enterprise endpoints managed through fleet tools all fit the profile: multiple local users with access to /tmp, and a realistic chance that no Snap application gets launched for a few weeks.

The attacker can force the window. An attacker with local access can monitor when /tmp/.snap was last accessed and simply wait. On Ubuntu 25.10 and later, the window is only 10 days. In an enterprise environment where machines are provisioned and then sit in a pool, this window can easily be met before the machine is even assigned to a user.

No user interaction required. The attacker does not need anyone to click anything or approve anything. They just need to wait for the cleanup daemon to do its job and then plant their payload. The next Snap launch triggers the exploit automatically.

Snap applications launch automatically in the background. Ubuntu Desktop ships with several Snap applications that update and refresh automatically. The snap store itself runs periodic checks. Any of these background processes can trigger snap-confine and detonate the payload.

What About Older Ubuntu?

Qualys confirmed that Ubuntu 16.04 through 22.04 LTS are not vulnerable in their default configurations. The specific interaction between snap-confine and systemd-tmpfiles that enables this attack was introduced in the 24.04 release cycle. However, Qualys still recommends applying the patch across all releases as a precaution, particularly if you have modified the default systemd-tmpfiles configuration or snap-confine behavior.

The uutils Bonus Bug

While investigating CVE-2026-3888, Qualys also discovered a separate race condition in the rm utility from uutils coreutils, a Rust-based reimplementation of GNU coreutils that Ubuntu 25.10 briefly adopted as the default.

The bug in uutils rm could have allowed arbitrary file deletion as root and further privilege escalation. Ubuntu mitigated this by reverting the default rm command back to GNU coreutils before the 25.10 release shipped. The uutils issue serves as a reminder that replacing battle-tested system utilities, even with memory-safe rewrites, introduces new risk surfaces that require thorough security review.

Vulnerability Details

Patched Versions

Patch Now

The fix is a standard apt update. Run this on every Ubuntu Desktop 24.04+ system you manage:

sudo apt update && sudo apt upgrade snapd -y

# Verify the installed version
snap version

# Confirm you are on a fixed version
dpkg -l snapd | grep -E "^ii"

If you manage a fleet, push this through your configuration management tool immediately. Qualys customers can use the Qualys Patch Management solution (QIDs are published in the advisory) for automated deployment.

Detection

Check If You Are Vulnerable

# Check Ubuntu version
lsb_release -a 2>/dev/null | grep Release

# Check snapd version
snap version | head -1

# Check if /tmp/.snap exists and who owns it
ls -la /tmp/.snap 2>/dev/null || echo "/tmp/.snap does not exist (system may be in vulnerable window)"

# Check the systemd-tmpfiles cleanup configuration
grep -r "snap" /usr/lib/tmpfiles.d/ /etc/tmpfiles.d/ 2>/dev/null

Detect Exploitation Attempts

# Monitor creation of /tmp/.snap by non-root users
# Add to auditd rules (/etc/audit/rules.d/snap-confine.rules)
-w /tmp/.snap -p wa -k snap_confine_hijack

# Check audit logs for suspicious /tmp/.snap activity
ausearch -k snap_confine_hijack -i 2>/dev/null

SIEM Detection (KQL)

// Detect non-root creation of /tmp/.snap directory
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has "/tmp/.snap" and SyslogMessage has_any ("mkdir", "create")
| where SyslogMessage !has "root"
| project TimeGenerated, HostName, SyslogMessage, Facility, SeverityLevel

// Monitor snapd package versions across fleet
IntuneDevices
| where Platform == "Linux"
| where OSVersion has "24.04" or OSVersion has "25.10" or OSVersion has "26.04"
| project DeviceName, UserPrincipalName, OSVersion, LastSync

Hardening (Beyond the Patch)

Even after patching, these controls reduce the risk of similar attacks in the future:

Protect /tmp/.snap with tmpfiles.d Override

Create a systemd-tmpfiles configuration that prevents /tmp/.snap from being cleaned:

# /etc/tmpfiles.d/snap-protect.conf
# Exclude /tmp/.snap from age-based cleanup
x /tmp/.snap
x /tmp/.snap/*

This tells systemd-tmpfiles to never delete /tmp/.snap, eliminating the race condition window entirely.

Restrict /tmp Access with mount Options

# Mount /tmp with noexec and nosuid to prevent code execution from /tmp
# Add to /etc/fstab:
tmpfs   /tmp    tmpfs   defaults,noexec,nosuid,nodev,size=2G   0   0

# Apply immediately without reboot:
sudo mount -o remount,noexec,nosuid,nodev /tmp

The noexec flag prevents execution of files from /tmp, which would block many payload delivery mechanisms including this one.

Monitor SUID Binaries

snap-confine is a SUID root binary. Regularly audit all SUID binaries on your system:

# List all SUID binaries
find / -perm -4000 -type f 2>/dev/null | sort

# Compare against a known-good baseline
find / -perm -4000 -type f 2>/dev/null | sort > /tmp/suid_current.txt
diff /tmp/suid_baseline.txt /tmp/suid_current.txt

Key Takeaways

• Every default Ubuntu Desktop 24.04+ installation is affected. The vulnerability exists in the standard package set, not in optional or third-party software. If you installed Ubuntu Desktop 24.04 or later and have not patched, you are vulnerable.
• The bug is a race condition between snap-confine and systemd-tmpfiles. Neither component is broken individually. The vulnerability emerges from the gap between when the cleanup daemon deletes /tmp/.snap and when snap-confine tries to use it, a window that any local user can exploit.
• The CVSS score of 7.8 reflects the timing requirement. The "high attack complexity" rating accounts for the 10 to 30 day delay before the exploit window opens. In practice, on shared or long-lived systems, this window is reliably reachable.
• Patches are available now. Run sudo apt update && sudo apt upgrade snapd on every affected system. There is no reason to remain vulnerable.
• The uutils rm bug is a secondary lesson. Replacing core system utilities, even with memory-safe alternatives, requires the same security scrutiny as the originals. Ubuntu caught this one before release, but the pattern is worth watching.

Canonical has confirmed the vulnerability and released patches for all supported Ubuntu Desktop releases. Organizations running Ubuntu Desktop 24.04 or later should prioritize this update, particularly on shared or multi-user systems where local privilege escalation has the greatest impact.