A path traversal vulnerability in LXD's instance template processing allows an attacker with container edit permissions, or any user launching a crafted image, to overwrite arbitrary files on the host system as root. When processing target template paths specified in metadata.yaml, LXD validates the path against a confined os.Root directory handle but subsequently opens and creates the file using os.Create with an unconfined string path. This discrepancy between path resolution checks and file creation allows an attacker to escape directory confinement, overwrite root-owned host files, and achieve host root code execution.

Path traversal in apport-unpack in Canonical Apport before 2.36.0, 2.34.2, and 2.28.4 on Linux allows an attacker to create or overwrite arbitrary files with the privileges of the executing user via an attacker controlled key names in crash report files.

A path traversal vulnerability in LXD allows an attacker to manipulate file system paths during backup import and restore operations. When importing or restoring a backup archive, LXD fails to validate instance and storage volume names contained within the archive metadata. An attacker can exploit this flaw by supplying a crafted backup archive with malicious instance or volume names containing path traversal sequences, potentially allowing file access or overwriting outside the designated restore directory.

A link following vulnerability in LXD allows an attacker to achieve arbitrary file read and write operations on the host system. When importing or unpacking an image archive, LXD fails to validate whether the metadata.yaml file is a symbolic link. An attacker can exploit this flaw by providing a crafted image archive with a symlinked metadata.yaml file pointing to target file paths on the host system.

A link following vulnerability in LXD allows an attacker to achieve root command execution on the host system. During the import or unpacking of crafted image or backup archives, LXD fails to properly validate and confine the backup.yaml file when it exists as a symbolic link. An attacker can exploit this flaw by providing a malicious archive with a symlinked backup.yaml file, causing LXD to process unconfined configuration metadata and execute arbitrary commands with root privileges.

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass project-level container isolation restrictions. When a project is configured with restrictions on container privileges (such as enforcing restricted.containers.privilege=isolated), LXD fails to enforce the requirement if an instance configuration omits the security.idmap.isolated key. An attacker can exploit this flaw by creating or updating an instance without explicitly setting security.idmap.isolated, bypassing the target project's security constraints.

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass target project restrictions during instance migration. When migrating an instance to a target project, LXD accepts configuration overrides without validating the new configuration against the target project's enforced restrictions. An attacker can exploit this flaw to move instances with disallowed high-privilege configurations into restricted projects, bypassing security controls.

An authorization bypass vulnerability in LXD due to a timing flaw during configuration merging allows an authenticated attacker to bypass target project restrictions during cross-project instance copies. When copying an instance to a target project, LXD performs restriction checks before configuration merging is complete, creating a time-of-check to time-of-use (TOCTOU) condition. An attacker can exploit this flaw to copy instances with disallowed high-privilege configurations into restricted projects, bypassing security controls.

An authorization bypass vulnerability in LXD allows an authenticated user to bypass project-level disk and volume limits. Two related code paths fail to verify resource limits during volume operations: the storagePoolVolumeTypePostMove function omits the limits.AllowVolumeCreation check before moving a volume across projects, and volume snapshot restore operations skip the AllowVolumeUpdate check when the configuration is nil (Config == nil). An attacker can exploit these flaws to allocate storage resources that exceed the administrative limits configured for a project.

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass target project security restrictions during cross-project instance migrations. When moving an instance cross-project to a different cluster member via POST /1.0/instances/{name} with migration: true, project: <target>, and target: <member>, the destination node skips all project restriction checks because the request arrives as an internal cluster notification. An attacker can exploit this to introduce disallowed instance configurations into a restricted project.

IBM Informix Dynamic Server 14.10, and 15.0 contain a local privilege escalation vulnerability in the oninit setuid-root utility.

IBM Informix could allow an unauthenticated user to execute arbitrary commands with service account privileges on the system due to improper validation of user supplied input.

Qualys Security Advisory

Local Privilege Escalation in set-capabilities versions of snap-confine (CVE-2026-8933)

======================================================================== Contents ========================================================================

Summary Analysis Exploitation Acknowledgments Timeline

======================================================================== Summary ========================================================================

