Local privilege escalation in snapd on Linux

CVE-2026-3888 is a local privilege escalation in Ubuntu's snapd, specifically the interaction between snap-confine and systemd-tmpfiles. The published CVE record says Ubuntu 16.04/18.04/20.04/22.04/24.04 LTS are affected, but Canonical's own March 17, 2026 advisory is more operationally useful: default installations of Ubuntu 24.04 LTS and Ubuntu 25.10 are the real exposure center, while older LTS releases received hardening because some non-default configurations could also be vulnerable. Fixed package lines include 2.73+ubuntu24.04.1 for noble and 2.73+ubuntu25.10.1 for questing, with backports for older LTS streams and upstream hardening planned in snapd 2.75.1.

The vendor's HIGH 7.8 score is technically defensible because successful exploitation ends in root, but it overstates enterprise urgency if you are triaging patch queues across 10,000 hosts. This is not initial access and not remote; the attacker already needs a local foothold with code execution, the vulnerable population is skewed toward Ubuntu desktop/dev endpoints rather than broad server fleets, and the exploit chain adds unusual friction by depending on systemd-tmpfiles cleanup timing and controlled re-creation of snap sandbox state. That combination pushes this down to a MEDIUM operational priority, not because the impact is small, but because the reachable population and attacker prerequisites are.

Why this verdict

• Downgrade for attacker position: exploitation starts at *local unprivileged user*, which implies the attacker is already on the endpoint. That is a major real-world severity reduction versus remote or pre-auth bugs.
• Downgrade for exposure population: Canonical's own March 17, 2026 note says default impact centers on Ubuntu 24.04 LTS and Ubuntu 25.10, not every Ubuntu server in the estate. In many enterprises, that means developer workstations and desktops, not the full Linux fleet.
• Downgrade for exploit friction: the chain depends on systemd-tmpfiles cleanup timing, recreation of a deleted sandbox directory, and a race during snap-confine setup. This is exactly the kind of high-complexity, long-dwell exploit path that breaks outside clean lab conditions.
• Keep it above LOW for blast radius: if it works, the attacker reaches host root, not a sandbox-limited nuisance. On engineering laptops and admin workstations, that can mean credential theft, EDR tampering, and lateral movement.

Why not higher?

This is not unauthenticated, not remote, not wormable, and not broadly exposed to the internet. The exploit path also asks for unusual patience and timing, which sharply narrows who can operationalize it at scale. No KEV listing and extremely low EPSS reinforce that this is not behaving like an urgent internet-burn event.

Why not lower?

A successful exploit produces real root compromise, and snapd is common enough on Ubuntu endpoints that you cannot hand-wave it away as theoretical. If you run Ubuntu developer desktops or shared jump hosts with local users, this is still a meaningful post-compromise privilege-escalation risk.

1. Restrict local shell access — Reduce who can reach the first prerequisite at all: review SSH, VDI, bastion, student/lab, and contractor access to Ubuntu hosts running snapd. For a MEDIUM verdict there is no mitigation SLA, but this is still the best immediate risk reducer while you work through the 365-day remediation window.
2. Monitor snap temporary paths — Alert on non-root creation or modification of /tmp/.snap and /tmp/snap-private-tmp/*/tmp/.snap, plus suspicious snap-confine execution bursts. Use the Elastic analytic or equivalent EDR rule logic; deploy as soon as feasible because detection is more realistic than blanket prevention here.
3. Hunt for unexpected SUID artifacts — Scan for new or recently changed SUID-root binaries, especially under /var/snap/*/common/, and correlate them with low-privilege user activity. This catches the breakout stage that turns sandboxed root into host root.
4. Prioritize desktop and dev images — If patch capacity is limited, start with Ubuntu 24.04 LTS desktops, VDI pools, shared engineering workstations, and any host where multiple users can execute code locally. That matches the real exposure center better than patching every headless Ubuntu server first.

Run this on the target Ubuntu host as any local user; sudo is not required because it only reads package metadata and OS release info. Save as check-cve-2026-3888.sh and run bash check-cve-2026-3888.sh — it prints VULNERABLE, PATCHED, or UNKNOWN and exits with 0, 1, or 2 respectively.

#!/usr/bin/env bash
# check-cve-2026-3888.sh
# Detect likely exposure to CVE-2026-3888 on Ubuntu systems by comparing
# installed snapd version to Canonical fixed package versions from USN-8102-1.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

print_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

print_vuln() {
  echo "VULNERABLE: $1"
  exit 1
}

print_patched() {
  echo "PATCHED: $1"
  exit 0
}

if ! command -v dpkg-query >/dev/null 2>&1; then
  print_unknown "dpkg-query not found; this script supports Debian/Ubuntu package checks only"
fi

if [ ! -r /etc/os-release ]; then
  print_unknown "/etc/os-release not readable"
fi

# shellcheck disable=SC1091
. /etc/os-release

if [ "${ID:-}" != "ubuntu" ]; then
  print_unknown "OS is '${ID:-unknown}', not Ubuntu"
fi

if ! dpkg-query -W -f='${Status} ${Version}\n' snapd >/tmp/check-cve-2026-3888.$$ 2>/dev/null; then
  print_unknown "snapd package is not installed"
fi

pkg_line=$(cat /tmp/check-cve-2026-3888.$$)
rm -f /tmp/check-cve-2026-3888.$$

case "$pkg_line" in
  "install ok installed "*) : ;;
  *) print_unknown "snapd package is not in installed state: $pkg_line" ;;
esac

installed_version=$(printf '%s' "$pkg_line" | awk '{print $4}')
series="${VERSION_ID:-unknown}"
fixed_version=""
notes=""

case "$series" in
  "25.10")
    fixed_version="2.73+ubuntu25.10.1"
    notes="Default-impact release per Canonical"
    ;;
  "24.04")
    fixed_version="2.73+ubuntu24.04.1"
    notes="Default-impact release per Canonical"
    ;;
  "22.04")
    fixed_version="2.73+ubuntu22.04.1"
    notes="Backported hardening for non-default vulnerable configurations"
    ;;
  "20.04")
    fixed_version="2.67.1+20.04ubuntu1~esm1"
    notes="Backported hardening via Ubuntu Pro/ESM for non-default vulnerable configurations"
    ;;
  "18.04")
    fixed_version="2.61.4ubuntu0.18.04.1+esm2"
    notes="Backported hardening via Ubuntu Pro/ESM for non-default vulnerable configurations"
    ;;
  "16.04")
    fixed_version="2.61.4ubuntu0.16.04.1+esm2"
    notes="Backported hardening via Ubuntu Pro/ESM for non-default vulnerable configurations"
    ;;
  *)
    print_unknown "Ubuntu version ${series} is not covered by USN-8102-1 mapping"
    ;;
esac

if dpkg --compare-versions "$installed_version" ge "$fixed_version"; then
  print_patched "snapd ${installed_version} >= fixed ${fixed_version} on Ubuntu ${series} (${notes})"
else
  print_vuln "snapd ${installed_version} < fixed ${fixed_version} on Ubuntu ${series} (${notes})"
fi

Sources

1. Ubuntu CVE record
2. Ubuntu USN-8102-1
3. Ubuntu security notice discussion
4. Qualys blog analysis
5. Qualys full advisory
6. NVD entry
7. Elastic detection rule
8. CISA KEV catalog