CVE-2026-112816: 클러스터 인수를 가능케 하는 LXD 및 MicroCloud 인증 우회 취약점

Canonical은 LXD 및 MicroCloud에 영향을 미치는 중요한 인증 우회 취약점인 CVE-2026-112816을 해결하는 보안 업데이트를 발표했습니다. 이 결함은 최대 CVSS 점수 10.0을 가지며 인증되지 않은 원격 공격자가 해당 클라이언트의 개인 키를 소유하지 않고 신뢰받는 TLS 클라이언트로 가장할 수 있도록 할 수 있습니다.

성공적인 익스플로잇은 가장된 아이덴티티에 할당된 권한으로 LXD 또는 MicroCloud API에 대한 접근을 제공할 수 있습니다. 신뢰받는 아이덴티티에 충분한 권한이 있는 경우, 공격자는 클러스터에 대한 전체 접근, 관리되는 가상 머신, 잠재적으로 루트 수준에서 호스트에 접근할 수 있습니다.

이 취약점은 상호 TLS 인증에 사용되는 클라이언트 인증서 체인의 부적절한 검증에서 발생합니다. 클라이언트가 해당 개인 키의 소유권을 입증하는 리프 인증서만 인증하는 대신, 취약한 구현체는 클라이언트가 제어하는 체인에서 제공된 모든 인증서를 신뢰된 인증서와 비교합니다.

따라서 HTTPS API에 도달하고 이미 신뢰받는 클라이언트의 공개 인증서를 얻을 수 있는 공격자는 공격자가 제어하는 리프 인증서 뒤에 해당 인증서를 추가하여 신뢰받는 아이덴티티로 인정받을 수 있습니다.

Canonical은 Incus 프로젝트에서 이 취약점을 참조한 후 2026년 10월 말에 이 문제를 공개했습니다. 패치된 LXD 및 MicroCloud 릴리스가 이제 제공되며, 관리자들은 즉시 업데이트 할 것을 강력히 권장합니다.

이 결함은 LXD가 시스템 컨테이너와 가상 머신을 관리하고, MicroCloud가 클러스터 인프라를 조정하기 때문에 인프라 환경에서 특히 중요합니다. 관리 아이덴티티의 손상은 따라서 단일 서비스 이상에 확장될 수 있으며, 워크로드 또는 호스트 자체에 대한 제어를 제공할 수 있습니다.

보안 팀은 CVE-2026-112816 감지를 위해 인터넷이나 네트워크에 액세스 가능한 LXD와 MicroCloud의 HTTPS API를 식별하고, 신뢰받는 클라이언트 인증서를 검토하고, 예기치 않은 소스 시스템이나 비정상적인 관리 작업과의 인증서 기반 인증을 상호 연관시키는 것이 우선적입니다.

SOC Prime의 AI 기반 탐지 인텔리전스 플랫폼은 보안 팀이 네트워크, 리눅스, 클라우드, 컨테이너 및 아이덴티티 원격 측정을 통해 익스플로잇 및 사후 침해 행위에 대한 커버리지를 강화하도록 지원합니다.

영업팀에 문의

탐지 규칙을 탐색하려면 탐색 감지 클릭하여 관련 탐지 콘텐츠 및 사냥 논리를 액세스하세요. CVE-2026-112816을 탐지하려면, 방어자들은 취약한 버전 인벤토리와 API 접속 모니터링, 인증서 인증 텔레메트리 및 컨테이너, 가상 머신 또는 클러스터 설정에 영향을 미치는 의심스러운 관리 활동을 결합해야 합니다.

CVE-2026-112816 분석

CVE-2026-112816은 Canonical LXD 및 MicroCloud에서 사용되는 HTTPS 리스너의 잘못된 인증서 검증 취약점입니다.

두 제품 모두 원격 클라이언트를 인증하기 위해 상호 TLS를 사용할 수 있습니다. 정상적인 mTLS 행동 하에서, 연결된 클라이언트는 인증서를 제출하고 TLS 체인의 리프로 사용되는 인증서와 관련된 개인 키의 소유권을 증명합니다.

문제는 취약한 LXD 및 MicroCloud 구현체가 인증된 리프 인증서보다 더 많은 것을 검토하기 때문에 발생합니다.

