A local privilege escalation vulnerability exists in snap-confine

CVE-2026-8933 is a local privilege escalation in snap-confine, the sandbox helper shipped with Canonical's snapd. Qualys chained two race conditions that appeared when Canonical hardened snap-confine from *setuid-root* to a *set-capabilities* model: because the binary now runs with the caller's UID (but with CAP_SYS_ADMIN-class capabilities retained), the scratch directories it creates in /tmp are momentarily owned by the attacker. A FUSE mount over that scratch dir plus a symlink/permission race lets the attacker plant a rogue file into /run/udev/rules.d/, and a subsequent FUSE cycle triggers systemd-udevd to execute arbitrary commands as root. Affected: default installs on Ubuntu 24.04, 25.10, 26.04, plus older LTS with snapd (16.04/18.04/20.04/22.04 via ESM/updates). Patched versions: snapd 2.76+ubuntu24.04.1, 2.76+ubuntu26.04.3, 2.76+ubuntu22.04.1, and ESM backports for older LTS.

Vendor HIGH / 7.8 is defensible on paper — it's AV:L/PR:L with full CIA impact — but for a fleet of 10,000 hosts the practical severity depends entirely on who has an interactive shell. Ubuntu Desktop with untrusted users? This is a real HIGH. Fleet of headless server VMs with no interactive users, no snapd installed, or snapd removed on the golden image? This is *noise*. Most enterprise Ubuntu Server fleets don't install snapd at all, and where it exists the attacker prerequisite (local shell as a non-root user) already implies prior compromise. Net: downgrade to MEDIUM for typical server fleets, keep at HIGH for shared-shell or student/dev workstation estates.

Why this verdict

• Local-only attack vector (AV:L) — the vector string honestly reflects that the attacker must already be executing code on the box. This removes the internet-exposure risk that drives most HIGH/CRITICAL calls.
• Prerequisite implies prior compromise on server fleets — on a headless production Ubuntu Server, an unprivileged local shell means the intrusion clock already started. This chain is the *second* stage, not the first.
• Installed-base narrowing — Ubuntu minimal cloud images (ubuntu-minimal, most container base images, AWS/GCP/Azure minimal images) ship without snapd. On those hosts the vuln is *unreachable*. Qualys' own writeup pins impact to Ubuntu Desktop defaults.
• Role multiplier — workstation / dev sandbox: chain succeeds, blast radius = single host. No fleet amplification. This is the modal case.
• Role multiplier — line-of-business Ubuntu Server: chain succeeds *if* snapd is present and an unprivileged user has a shell; blast radius = single host with credentialed pivot potential (SSH keys, cloud IAM tokens, k8s kubeconfig). Meaningful but bounded.
• Role multiplier — high-value roles (domain controller, IdP, hypervisor, PAM, CI runner): none of these are canonically Ubuntu-with-snapd. CI runners are the one plausible high-value analogue (GitHub Actions self-hosted, GitLab Runner on Ubuntu) — if a build job can drop this exploit, root on the runner = supply-chain pivot. That scenario keeps the floor at HIGH *for CI runner fleets specifically*, but does not lift the general verdict, because CI runners are <10% of the affected component's install base.
• EDR safety net — udevd spawning bash/curl/nc is a signature detection layup for any competent EDR.

Why not higher?

HIGH would be appropriate if this were remotely reachable or if snapd were canonically deployed on identity/hypervisor/CI infrastructure. Neither holds: AV:L and the affected component is a desktop-oriented sandbox helper. Multi-user shared-shell environments (universities, HPC clusters, jump boxes) *should* treat this as HIGH — bump the verdict locally in those estates.

Why not lower?

LOW / IGNORE would ignore that this is a reliable, low-complexity path from unprivileged shell to root on default Ubuntu Desktop, published by a team (Qualys TRU) that reliably ships weaponizable exploits within days. Any environment with shared interactive access, student accounts, or CI runners must patch on the HIGH timeline.

