CVE-2026-3888: Snap LPE -- Patch It Now

This post covers a live vulnerability with a patch already available. Version history in changelog below.

What’s New This Week

Qualys published the full technical advisory for CVE-2026-3888 on 17 March 2026, including working proofs of concept for Ubuntu 24.04 and 25.10. The coordinated disclosure timeline started in December 2025 – patches for all affected Ubuntu versions are available now via apt.

Changelog

Qualys disclosed CVE-2026-3888 this week: a local privilege escalation in Ubuntu’s Snap package manager that hands any unprivileged local user a full root shell on Ubuntu 24.04 and later. The CVSS score is 7.8 (High). Patches are out. If you’re running Ubuntu 24.04+ with Snap – which is every default Ubuntu Desktop installation – you need to update snapd today.

The exploit has a timing requirement. You have to wait for a scheduled cleanup job to delete a specific directory before the attack window opens. On Ubuntu 24.04 that’s a 30-day wait; on later versions, 10 days. This sounds like a significant barrier. It isn’t, and I’ll explain why.

What the exploit actually does

Two system components interact in a way neither was designed to handle.

snap-confine is the setuid-root binary that constructs the sandbox before a snap application runs. It handles mount namespace isolation, cgroup enforcement, AppArmor policy loading, and seccomp filtering – the full confinement stack. Because it sets up kernel-level isolation on behalf of regular users, it runs with elevated privileges. Every execution of a snap application passes through snap-confine first.

systemd-tmpfiles manages volatile directories: /tmp, /run, /var/tmp. It creates them at boot with the right ownership and cleans stale entries on a timer. In Ubuntu 24.04 the default threshold is 30 days; in later Ubuntu versions it’s 10 days.

The interaction: snap-confine does privileged work inside /tmp/snap-private-tmp, including creating and bind-mounting a /tmp/.snap directory used to construct “mimics” of read-only filesystem paths that snaps need writeable. The mimic process works roughly like this – snap-confine bind-mounts a read-only directory from the squashfs base into /tmp/.snap/, mounts a fresh writable tmpfs over the real path, then bind-mounts everything back from /tmp/.snap/ into the writable tmpfs. This is how a snap gets a writable version of otherwise read-only paths like /usr/lib/x86_64-linux-gnu.

Here’s the problem: /tmp/.snap is created by root and initially root-owned, but /tmp is world-writable. When systemd-tmpfiles runs its cleanup and deletes the stale /tmp/.snap directory (it hasn’t been modified, just accessed), an unprivileged user can recreate it and populate it with malicious content. On the next sandbox initialisation, snap-confine bind-mounts that attacker-controlled content as root – handing the attacker control over shared libraries and the dynamic loader inside the sandbox. From there, executing any dynamically-linked setuid-root binary runs the attacker’s code as root.

Qualys demonstrated the full chain on Ubuntu 24.04 and 25.10, producing a working root shell in both cases. The 24.04 proof of concept exploits the race between snap-confine’s mimic creation steps to swap in a malicious library directory. The 25.10 path is slightly different (snap-confine lost its setuid-root bit in favour of capabilities there) but equally effective via a different race target.

Why “high complexity” doesn’t mean low risk

The CVSS Attack Complexity: High rating reflects the timing dependency. An attacker can’t trigger the cleanup – they have to wait for it. That’s the basis for the High Complexity classification. It’s also why people will read “7.8 High” and think this is a mid-tier priority. It shouldn’t be.

High Complexity in CVSS means the attack requires conditions the attacker doesn’t fully control. But “conditions the attacker doesn’t fully control” is not the same as “conditions unlikely to occur.” The systemd-tmpfiles cleanup runs on a predictable schedule. An attacker who has a low-privilege foothold on a machine just has to wait. 10 to 30 days is a long time in incident response terms, but it’s a trivially short time for a patient attacker maintaining access via a compromised dependency or a dormant implant.

The race condition component of the actual exploit is also a solved problem. Qualys used a well-understood technique – rate-limiting snap-confine’s debug output through a socket buffer to reliably single-step the mimic creation – to win the race deterministically. The timing requirement is the hard part. The race itself isn’t.

Developer machines are the target

Snap is the default package manager on Ubuntu Desktop. Developer machines running Ubuntu 24.04 or later have snapd installed by default, often with Firefox, snap-store, and other snap applications running. They’re also the machines most likely to have a credible initial-access vector.

The threat model for developer workstations has expanded considerably in 2026. Supply chain attacks via malicious npm packages and compromised Rust crates in CI/CD pipelines have demonstrated reliable paths to unprivileged code execution on developer machines. ClickFix and MacSync campaigns have specifically targeted developers with social engineering that achieves initial access. Once you have unprivileged code execution on a developer machine, you have the starting conditions for CVE-2026-3888.

Developer machines carry extraordinary credential density – cloud provider keys, signing certificates, SSH keys, access tokens for production systems. A root shell on a developer workstation is rarely just a workstation compromise. The blast radius extends to whatever that machine had access to.

The combination is significant: initial access via supply chain or social engineering, persistence for 10-30 days at low privilege, then root via CVE-2026-3888 when the cleanup timer fires. No interaction required from the user after the initial compromise.

Where this fits in the pattern

CVE-2026-3888 isn’t a bug in snap-confine. It isn’t a bug in systemd-tmpfiles. Both components are doing exactly what they were designed to do – snap-confine is doing privileged work in /tmp, and systemd-tmpfiles is cleaning up stale /tmp entries. The vulnerability is the interaction between them, which nobody designed and nobody anticipated.

This pattern recurs in complex system software. Polkit/pkexec (2021) exploited a subtle interaction between how pkexec parsed its own argument list and how polkit validated the calling process. Dirty Pipe (2022) arose from an interaction between page cache handling and the pipe splicing implementation – neither component was buggy in isolation. PwnKit and related class were all about unexpected interactions between components with individually correct behavior.

The reason these bugs are hard to find in code review is precisely that neither component looks wrong. You’d have to reason about the combined behavior of two independently correct components that weren’t designed to interact, and model the failure mode of their interaction over a 10-30 day time window. That’s not a standard threat model.

It’s a class of bug that gets harder to prevent as systems grow more complex and composed, and easier to find in retrospect once you know the pattern.

Affected versions and how to patch

Patch is available now for all affected versions.

Affected:

• Ubuntu 24.04 LTS: snapd < 2.73+ubuntu24.04.2
• Ubuntu 25.10: snapd < 2.73+ubuntu25.10.1
• Ubuntu 26.04 LTS (dev): snapd < 2.74.1+ubuntu26.04.1
• Upstream snapd: versions < 2.75
• Ubuntu 16.04-22.04: not vulnerable in default config; patch recommended as precaution for non-default configurations

Check what you’re running:

lsb_release -a
snap version

Patch:

sudo apt update && sudo apt install snapd

Verify: snap version should report 2.73 or 2.74+ depending on your Ubuntu release.

If you manage Ubuntu developer machines via MDM or configuration management, push this update now. Don’t wait for the next patch cycle. The timing requirement means machines that are already compromised at low privilege may be within days of the window opening.

One apt upgrade. Do it now, verify the version, move on. If you’re managing a fleet, treat this like the P0 it is – the 30-day window on 24.04 machines means some of your developer workstations may already be partway through an attacker’s patience timer.