According to Canonical, remote API authentication logic compared all certificates presented by a client against entries in the trusted certificate store. However, TLS proves private-key possession only for the leaf certificate. Additional certificates in the presented chain are supplied by the client and do not independently prove ownership of their corresponding private keys.

This creates an authentication gap.

An attacker can generate a certificate and private key they control, use that certificate as the leaf, and append the public certificate of a trusted client elsewhere in the presented chain. The vulnerable server may find the trusted certificate and associate the connection with that trusted identity even though the attacker does not possess its private key.

The details for CVE-2026-112816 therefore show that exploitation depends primarily on two prerequisites:

• The attacker can reach the LXD or MicroCloud HTTPS API.
• The attacker possesses the public certificate of an identity already trusted by the target.

The trusted client’s private key is not required.

This distinction explains the vulnerability’s critical severity. Certificate-based authentication is expected to demonstrate possession of a secret private key, but the affected logic effectively allows possession of the public certificate alone to satisfy part of the trust decision.

A standalone LXD installation does not expose its remote HTTPS API by default. The Hacker News notes that LXD normally listens only on its local Unix socket unless an administrator enables network access, for example through the core.https_address configuration.

This means not every vulnerable LXD installation is remotely exploitable from another host.

Exposure becomes significantly higher when administrators enable the API across a management network or expose it to the internet.

MicroCloud presents another relevant attack scenario. Canonical states that an attacker who can intercept the public TLS certificate of a machine joining a MicroCloud cluster may subsequently authenticate as that joined member.

CVE-2026-112816 affects vulnerable Canonical LXD releases including 4.0.14, 5.0.10, 5.21.8, and 6.9 before their corresponding fixed releases.

Canonical lists these patched LXD versions:

• LXD 6.10.1 for the 6/stable channel
• LXD 5.21.9 for 5.21/stable
• LXD 5.0.11 for 5.0/stable
• LXD 4.0.15 for 4.0/stable

For MicroCloud, fixed versions are:

• MicroCloud 3.4.1 for 3/stable
• MicroCloud 2.1.5 for 2/stable

Ubuntu’s CVE record describes successful exploitation as allowing an unauthenticated attacker to authenticate as a trusted client and gain full access to the cluster and managed virtual machines through a crafted certificate chain.

The maximum CVSS score of 10.0 reflects network accessibility, low attack complexity, no required privileges, and no user interaction, combined with potentially high impact to confidentiality, integrity, and availability.

Impact ultimately depends on the privileges of the identity being impersonated.

A restricted identity may provide limited API capabilities. A highly privileged client or cluster identity can provide substantially greater access.

Canonical explicitly warns that impersonation of a privileged trusted user can result in root access to the host machine.

That can potentially allow an attacker to:

• Manage or modify containers and virtual machines.
• Access workloads managed through the compromised LXD environment.
• Modify infrastructure configuration.
• Create new workloads or alter existing ones.
• Interfere with availability.
• Access data available to the impersonated identity.
• Potentially reach the host with root-level privileges when sufficient permissions are available.

The flaw was originally identified in the related Incus project and then referred to Canonical, which confirmed that the same certificate-chain authentication problem affected LXD.

Incus describes the underlying issue similarly: the server requested client certificates without verifying the entire submitted chain, while trust checks iterated across every supplied peer certificate rather than restricting authentication to the actual leaf certificate. Incus addressed the issue in version 7.6.0.

The vulnerability appears to have existed for an extended period. Incus states that the equivalent authentication logic had been present since its initial release. Canonical’s public advisory does not provide an exact date for when the vulnerable LXD behavior was first introduced.

As of November 2, 2026, an independent CVE-2026-112816 PoC and lab reproduction have been published publicly. This represents a change from The Hacker News report published on November 1, which stated that no working exploit had yet been released. The public reproduction appeared after disclosure and is not the original vulnerability research.

Canonical and the referenced reporting have not indicated that the vulnerability has been exploited in real-world attacks.

The Hacker News reports that the issue was not known to be exploited as of the U.S. CISA assessment dated October 30 and was not included in CISA’s Known Exploited Vulnerabilities catalog at that time.

There are therefore no campaign-specific CVE-2026-112816 IOCs such as confirmed malicious IP addresses, domains, malware hashes, or known attacker infrastructure associated with exploitation.

Defenders should instead focus on vulnerability exposure and behavior.

