Local privilege escalation in Canonical snapd through private /tmp cleanup

Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.

Canonical initially described the issue as affecting Ubuntu 16.04 LTS through Ubuntu 24.04 LTS. A later Canonical discussion also listed Ubuntu 25.10, and the updated Canonical status page lists Ubuntu 26.04 LTS.

• Ubuntu 16.04 LTS: snapd is affected in non-default configurations; fixed in 2.61.4ubuntu0.16.04.1+esm2.
• Ubuntu 18.04 LTS: snapd is affected in non-default configurations; fixed in 2.61.4ubuntu0.18.04.1+esm2.
• Ubuntu 20.04 LTS: snapd is affected in non-default configurations; fixed in 2.67.1+20.04ubuntu1~esm1.
• Ubuntu 22.04 LTS: snapd is affected in non-default configurations; fixed in 2.73+ubuntu22.04.1.
• Ubuntu 24.04 LTS: default installations were identified by Canonical and Qualys as affected; fixed in 2.73+ubuntu24.04.2. Version 2.73+ubuntu24.04.1 introduced a regression while deploying the fix and should not be treated as the final fixed boundary.
• Ubuntu 25.10: default installations were identified by Canonical as affected; fixed in 2.73+ubuntu25.10.1.
• Ubuntu 26.04 LTS: the updated Canonical status page lists this branch with a fix in 2.74.1+ubuntu26.04.3.
• Upstream snapd: the normalized record states that versions less than 2.75.1 are affected, while the Canonical discussion says hardening was applied in 2.75.1. A Qualys summary gives an upstream boundary of versions prior to 2.75, so the upstream boundary conflicts across sources and should be verified against the vendor advisory before making a final determination.

Canonical snapd performs privileged work in a snap's private /tmp area through snap-confine, while systemd-tmpfiles runs as root to create, remove, and clean temporary directories. If cleanup removes the .snap directory inside a snap's temporary area, a local user can recreate the deleted directory through the writable /tmp path. When snap-confine rebuilds the sandbox, attacker-controlled content can be bind-mounted into the sandbox in a privileged context, leading to arbitrary code execution as root. Preconditions include a low-privilege local account, an installed snap, and a systemd-tmpfiles configuration that cleans the relevant directory. Exploitation also depends on waiting for the cleanup window, so the attack is not immediate. The record and reviewed advisories do not identify a more specific function-level defect beyond unsafe handling of snap-private directories.

This is a local-only vulnerability and is not reachable remotely over the network. An attacker needs a low-privilege local account, but no other user's interaction is required. Complexity is high because the attacker must wait for systemd-tmpfiles to remove the target directory, with Qualys describing a delay of roughly 10 to 30 days depending on the release, and then cause snap-confine to rebuild the sandbox. Qualys publicly documented a proof of concept and demonstrated root-level exploitation, so exploitability has been established technically. That documentation does not by itself establish active exploitation in the wild.

The technical result of exploitation is escalation from a low-privilege local user to root-level execution. Binding attacker-controlled content during snap-confine sandbox construction can permit arbitrary code execution in a privileged context. Because the impact extends beyond the attacker's initial account privileges, a successful attack could affect system confidentiality, integrity, and availability. The systemd-tmpfiles cleanup condition, the presence of a suitable snap, and the long waiting period are practical limitations of the attack path. Systems that do not meet those conditions are not established by the available evidence to be exploitable in the same way.

Successful exploitation can turn a low-privilege local account into root access on the affected host. That access could expose sensitive data, modify system software and configuration, weaken security controls, or disrupt services. The risk is most relevant to systems that permit untrusted local accounts or use snap applications for important workloads. Because Ubuntu branches have separate fixed package versions, remediation tracking must be performed per branch rather than by relying on one generic package status.

1. Prioritize a branch-specific snapd update. Confirm that the package reaches the Canonical fixed boundary: 2.61.4ubuntu0.16.04.1+esm2 for Ubuntu 16.04 LTS, 2.61.4ubuntu0.18.04.1+esm2 for Ubuntu 18.04 LTS, 2.67.1+20.04ubuntu1~esm1 for Ubuntu 20.04 LTS, 2.73+ubuntu22.04.1 for Ubuntu 22.04 LTS, 2.73+ubuntu24.04.2 for Ubuntu 24.04 LTS, 2.73+ubuntu25.10.1 for Ubuntu 25.10, and 2.74.1+ubuntu26.04.3 for Ubuntu 26.04 LTS.
2. Update the complete system through the normal Ubuntu update mechanism. If a full update is not possible, Canonical documents upgrading only snapd with apt, but the installed package must still be checked against the fixed boundary for the running branch.
3. If the update cannot yet be installed, apply the following configuration change only as a last-resort temporary mitigation. Replace the complete contents of /usr/lib/tmpfiles.d/snapd.conf with the configuration published by Canonical:

D! /tmp/snap-private-tmp 0700 root root -

# Allow removing content in the private tmp folders without affecting the
# architectural structure of the folders themselves.
X /tmp/snap-private-tmp
X /tmp/snap-private-tmp/*/tmp
x /tmp/snap-private-tmp/*/tmp/.snap

1. After changing the configuration, run sudo systemctl restart systemd-tmpfiles-clean.service.
2. Track package deployment across all mirrors and recheck with dpkg -l snapd. A fix for one Ubuntu branch does not prove that another branch is fixed.
3. Manual configuration changes may cause later unattended upgrades to fail until the file is restored to the corrected package content. For upstream snapd, the published boundaries of 2.75 and 2.75.1 differ, so verify the exact upstream release with the vendor advisory.

1. Inventory Ubuntu systems with snapd installed, especially systems that permit untrusted local users to log in.
2. On each system, run dpkg -l snapd and compare the installed package with the branch-specific fixed version in affected_summary.
3. Review /usr/lib/tmpfiles.d/snapd.conf and related tmpfiles.d configuration to determine whether systemd-tmpfiles automatically cleans the snap-private /tmp area.
4. Confirm that the installed package contains the corrected rule that preserves the private directory structure while permitting only the intended cleanup of its contents.
5. As a precaution, review for unexpected ownership changes or recreation of directories below snap-private temporary paths. This is defensive monitoring, not a vendor-confirmed IOC.
6. Do not treat the absence of suspicious log events as proof of safety. Package version and configuration verification are the primary checks.