We discovered a vulnerability (a Local Privilege Escalation from any user to full root) in snap-confine, "a program used internally by snapd to construct the execution environment for snap applications."

Counter-intuitively, only set-capabilities versions of snap-confine are vulnerable, set-uid-root versions are not; in particular:

- default installations of Ubuntu Desktop 26.04 and 25.10 are vulnerable and exploitable (they ship a set-capabilities /usr/lib/snapd/snap-confine);

- default, up-to-date installations of Ubuntu Desktop 24.04 are also vulnerable and exploitable (they ship a set-capabilities /snap/snapd/current/usr/lib/snapd/snap-confine).

======================================================================== Analysis ========================================================================

After the publication of CVE-2026-3888 and the release of Ubuntu 26.04 Beta, we decided to re-assess the security of snap-confine. One of the most fundamental changes between Ubuntu 24.04 and Ubuntu 26.04 is that /usr/lib/snapd/snap-confine is not set-uid-root anymore; instead, it is set-capabilities now, undoubtedly for security reasons (the Principle of Least Privilege):

------------------------------------------------------------------------ $ cat /etc/os-release PRETTYNAME="Ubuntu Resolute Raccoon (development branch)" VERSIONID="26.04"

$ stat /usr/lib/snapd/snap-confine Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

$ getcap /usr/lib/snapd/snap-confine /usr/lib/snapd/snap-confine capchown,capdacoverride,capdacreadsearch,capfowner,capsetgid,capsetuid,capsyschroot,capsysptrace,capsysadmin,capsysresource=p ------------------------------------------------------------------------

------------------------------------------------------------------------ $ cat /etc/os-release PRETTYNAME="Ubuntu 24.04.3 LTS"

$ stat /usr/lib/snapd/snap-confine Access: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

$ stat /snap/snapd/current/usr/lib/snapd/snap-confine Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

$ getcap /snap/snapd/current/usr/lib/snapd/snap-confine /snap/snapd/current/usr/lib/snapd/snap-confine capchown,capdacoverride,capdacreadsearch,capfowner,capsyschroot,capsysptrace,capsysadmin=p ------------------------------------------------------------------------

Unfortunately, belatedly we realized that this change has a potentially dangerous consequence: because snap-confine is not set-uid-root anymore, it runs with the effective uid of our unprivileged user (but with near- root capabilities), and all the files and directories that it creates therefore do not belong to root anymore, but to our unprivileged user.

For example, snap-confine creates a /tmp/snap.rootfsXXXXXX directory at line 511, and a file inside this directory at line 450, and even though snap-confine quickly changes the ownership of this directory and file to root at lines 362 and 454, a small window of time exists when they are under the complete control of our unprivileged user (between lines 511 and 362, and between lines 450 and 454):

