Local privilege escalation in Canonical snapd snap-confine

A local privilege escalation vulnerability exists in snap-confine, a set-capabilities core component used internally by Canonical snapd to construct the secure execution environment for snap applications. This vulnerability uniquely affects versions of snap-confine configured with set-capabilities (rather than standard set-uid-root installations). Due to a flaw in how privilege boundaries or security sandboxes are initialized when the binary runs under limited ambient capabilities, a local, unprivileged attacker can exploit this behavior to bypass intended restrictions and execute arbitrary code. Successful exploitation allows the local user to elevate their privileges to full root authority.

Exposure depends on both the release branch and deployment configuration:

• Upstream snapd: the normalized record marks 2.75.0 through less than 2.76.1 as affected, with default_status set to unaffected. The relevant configuration is snap-confine using set-capabilities.
• Canonical Ubuntu 26.04 LTS: default status is affected; the confirmed fixed package release is 2.76+ubuntu26.04.3.
• Canonical Ubuntu 24.04 LTS: default status is affected; the confirmed fixed package release is 2.76+ubuntu24.04.1.
• Canonical Ubuntu 22.04 LTS: default status is affected; the confirmed fixed package release is 2.76+ubuntu22.04.1.
• Ubuntu 20.04 LTS and Ubuntu 18.04 LTS are identified by Ubuntu as not affected.

Do not generalize a fixed release from one Ubuntu branch to another branch or to every downstream build.

The flaw is in snap-confine, an internal Canonical snapd component that constructs the secure execution environment for snap applications. The affected configuration is specifically associated with set-capabilities, rather than standard set-uid-root installations. Available technical evidence states that snap-confine can be tricked into creating attacker-controlled files at certain privileged locations, weakening intended protection boundaries and sandboxing. The attacker must have local access with low privileges, and no interaction from another user is required. Successful exploitation can permit arbitrary code execution and full root privileges. The precise initialization defect, affected privileged paths, and complete exploit chain are not fully described by the available evidence.

The vulnerability is locally reachable and is not described as a remote network attack. The attacker needs a local account with low privileges; attack complexity is assessed as low and no user interaction is required. The supplied record marks the public exploit status as false, while the returned CISA status data reports Exploitation: none and Automatable: no. These statuses do not prove that systems are safe or exclude exploitation that has not been reported.

The documented technical outcome is a bypass of protections in the snap execution environment, arbitrary code execution, and escalation of a local user's privileges to full root. The supplied impact assessment classifies confidentiality, integrity, and availability impact as high, with scope remaining within the affected host's security authority. Root access could allow modification of system files, access to protected data, alteration of security controls, or service disruption, although the exact consequences depend on the host and its data. The key limiting condition is that the attacker needs local access and a matching snap-confine configuration; the available evidence does not establish a remote attack path.

Successful exploitation can turn a low-privileged local account into full administrative control of the host. Depending on the compromised system, that control could expose protected data, alter system software or security configuration, and disrupt services. The risk is more significant on hosts that allow untrusted users or workloads to execute locally.

Ubuntu 22.04 LTS, 24.04 LTS, and 26.04 LTS systems should receive priority for verification and patching. The Ubuntu update notice indicates that a reboot is required after the standard update, so remediation should be planned as a maintenance activity. The returned evidence does not identify a specific campaign, victim, or breach associated with exploitation.

1. Update snapd through the official update channel and use the branch-specific fixed package: 2.76+ubuntu26.04.3 for Ubuntu 26.04 LTS, 2.76+ubuntu24.04.1 for Ubuntu 24.04 LTS, or 2.76+ubuntu22.04.1 for Ubuntu 22.04 LTS.
2. Reboot after updating, as directed by the Ubuntu update notice, so that all required changes take effect.
3. Give priority to systems where snap-confine uses set-capabilities, because this is the configuration described as specifically affected. Do not assume that every standard set-uid-root installation has the same exposure.
4. For upstream or non-Ubuntu downstream builds, compare the installed release with the vendor's confirmed fix information before declaring a specific release remediated. The available evidence does not establish one universal upstream fixed boundary for all branches.
5. If immediate updating is not possible, reduce local shell or execution access for untrusted accounts where operationally feasible, but do not treat this as a substitute for the confirmed package fixes.

1. Inventory Linux systems running snapd, identify the Ubuntu branch and installed package version, and compare them with the fixed boundaries in affected_summary.
2. Determine how snap-confine is deployed, with particular attention to whether the system uses set-capabilities or the standard set-uid-root model.
3. Review security telemetry for unexpected creation or modification of files by snap-confine at privileged locations. Treat this as precautionary monitoring, not as a confirmed IOC.
4. Do not treat the absence of suspicious events as proof that a system is unaffected; verify package state and deployment configuration directly.
5. The available evidence does not provide a specific log signature, IOC path, or detection pattern.