1. Refresh snapd on all Ubuntu hosts within 30 days — Run sudo snap refresh snapd core and sudo apt install --only-upgrade snapd. Snap auto-refresh will handle most hosts within 24h — verify the minority that disabled it. Deploy within the noisgate mitigation SLA of 30 days for HIGH-tier assets (multi-user, CI runners); MEDIUM assets fall under the 365-day remediation window.
2. Inventory which hosts actually have snapd installed — Run dpkg -l snapd or rpm -q snapd fleet-wide. Any host without snapd is not affected — this dramatically narrows the patching universe on server fleets. Do this in the first 48 hours to size the actual exposure.
3. Remove snapd from headless server golden images — If snapd is not required (most server workloads don't need it), apt purge snapd && apt-mark hold snapd on the base image. Eliminates this class of vuln permanently. Roll into next image-baking cycle (~30 days).
4. Disable unprivileged FUSE mounts on hardened hosts — Remove user_allow_other from /etc/fuse.conf, set kernel sysctl kernel.unprivileged_userns_clone=0 where feasible. Breaks step 2 of the chain and blocks a broader class of container-escape / LPE primitives. 7-day window on jump boxes and shared-shell hosts.
5. Add auditd rule watching /run/udev/rules.d/ writes and udevd exec children — -w /run/udev/rules.d/ -p wa -k udev_rule_tamper plus a rule on execve where the parent comm is systemd-udevd. Any write by non-root or udevd spawning a shell is a fire-alarm event. Deploy in 3-7 days as a durable detection.
6. Force-enable AppArmor enforce mode for snap-confine — Verify aa-status | grep snap-confine shows enforce, not complain. Some hardening tools drop AppArmor to complain — that widens the attack surface for step 3. Verify in 7 days.

Run on each target Ubuntu host as a normal user (no sudo required for the read-only checks). Example: ./check-cve-2026-8933.sh. Exits 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN / snapd not installed.

#!/usr/bin/env bash
# check-cve-2026-8933.sh — noisgate verification for snap-confine LPE
# Determines whether the running snapd package is at or above the fixed version
# for this host's Ubuntu release.
set -u

if ! command -v dpkg >/dev/null 2>&1; then
  echo 'UNKNOWN: dpkg not available (non-Debian host?)'
  exit 2
fi

if ! dpkg -l snapd 2>/dev/null | grep -q '^ii'; then
  echo 'PATCHED: snapd not installed — CVE-2026-8933 not applicable'
  exit 0
fi

INSTALLED=$(dpkg-query -W -f='${Version}' snapd 2>/dev/null)
RELEASE=$(. /etc/os-release; echo "$VERSION_ID")

case "$RELEASE" in
  16.04) FIXED='2.61.4ubuntu0.16.04.1+esm4' ;;
  18.04) FIXED='2.61.4ubuntu0.18.04.1+esm4' ;;
  20.04) FIXED='2.67.1+20.04ubuntu1~esm3'   ;;
  22.04) FIXED='2.76+ubuntu22.04.1'         ;;
  24.04) FIXED='2.76+ubuntu24.04.1'         ;;
  25.10) FIXED='2.76+ubuntu25.10.1'         ;;
  26.04) FIXED='2.76+ubuntu26.04.3'         ;;
  *)     echo "UNKNOWN: unrecognized Ubuntu release $RELEASE (installed=$INSTALLED)"; exit 2 ;;
esac

# dpkg --compare-versions returns 0 if the relation holds
if dpkg --compare-versions "$INSTALLED" ge "$FIXED"; then
  echo "PATCHED: snapd $INSTALLED >= $FIXED (Ubuntu $RELEASE)"
  exit 0
else
  echo "VULNERABLE: snapd $INSTALLED < $FIXED (Ubuntu $RELEASE) — CVE-2026-8933"
  exit 1
fi

Sources

1. Qualys TRU — CVE-2026-8933 technical writeup
2. Ubuntu Security — snapd multiple vulnerabilities fixed
3. Debian Security Tracker — CVE-2026-8933
4. Qualys TRU — CVE-2026-3888 (sibling snap-confine LPE, March 2026)
5. oss-security — snap-confine + systemd-tmpfiles = root (CVE-2026-3888 background)
6. Elastic Security — detection rule for snap-confine LPE
7. The Hacker News — Ubuntu snap-confine root escalation coverage
8. ITBrief — Ubuntu snap-confine flaw grants root