Potential hunting opportunities include:

• Remote connections to LXD or MicroCloud HTTPS APIs from unexpected systems.
• Successful API authentication originating from networks not normally used by trusted administrators.
• A trusted certificate identity appearing from multiple unrelated source systems.
• Administrative API activity that does not match the expected owner of a certificate.
• Unexpected creation, deletion, or modification of containers and virtual machines.
• Changes to trusted certificate entries.
• New or altered cluster members.
• Unexpected changes to storage, networking, profiles, projects, or instance configuration.
• Privileged operations occurring shortly after unusual certificate-based authentication.
• API connections to management interfaces that were not intended to be remotely accessible.

Organizations should also inventory trusted certificates associated with former administrators, retired hosts, automation systems, and cluster members.

Because exploitation requires the public certificate rather than the private key, defenders should not treat the confidentiality of private keys alone as sufficient protection against this specific vulnerability.

Monitoring should also account for shared management networks.

An API that is not exposed directly to the public internet can still be exploitable by an attacker who has already gained a foothold on another system capable of reaching the management interface.

This makes lateral movement particularly relevant. A compromised workstation, server, CI/CD runner, management host, or cloud workload with network access to the LXD API could provide the position needed to exploit an otherwise internally exposed system.

CVE-2026-112816 Mitigation

Canonical recommends upgrading affected LXD and MicroCloud deployments to the latest fixed versions immediately.

For Snap-based deployments, administrators can update using:

sudo snap refresh lxd

and:

sudo snap refresh microcloud

After refreshing, verify the version actually installed rather than assuming that the update was applied successfully.

Canonical noted during disclosure that some LXD point releases were progressing from candidate to stable channels. Administrators should therefore explicitly confirm that their system is running one of the fixed versions.

The primary CVE-2026-112816 mitigation is upgrading to:

Product	Fixed version
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

Canonical has not published a configuration-based workaround that fully eliminates the underlying authentication defect.

If immediate upgrading is impossible, restrict network access to the HTTPS API as aggressively as operational requirements allow.

Only authorized management hosts and trusted infrastructure should be able to establish connections to the listener.

For LXD installations that do not require remote management, administrators should evaluate whether the network API needs to remain enabled at all.

For environments that require remote access:

• Restrict the API using host or network firewalls.
• Permit connections only from dedicated management networks.
• Avoid exposing the API directly to the public internet.
• Use VPN or bastion-based administrative access where appropriate.
• Segment container and virtualization management infrastructure from user networks.
• Monitor all successful administrative API requests.
• Review trusted certificates and remove entries that are no longer necessary.

These controls reduce exposure but do not correct the vulnerable certificate-validation logic.

Organizations running MicroCloud should prioritize updating all relevant cluster members and review recent joining activity for unexpected systems or certificate identities.

Administrators should also review their trusted certificate stores.

Remove certificates belonging to decommissioned hosts, former administrators, unused automation systems, or identities that no longer require access.

Where suspicious activity is discovered, investigate the affected host and cluster before rotating credentials or modifying evidence.

Relevant sources of telemetry may include:

• LXD and MicroCloud service logs
• Linux system logs
• Firewall and network flow records
• Reverse proxy telemetry, if applicable
• Host EDR data
• Cloud network logs
• Cluster configuration and membership history
• Administrative change records

Look for unexpected instance creation, modification, deletion, snapshot activity, storage operations, networking changes, and configuration updates.

If exploitation is suspected and a privileged certificate identity was impersonated, defenders should treat potential host-level compromise seriously because Canonical confirms that root access may be possible depending on the victim identity’s permissions.

Incident responders should preserve relevant evidence and inspect the system for persistence, unauthorized accounts or certificates, modified services, new workloads, suspicious processes, and abnormal outbound network communication.

Organizations using Incus rather than Canonical LXD should separately update to Incus 7.6.0 or the relevant supported fixed release because the related project was affected by the same underlying certificate-chain trust issue.

Ubuntu also notes that its archive-packaged LXD versions for currently listed Ubuntu releases are either not shipped through the affected package path or not affected, while Canonical’s security guidance focuses on the Snap releases. Administrators should still verify the actual LXD distribution and version running in their environment rather than assuming exposure based solely on the Ubuntu release.

Disclaimer: Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.