What is the CVSS score of CVE-2026-34179?

CVE-2026-34179 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of Canonical are affected by CVE-2026-34179?

CVE-2026-34179 is a critical privilege escalation flaw in Canonical LXD versions 4.12-6.7 that allows authenticated users with restricted TLS certificate permissions to escalate to cluster…. A patch is available.

How to fix or mitigate CVE-2026-34179?

Within 24 hours: inventory all LXD deployments and identify instances running versions 4.12 through 6.7; verify current version via `lxd --version`. Within 7 days: apply vendor-released patch to upgrade all affected LXD instances to version 6.8 or later; test patched versions in non-production environments first and coordinate maintenance windows to minimize cluster downtime. Within 30 days: audit TLS certificate permissions and implement least-privilege access controls; review cluster access logs for any certificate-based authentication activity during the vulnerability window.

Canonical CVE-2026-34179

EUVD-2026-20876 CRITICAL

Improperly Controlled Modification of Dynamically-Determined Object Attributes (CWE-915)

2026-04-09 canonical

GHSA-c3h3-89qf-jqm5

Canonical Privilege Escalation

9.1

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.1 CRITICAL

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

SUSE

CRITICAL

qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Re-analysis Queued

Apr 22, 2026 - 20:52 vuln.today

cvss_changed

EUVD ID Assigned

Apr 09, 2026 - 09:30 euvd

EUVD-2026-20876

Analysis Generated

Apr 09, 2026 - 09:30 vuln.today

Patch released

Apr 09, 2026 - 09:30 nvd

Patch available

CVE Published

Apr 09, 2026 - 09:22 nvd

CRITICAL 9.1

DescriptionCVE.org

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.

AnalysisAI

Privilege escalation in Canonical LXD 4.12 through 6.7 enables remote authenticated restricted TLS certificate users to gain cluster admin privileges. Exploitation requires high-privilege authentication (PR:H) but no user interaction. The vulnerability stems from missing Type field validation in doCertificateUpdate function when processing PUT/PATCH requests to the certificates API endpoint. Attack scope is changed (S:C), allowing attackers to break containment and achieve full cluster compromise with high impact to confidentiality, integrity, and availability. No public exploit identified at time of analysis.

Technical ContextAI

The doCertificateUpdate function in lxd/certificates.go fails to validate the Type field during certificate modification operations. This CWE-915 (improperly controlled modification of dynamically-determined object attributes) flaw allows authenticated restricted certificate users to manipulate certificate properties via PUT/PATCH to /1.0/certificates/{fingerprint}, bypassing intended access controls and elevating to cluster administrator role. Network-accessible (AV:N), low complexity (AC:L), requiring high privileges (PR:H).

RemediationAI

Vendor-released patch: upstream fix available via GitHub pull request (https://github.com/canonical/lxd/pull/17936); released patched version not independently confirmed at time of analysis. Organizations should monitor Canonical's official security advisory (https://github.com/canonical/lxd/security/advisories/GHSA-c3h3-89qf-jqm5) for release announcements and apply updates immediately upon availability. As an interim mitigation, restrict network access to the LXD API endpoint /1.0/certificates/* to trusted networks only, implement additional authentication layers for certificate management operations, audit existing TLS certificate users for appropriate privilege levels, and revoke restricted certificates if cluster admin escalation risk is unacceptable. Enable comprehensive API request logging to detect unauthorized certificate modification attempts.