CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

Original Article ↗ Hacker News Discussion ↗

A newly disclosed local privilege escalation flaw in Ubuntu’s Snap infrastructure is prompting broader criticism of Snap’s design, its reliance on setuid binaries, and its use of shared `/tmp` directories that are prone to race-condition bugs. Commenters also question Canonical’s push to replace mature GNU coreutils with Rust-based alternatives in the name of safety, noting that the Rust rewrite has already produced serious vulnerabilities and may have been adopted prematurely. Many suggest simpler or alternative approaches—such as traditional package management, Flatpak, Debian, or other distros—as ways to reduce attack surface and avoid Snap’s growing complexity.

Rust coreutils vulnerability & Ubuntu’s “oxidation” strategy

  • Qualys found a race condition in the Rust uutils coreutils rm, shipped by default in Ubuntu 25.10; it could have enabled local root escalation but was mitigated by swapping back to GNU rm.
  • Some argue this shows Canonical rushed Rust utilities into production assuming safety because “it’s Rust,” without enough security review.
  • Others say new software naturally has more bugs early on; a spike in vulnerabilities is expected and should be judged over a longer time horizon.
  • Debate:
    • One side: GNU coreutils has decades of battle‑hardening and relatively few CVEs; replacing it increases current risk.
    • Other side: Rust’s safety model should eventually yield fewer bugs; making uutils the default accelerates that maturation.

Limits of Rust and nature of race conditions

  • Several comments stress that Rust cannot prevent all race conditions, especially those across processes, filesystems, or system boundaries.
  • Distinction made between “data races” (which safe Rust prevents) and broader logic or TOCTOU races (which any language can suffer).
  • Some frustration with overblown “Rust will fix security” narratives; core message: language helps, but system‑level design and programmer discipline are crucial.

Snap, systemd‑tmpfiles, and /tmp design

  • Core flaw discussed: a predictable, world‑writable path under /tmp used by a root process (snap-confine with systemd‑tmpfiles cleanup) enables a race for privilege escalation.
  • Commenters note similar /tmp timing/permission bugs predate snap/systemd; the underlying pattern is not new.
  • Suggested mitigations: user‑specific temp dirs, tighter ownership checks (e.g., open + fstat + *at syscalls), or using /run/user/$UID and private /tmp features that systemd already provides.
  • Some ask why snap doesn’t use those safer mechanisms; this is left unclear.

Privilege escalation, suid, and alternatives

  • Debate over whether suid should be considered a design mistake and disabled.
  • One camp: suid repeatedly leads to local root exploits; prefer privileged daemons plus IPC or tightly scoped sudo rules.
  • Counterpoint: any solution still runs code as root; a small, well‑audited suid helper can be safer than complex daemons or large frameworks.

Broader reactions to Snap and distros

  • Multiple commenters dislike Snap’s complexity, performance, security surface, and closed distribution story; some disable snapd entirely.
  • Alternatives suggested: Debian (often with XFCE), Devuan, Pop!_OS, Fedora, or Arch.
  • Some view Snap as contradicting Ubuntu’s earlier values and prefer Flatpak or traditional packaging.