EN PT-BR
← Voltar ao feed
high

CVSS 10.0 flaw in Canonical LXD and MicroCloud (CVE-2026-112816) lets attackers impersonate trusted TLS clients without a private key

1 fonte(s) · 1 atualização(ões) · publicado 01/11/2026 05:51 · coletado há 12 horas

Canonical disclosed CVE-2026-112816, a maximum-severity (CVSS 10.0) authentication flaw in LXD and MicroCloud. It lets an attacker with network access to the HTTPS API log in as a trusted client without holding that client's private key. The attacker only needs the trusted client's public certificate, which is not secret. If the impersonated account is privileged, the attacker could gain root access to the host, according to Canonical. The bug was reported by the Incus project, and Canonical confirmed LXD was also affected. A CISA assessment dated October 30 says there is no known exploitation, the flaw is not in the KEV catalog, and no public exploit exists.

Entenda a falha

A vulnerabilidade

CVE-2026-112816 (CVSS 10.0) is an authentication flaw in the HTTPS API of Canonical's LXD and MicroCloud. An attacker with network access to the API and the public certificate of an already-trusted client can log in as that client without its private key. If the impersonated account is privileged, Canonical says the attacker could get root on the host. The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before its fixed release, and MicroCloud is also affected. Incus is affected too and is fixed in 7.6.0.

Como funciona

LXD and MicroCloud use mutual TLS for remote API access: the client presents a certificate, and it is trusted if that certificate is in the server's trust store. During the TLS handshake the client proves possession of the private key only for the first certificate in its chain, the leaf. The server, however, compared every certificate the client sent against the trust store. So a trusted client's public certificate placed behind the attacker's own in the chain was matched, and the server treated the connection as that trusted client.

Por que é vulnerável

The root cause is a wrong assumption in certificate validation: the server trusted every certificate in the presented chain, although TLS only proves private-key ownership for the leaf. The rest of the chain is arbitrary data chosen by the client, and public certificates are not secret. The articles do not describe the exact code change or why the bug went unnoticed.

Como foi descoberta

The Incus project, which began as a community fork of LXD, reported the bug, and Canonical confirmed that LXD was also affected. Incus fixed it in version 7.6.0, together with 17 other security issues. Canonical published an advisory with fixed snap versions, and the fixed LXD point releases were still moving from the candidate channel to stable at the time. A CISA assessment dated October 30 in the CVE record says there is no known exploitation and the flaw is not in the KEV catalog.

Explicação gerada por IA a partir da matéria e dos artigos, em 01/11/2026 08:15.

Detalhes técnicos

  • LXD and MicroCloud use mutual TLS for remote API access. A client is trusted when its certificate is in the server's trust store.
  • The server compared every certificate the client sent against the trust store. A TLS handshake only proves possession of the private key for the leaf (first) certificate. The rest of the chain is arbitrary data supplied by the client.
  • An attacker can attach a trusted client's public certificate behind their own certificate in the chain, and the server accepts them as that client.
  • Exploitation requires network access to the HTTPS API and the public certificate of an already-trusted client.
  • A standalone LXD server does not expose the network API by default. It listens only on a local socket unless an administrator enables core.https_address.
  • MicroCloud is more exposed. An attacker who can capture a member's public certificate while it joins the cluster can then log in as that member.
  • The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before its fixed release. Ubuntu archive packages of LXD are listed as not affected or not shipped, so the fixes are delivered as snaps.
  • Incus fixed the same flaw in version 7.6.0, along with 17 other security issues.

Remediação

  • Update LXD and MicroCloud to the fixed versions with sudo snap refresh lxd and sudo snap refresh microcloud.
  • Canonical said the fixed LXD point releases were still moving from the candidate channel to stable at the time of its advisory. Verify the installed version after refreshing.
  • Canonical gives no workaround for LXD. Restricting who can reach the network API reduces risk until patching. Incus says there is no configuration fix and the only step is to restrict network access to the listener.
  • Incus users should move to 7.6.0.

Linha do tempo

  1. thehackernews.com ↗ · pub. 01/11/2026 05:51 · coletado 01/11 08:00 primeiro registro

    CVSS 10.0 flaw in Canonical LXD and MicroCloud (CVE-2026-112816) lets attackers impersonate trusted TLS clients without a private key

    ler a análise desta fonte

    Canonical disclosed CVE-2026-112816, a maximum-severity (CVSS 10.0) authentication flaw in LXD and MicroCloud. It lets an attacker with network access to the HTTPS API log in as a trusted client without holding that client's private key. The attacker only needs the trusted client's public certificate, which is not secret. If the impersonated account is privileged, the attacker could gain root access to the host, according to Canonical. The bug was reported by the Incus project, and Canonical confirmed LXD was also affected. A CISA assessment dated October 30 says there is no known exploitation, the flaw is not in the KEV catalog, and no public exploit exists.

    Technical Details

    • LXD and MicroCloud use mutual TLS for remote API access. A client is trusted when its certificate is in the server's trust store.
    • The server compared every certificate the client sent against the trust store. A TLS handshake only proves possession of the private key for the leaf (first) certificate. The rest of the chain is arbitrary data supplied by the client.
    • An attacker can attach a trusted client's public certificate behind their own certificate in the chain, and the server accepts them as that client.
    • Exploitation requires network access to the HTTPS API and the public certificate of an already-trusted client.
    • A standalone LXD server does not expose the network API by default. It listens only on a local socket unless an administrator enables core.https_address.
    • MicroCloud is more exposed. An attacker who can capture a member's public certificate while it joins the cluster can then log in as that member.
    • The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before its fixed release. Ubuntu archive packages of LXD are listed as not affected or not shipped, so the fixes are delivered as snaps.
    • Incus fixed the same flaw in version 7.6.0, along with 17 other security issues.

    Remediation

    • Update LXD and MicroCloud to the fixed versions with sudo snap refresh lxd and sudo snap refresh microcloud.
    • Canonical said the fixed LXD point releases were still moving from the candidate channel to stable at the time of its advisory. Verify the installed version after refreshing.
    • Canonical gives no workaround for LXD. Restricting who can reach the network API reduces risk until patching. Incus says there is no configuration fix and the only step is to restrict network access to the listener.
    • Incus users should move to 7.6.0.