------------------------------------------------------------------------ 507 static void scbootstrapmountnamespace(const struct scmountconfig config) { 508 char scratchdir[] = "/tmp/snap.rootfsXXXXXX"; ... 511 if (mkdtemp(scratchdir) == NULL) { ... 523 scdomount(scratchdir, scratchdir, NULL, MSBIND, NULL); ... 530 scdomount("none", scratchdir, NULL, MSUNBINDABLE, NULL); ... 535 scdomount("none", scratchdir, "tmpfs", 0, "uid=0,gid=0"); 536 screplicatebaserootfs(scratchdir, config->rootfsdir, config->mounts); ------------------------------------------------------------------------ 354 static void screplicatebaserootfs(const char scratchdir, const char rootfsdir, 355 const struct scmount rootmounts) { ... 362 if (chown(scratchdir, 0, 0) < 0) { ... 397 scmustsnprintf(fullpath, sizeof(fullpath), "%s/%s", scratchdir, ent->dname); ... 446 } else if (ent->dtype == DTREG) { ... 450 int fd = open(fullpath, OCREAT | OTRUNC, 0644); ... 454 if (fchown(fd, 0, 0) < 0) { ------------------------------------------------------------------------

======================================================================== Exploitation ========================================================================

Our basic idea for exploiting this vulnerability is to transform it into an arbitrary file creation, by winning these two race conditions:

- first, immediately after the creation of the /tmp/snap.rootfsXXXXXX directory at line 511, and while this directory still belongs to our unprivileged user, we quickly create a symlink inside this directory, whose target is an arbitrary file in the filesystem, and whose name is the name of one of the files that snap-confine will create at line 450 (for example, when setting up the sandbox for the firefox snap, snap-confine will create a file named default256.png);

- second, immediately after the creation of our arbitrary file at line 450 (which succeeds because this open() does not specify ONOFOLLOW, and because snap-confine runs with near-root capabilities), and while this file still belongs to our unprivileged user, we quickly change its permissions to 0666 so that we can still write to it even after snap-confine changes its ownership to root at line 454.

However, to implement this exploit in practice, we must overcome two major problems:

1/ After the creation of the /tmp/snap.rootfsXXXXXX directory at line 511, but before the creation of our arbitrary file at line 450, snap- confine mounts a temporary filesystem onto /tmp/snap.rootfsXXXXXX at line 535; but we cannot create the symlink to our arbitrary file inside this directory because it is not visible from outside the sandbox that snap-confine is setting up (because of the two mounts at lines 523 and 530, which make this temporary filesystem private).

The solution to this first problem is surprisingly simple: immediately after the creation of the /tmp/snap.rootfsXXXXXX directory, and while this directory still belongs to our unprivileged user, we quickly mount a FUSE filesystem onto it (with fusermount), which allows us to unmount (with fusermount -u -z) every filesystem that snap-confine later mounts onto it, at lines 523 and 535.

As a result, when snap-confine reaches line 450, /tmp/snap.rootfsXXXXXX is simply back to the directory that was originally created at line 511 and that still belongs to our unprivileged user: inside this directory we can create the symlink to our arbitrary file, and finally snap-confine creates this arbitrary file at line 450.

2/ In reality, this arbitrary file creation is not entirely arbitrary, because snap-confine itself is confined by a highly restrictive AppArmor profile; for example, we cannot create or write to any file in /etc. To solve this second problem we inspected snap-confine's AppArmor profile, and one of the few allow-read-write rules caught our attention:

/run/udev/ rw,

We therefore exploit our arbitrary file creation to create a .rules file in /run/udev/rules.d, write PROGRAM="/bin/sh -c id>>/tmp/pwned" into it, and mount and unmount a FUSE filesystem (any FUSE filesystem) to trigger the execution of this arbitrary command with full root privileges (via the systemd-udevd daemon):

------------------------------------------------------------------------ $ cat /etc/os-release PRETTYNAME="Ubuntu Resolute Raccoon (development branch)" VERSIONID="26.04"

$ id uid=1001(jane) gid=1001(jane) groups=1001(jane),100(users)

$ ./exploit scratch directory for constructing namespace: /tmp/snap.rootfsZW0eZT ndirs 1 nregs 0 -rw-r--r-- 1 root root 78 Apr 21 21:00 /tmp/pwned /run/udev/rules.d: total 12 -rw-rw-rw- 1 root root 36 Apr 21 21:00 2064396357-default256.png.rules -rw-r----- 1 root root 265 Apr 21 20:20 90-netplan.rules -rw-r----- 1 root root 98 Apr 21 20:20 99-netplan-enp0s3.rules uid=0(root) gid=0(root) groups=0(root) uid=0(root) gid=0(root) groups=0(root) ------------------------------------------------------------------------

------------------------------------------------------------------------ $ cat /etc/os-release PRETTYNAME="Ubuntu 24.04.3 LTS"

$ id uid=1001(jane) gid=1001(jane) groups=1001(jane),100(users)

$ ./exploit scratch directory for constructing namespace: /tmp/snap.rootfsAkYmf6 ndirs 1 nregs 0 -rw-r--r-- 1 root root 78 Apr 21 13:09 /tmp/pwned /run/udev/rules.d: total 8 -rw-rw-rw- 1 root root 36 Apr 21 13:09 429214770-default256.png.rules -rw-r----- 1 root root 162 Apr 21 12:47 90-netplan.rules uid=0(root) gid=0(root) groups=0(root) uid=0(root) gid=0(root) groups=0(root) ------------------------------------------------------------------------

======================================================================== Acknowledgments ========================================================================

We thank everyone at Canonical who worked on this release (Eduardo Barretto and Zygmunt Krynicki in particular). We also thank the members of the linux-distros list (Caryl Takvorian in particular).

======================================================================== Timeline ========================================================================

2026-04-22: We sent our advisory and exploit to the Ubuntu Security Team.

2026-07-13: The Ubuntu Security Team sent their patches to the linux-distros list.

2026-07-14: We sent our advisory to the linux-distros list.

2026-07-21: Coordinated Release Date (14:00 UTC).

Hi everyone,

Qualys discovered another Local Privilege Escalation (LPE) in snapd snap-confine, via Capabilities misconfiguration. Qualys will send an email on top of this one with their report, but in the meantime, for this vulnerability we assigned CVE-2026-8933, with CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H 7.8 HIGH

The upstream version of snapd containing the fix will be 2.76.1.

Also in this version we are fixing/disclosing other two vulnerabilities - CVE-2024-5300 AppArmor Base Profile Misconfiguration in snapd Permits Confined Snaps Unauthorized Access to Hashed Passwords via systemd-userdbd CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N 5.6 MEDIUM Credits: James Henstridge

- CVE-2026-15226 snapd snap-confine Sandbox Confinement Bypass via Omission of setuid Restriction in Seccomp Templates CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N 8.4 HIGH Credits: Zygmunt Krynicki

In Ubuntu those fixes will land in:

Xenial (16.04): snapd - 2.61.4ubuntu0.16.04.1+esm4 Bionic (18.04): snapd - 2.61.4ubuntu0.18.04.1+esm4 Focal (20.04): snapd - 2.67.1+20.04ubuntu1~esm3 Jammy (22.04): snapd - 2.76+ubuntu22.04.1 Noble (24.04): snapd - 2.76+ubuntu24.04.1 Resolute (26.04): snapd - 2.76+ubuntu26.04.3

And we will soon be publishing an advisory: https://ubuntu.com/security/notices/USN-8579-1

We want to thanks again Qualys, Zygmunt and James for their work and patience!

Thanks, Eduardo

A sandbox confinement bypass vulnerability exists in Canonical snapd within its internal execution environment compiler (snap-confine). The default seccomp security templates generated by the engine to restrict system calls do not filter or reject process operations capable of creating or manipulating file execution flags with set-user-ID attributes. Consequently, an application running within a strictly confined snap environment can successfully compile or drop binaries and apply setuid properties to them. If a compromised or malicious process inside the snap sandbox executes these generated setuid binaries, it can potentially circumvent architectural sandboxing assumptions, drop intended restriction policies, or execute privileged actions inside the container namespace that should otherwise be strictly blocked. The vulnerability has been resolved by hardening the seccomp template engine to block the execution and creation of setuid executables by sandboxed snap processes.

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.

An insecure symlink following vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools) within the pro collect-logs command framework. The utility creates or utilizes predictable temporary file paths or user-accessible log directories when gathering diagnostic information without verifying the file type or ownership. An unprivileged local attacker can exploit this behavior by creating a symbolic link (symlink) at a predictable destination path pointing to an arbitrary, root-readable file (such as /etc/shadow or private files within /root). When a root administrator or operator subsequently executes the pro collect-logs command, the tool follows the user-controlled symlink, reads the target file, and compresses its contents into the resulting diagnostic support archive. Because the output archive remains readable by the unprivileged user, the attacker can extract and read the sensitive root-owned files, leading to a complete information disclosure of system secrets.

An input validation and injection vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client constructs APT source files (such as /etc/apt/sources.list.d/ubuntu-.list or their DEB822 equivalents) using data received directly from the contract server response via the directives.suites[] and directives.aptURL fields. Because the client utilizes Python's str.format() to write these files without performing escaping, validation, or newline character filtering, a malicious or tampered contract response containing embedded newline (\n) characters can successfully inject arbitrary, attacker-controlled deb configuration lines into root-owned APT sources. When combined with the unvalidated additionalPackages[] field—which is passed positionally into a root-executed apt-get install command—an attacker capable of spoofing or manipulating the contract response (e.g., via a compromised internal infrastructure, an intercepted connection utilizing a trusted CA, or local logical bugs) can force the client to fetch and install malicious packages. This ultimately leads to arbitrary code execution with root privileges on the affected system. This component is preinstalled on supported Ubuntu Server releases and auto-attaches by default on cloud provider Ubuntu Pro images.

An information disclosure vulnerability exists in Canonical ubuntu-pro-client (formerly ubuntu-advantage-tools). The client validates Ubuntu Pro APT credentials by executing /usr/lib/apt/apt-helper using the download-file command. During this process, the secret bearer token is embedded directly in the cleartext URL component passed via the command-line arguments (argv), resulting in a URL format such as https://bearer:<token>@esm.ubuntu.com/.../. On systems utilizing a default-mounted /proc file system where process-hiding mitigations (such as hidepid) are disabled, an unprivileged local attacker can monitor system processes and read the sensitive bearer token directly from /proc/cmdline while the helper process is actively running. This leaked token can subsequently be used to gain unauthorized access to the victim's Ubuntu Pro or Expanded Security Maintenance (ESM) repositories.

In Canonical LXD versions 4.12 through 6.9, a Server-Side Request Forgery (SSRF) vulnerability in the image import functionality allows authenticated users with the cancreateimages entitlement to interact with internal network infrastructure via the /images endpoint. When importing an image from a URL source, the LXD daemon fails to validate or restrict outbound destination IP addresses, allowing connections to loopback, RFC1918 private ranges, and cloud metadata endpoints. This enables error-based port scanning and unauthorized interaction with internal HTTP services from the daemon's network position.

A privilege escalation vulnerability exists in LXD from 6.0 before 6.9, 5.21.0 before 5.21.5, and 5.0.0 before 5.0.7 regarding the handling of project-restriction policies during snapshot restoration.. An authenticated project operator in a restricted multi-tenant environment can bypass policy restrictions by importing a maliciously crafted instance backup containing restricted configuration keys within a snapshot. When the snapshot is restored, these restricted keys are applied to the live instance without policy validation. Starting the modified instance grants the operator unauthorized host root access.

Nil-pointer dereference in CreateCustomVolumeFromBackup in LXD up to version 6.8 and 5.21 on Linux allows an authenticated user with cancreatestoragevolumes permissions to cause a denial of service via a specially crafted custom-volume backup tarball that omits the expiresat snapshot field.

Broken Access Control in the devLXDInstancePatchHandler component of Canonical LXD allows an untrusted guest to mount, read, and overwrite another guest's custom storage volume via a crafted device PATCH request over /dev/lxd when security.devlxd.management.volumes is enabled.

An issue was discovered in Canonical ADSys upstream versions through v0.16.2. During Active Directory Certificate Services (AD CS) certificate auto-enrollment via the vendored Samba client script (internal/policies/certificate/python/vendorsamba/gp/gpcertautoenrollext.py), ADSys utilizes a plaintext HTTP connection (http://) instead of a secure HTTPS connection (https://) to request the CA certificate from the Active Directory Certificate Services server (GetCACert). An unauthenticated network attacker positioned between the managed Ubuntu host and the configured AD CS CA hostname can conduct a Man-in-the-Middle (MITM) attack. By intercepting the plaintext HTTP request, the attacker can supply an arbitrary, attacker-controlled Root CA certificate. Because the system automatically accepts this certificate and registers it into the local system trust store via update-ca-certificates, this results in system-wide trust store poisoning. Consequently, TLS clients utilizing the operating system trust store on the affected machine will accept rogue certificates for arbitrary domains, enabling persistent decryption and interception of subsequent TLS connections. This issue is resolved in version v0.16.3.

Canonical MicroCeph versions from the squid and tentacle track are vulnerable to a path traversal issue in the remote-import API. Holders of a trusted cluster mTLS certificate (such as enrolled cluster members) or join token can manipulate files in an imported remote cluster within the /var/snap/microceph confinement. This would allow daemon disruption and pollution of the cluster state.

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 5 June 2026