Canonical snapd AppArmor profile bypass exposes system password hashes

An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox, such as a daemon or configuration hook. Because systemd-userdbd returns "complete" user records, including sensitive hashed user passwords from /etc/shadow, when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.

The recorded affected scope is:

• Generic snapd package: versions from 0 through less than 2.76.1 are marked affected under the CNA's semver range. The affected product record retains default_status as unaffected, so distribution-specific package status should take precedence over applying the generic range mechanically.
• Canonical Ubuntu 26.04 LTS: fixed in 2.76+ubuntu26.04.3.
• Canonical Ubuntu 24.04 LTS: fixed in 2.76+ubuntu24.04.1.
• Canonical Ubuntu 22.04 LTS: fixed in 2.76+ubuntu22.04.1.
• Canonical Ubuntu 20.04 LTS: fixed in 2.67.1+20.04ubuntu1~esm3; the fix is available through Ubuntu Pro.
• Canonical Ubuntu 18.04 LTS: fixed in 2.61.4ubuntu0.18.04.1+esm4; the fix is available through Ubuntu Pro.
• Canonical Ubuntu 16.04 LTS: fixed in 2.61.4ubuntu0.16.04.1+esm4; the fix is available through Ubuntu Pro and requires the Legacy Support add-on.

Ubuntu also lists the interim releases that have reached end of life as ignored and does not provide maintained fixed-status guidance for those branches.

Canonical snapd contains a flaw in its base AppArmor security profile configuration. Rules in the /etc/apparmor.d/abstractions/nss-systemd abstraction inadvertently allow strictly confined snap applications to access the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/, even though those applications lack the privileged account-control interface.

The main precondition is a compromised or malicious snap that can execute code as root, such as code running in a daemon or configuration hook. When systemd-userdbd is installed and operational, the service does not distinguish between an unconfined root user on the host and a restricted root user inside the snap sandbox. A root process in the snap can therefore query the Varlink interface and receive complete user records, including password hashes from /etc/shadow.

The confirmed effect is a bypass of the intended AppArmor boundary that exposes sensitive data from the host's user database service. The record does not specify the exact rule change or internal implementation detail used to correct the behavior, so additional implementation details should not be inferred.

The issue is locally reachable through UNIX domain sockets on the host and is not, by itself, an independent remote network attack path. An attacker needs a compromised or malicious strictly confined snap that can execute code as root; the recorded attack complexity is high, no user interaction is required, and the initial privilege requirement is low.

The requirement for systemd-userdbd to be installed and operational materially limits exposure. The supplied record does not identify a public exploit and does not record a known-exploited status; that absence should not be treated as proof that exploitation has never occurred.

The technical outcome is that a root process inside a snap sandbox can read user records from a host service, including sensitive password hashes. This is a cross-boundary confidentiality impact because host data becomes accessible from an application that was intended to remain confined.

The issue does not establish direct data modification or service disruption, and it does not by itself prove that plaintext passwords are obtained. However, the hashes could support offline cracking or password-reuse attacks, which may lead to unauthorized access to local accounts when credentials are weak or reused.

The impact is limited by the requirement for root-executing code inside a snap and by the requirement that systemd-userdbd be installed and operational. Standard Ubuntu deployments do not install that service by default, but systems that add or enable it should be prioritized for review.

The flaw can expose all system password hashes to root code running inside a snap that is otherwise restricted by sandboxing. This is a disclosure across the protection boundary between a snap application and the host user database service.

Password hashes are not the same as plaintext passwords, but stolen hashes can support offline password cracking when password choices or hashing protections are weak. Hash disclosure can increase the risk of local account compromise and credential reuse, but the record does not establish that account takeover, data modification, or service disruption occurred. Actual exposure depends on systemd-userdbd being installed and operational and on a snap containing compromised or malicious root-level code.

1. Update snapd to the confirmed branch-specific package boundary: 2.76+ubuntu26.04.3 for Ubuntu 26.04 LTS, 2.76+ubuntu24.04.1 for Ubuntu 24.04 LTS, and 2.76+ubuntu22.04.1 for Ubuntu 22.04 LTS.
2. For Ubuntu 20.04 LTS, use 2.67.1+20.04ubuntu1~esm3 through Ubuntu Pro. For Ubuntu 18.04 LTS, use 2.61.4ubuntu0.18.04.1+esm4 through Ubuntu Pro. For Ubuntu 16.04 LTS, use 2.61.4ubuntu0.16.04.1+esm4 through Ubuntu Pro with the Legacy Support add-on.
3. When managing the generic snapd package rather than an Ubuntu backport, update to the 2.76.1 boundary because versions below that boundary are in the published affected semver range. Do not treat this generic boundary as a substitute for the Ubuntu backport versions.
4. After updating, verify that the installed package belongs to the intended Ubuntu branch and meets that branch's fixed boundary. Also check whether systemd-userdbd is installed and operational to determine remaining exposure.
5. If an update is not immediately possible, prioritize identifying snaps that can execute code as root and assess whether systemd-userdbd is required. The service not being installed by default on standard Ubuntu deployments reduces exposure, but the record does not provide a vendor-confirmed temporary configuration workaround.
6. If there is evidence that password hashes were accessed, treat the local hashes as exposed and initiate the organization's credential-response process. Do not use the absence of log evidence as proof that the hashes were not read.

Perform the following checks:

1. Inventory snapd packages by Ubuntu release and compare them with the fixed boundaries in the affected summary.
2. Determine whether systemd-userdbd is installed and operational, and check for the sockets under /run/systemd/userdb/.
3. Identify strictly confined snaps with daemons or configuration hooks that execute code as root, because this is a key precondition in the described attack path.
4. Inspect the effective AppArmor profile and the /etc/apparmor.d/abstractions/nss-systemd abstraction to determine whether the snap can access io.systemd.Multiplexer or io.systemd.NameServiceSwitch.
5. Host and systemd-userdbd telemetry related to access to these sockets can be reviewed as a precaution. No specific log event or IOC is provided, and the absence of such evidence does not prove that the system is safe.