CVE-2024-5300: Canonical snapd Auth Bypass Vulnerability

CVE-2024-5300 Overview

CVE-2024-5300 is an access control bypass and information disclosure vulnerability in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules in /etc/apparmor.d/abstractions/nss-systemd allow strictly confined snap applications to communicate with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. A strictly confined snap running as root can query the Varlink interface exposed by systemd-userdbd and retrieve complete user records, including hashed passwords sourced from /etc/shadow. The flaw is categorized under [CWE-212] (Improper Removal of Sensitive Information Before Storage or Transfer).

Critical Impact
A compromised strictly confined snap executing code as root can exfiltrate all system password hashes, breaking the intended snap sandbox boundary.

Affected Products

Canonical snapd (base AppArmor security profile configuration)
Systems where systemd-userdbd is installed and operational
Ubuntu deployments that have enabled the userdb service (not default)

Discovery Timeline

2026-07-21 - CVE-2024-5300 published to NVD
2026-07-22 - Last updated in NVD database

Technical Details for CVE-2024-5300

Vulnerability Analysis

The vulnerability originates in the AppArmor abstraction file nss-systemd, which snapd inherits into its base profile for strictly confined snaps. This abstraction grants read and write access to the Varlink sockets io.systemd.Multiplexer and io.systemd.NameServiceSwitch located under /run/systemd/userdb/. Strictly confined snaps are not supposed to reach the account-control interface, yet the abstraction silently permits socket-level interaction with the user database service.

On hosts where systemd-userdbd is running, the service treats any caller with effective UID 0 as an unconfined administrator. It does not consult AppArmor context or namespace metadata to determine whether the caller is a host root process or a root process inside a snap sandbox. When queried, systemd-userdbd returns complete user records that include the hashed password field pulled from /etc/shadow.

Root Cause

The root cause is a mismatch between two access control layers. AppArmor confines the snap process but exposes the Varlink socket through an overly broad abstraction. systemd-userdbd performs identity checks based only on UID and does not validate that the caller is outside a mandatory access control sandbox. The result is a confused-deputy condition where a confined snap inherits the privileges of host root for the purpose of user database queries.

Attack Vector

An attacker requires a strictly confined snap that runs a daemon or configuration hook as root inside the sandbox. This is a local, low-privileged prerequisite. The malicious or compromised snap opens a client connection to /run/systemd/userdb/io.systemd.Multiplexer, issues a Varlink io.systemd.UserDatabase.GetUserRecord call for each known user, and reads the returned JSON records. The privileged fields include the shadow password hashes, which can be exported for offline cracking against /etc/shadow policies.

No verified public exploit code is available. See the Ubuntu Security Advisory CVE-2024-5300 for authoritative technical details.

Detection Methods for CVE-2024-5300

Indicators of Compromise

Snap-confined processes opening connections to /run/systemd/userdb/io.systemd.Multiplexer or /run/systemd/userdb/io.systemd.NameServiceSwitch
Varlink GetUserRecord calls originating from any child of snap-confine or a snap application cgroup
Unexpected reads of user records where the caller's AppArmor label matches snap.*
systemd-userdbd audit entries showing enumeration of every local user account within a short interval

Detection Strategies

Enable AppArmor audit logging and monitor for apparmor="ALLOWED" events involving nss-systemd from snap profiles
Correlate systemd-userdbd journal entries with the peer PID's cgroup to flag callers under snap.slice
Deploy Linux endpoint telemetry that captures UNIX socket connect() events, process ancestry, and AppArmor context for each syscall
Alert on any non-root-namespace process reading multiple passwd entries via Varlink within a bounded time window

Monitoring Recommendations

Track presence and status of the systemd-userdbd.service and systemd-userdbd.socket units across the fleet
Baseline the set of installed strictly confined snaps and monitor for new snaps that request root-executing hooks or daemons
Forward auditd and journald events to a centralized data lake for retrospective hunting on Varlink socket access patterns

How to Mitigate CVE-2024-5300

Immediate Actions Required

Apply the updated snapd package from the Ubuntu archive as soon as it is available for your release channel
Audit whether systemd-userdbd.service and systemd-userdbd.socket are enabled; disable them if the userdb NSS backend is not required
Inventory all installed strictly confined snaps that run root daemons or configuration hooks and review their publishers
Rotate local user passwords on any host where a suspicious snap has been present and userdb was active

Patch Information

Canonical has published tracking and fix information in the Ubuntu Security Advisory CVE-2024-5300. The remediation removes the overly permissive Varlink socket rules from the nss-systemd AppArmor abstraction inherited by the snap base profile. Apply the fixed snapd package on all Ubuntu systems and reload AppArmor profiles after the upgrade.

Workarounds

Mask the systemd-userdbd.socket and systemd-userdbd.service units with systemctl mask on hosts that do not require the Varlink user database
Add a local AppArmor override that denies unix access to /run/systemd/userdb/** from snap profiles until the vendor patch is deployed
Avoid installing strictly confined snaps from untrusted publishers on hosts where systemd-userdbd is active

bash

# Disable systemd-userdbd as a temporary mitigation
sudo systemctl stop systemd-userdbd.socket systemd-userdbd.service
sudo systemctl mask systemd-userdbd.socket systemd-userdbd.service

# Verify no snap process retains access to the Varlink sockets
sudo ss -xlp | grep '/run/systemd/userdb'

# Reload AppArmor profiles after applying the snapd update
sudo systemctl reload apparmor