CVE-2026-63295

Executive Summary

CVE-2026-63295 is an authorization bypass vulnerability (CWE-863) in LXD, the Linux system-container hypervisor. An authenticated attacker who can create or update instances inside a project configured with container privilege restrictions — such as restricted.containers.privilege=isolated — can evade the project's isolation policy by simply omitting the security.idmap.isolated key from the instance configuration. Successful exploitation weakens the project-level security boundary and enables an instance to run without the enforced isolated ID-mapping requirements, with a CVSS 3.1 base score of 4.3 (Medium) reflecting primarily an availability impact.

Technical Analysis

LXD's project model is a multi-tenant isolation mechanism: an administrator can create projects and attach "restrictions" to them, bounding what members of that project are permitted to do. One such restriction, restricted.containers.privilege=isolated, is designed to force every container spawned in that project to run with isolated user/group ID mappings (unprivileged containers), preventing the container root from mapping directly to host-root-level UIDs and keeping the container inside a dedicated ID-mapping namespace.

The vulnerability lies in how the enforcement logic evaluates instance configurations against that project restriction. According to the NVD description, when an instance is created or updated without explicitly setting the security.idmap.isolated key, LXD fails to enforce the project's restricted.containers.privilege=isolated requirement. From the vulnerability class perspective (CWE-863, Incorrect Authorization), the policy check appears to pass when the effective instance configuration does not carry the expected key — i.e., the check fails open on a missing attribute rather than failing closed. The authorization decision is therefore derived from the presence of the key rather than from the evaluated outcome of the project's restriction policy.

Attack surface: the LXD daemon exposes a REST API (network-accessible, typically TLS-protected, and also available over the local Unix socket). Any authenticated principal — including a low-privilege tenant in a shared LXD deployment — who is permitted to create or update instances in a restricted project is inside the attack surface. The flaw is server-side configuration validation logic; the attacker does not need host-level access.

Precise code-level mechanics are not available from the NVD description — no function names, validation routines, or API endpoint paths are disclosed, and no CNA title was provided. What can be stated with confidence is the mechanism at the configuration-validity level: the project restriction is intended to be mandatory, but the absence of the security.idmap.isolated key causes the enforcement path to be skipped, yielding an instance that violates the project's declared isolation profile.

Exploitation Scenarios

No public PoC or exploit code exists for CVE-2026-63295, and the EPSS score (0.00213, 11.8th percentile) indicates a low current likelihood of exploitation in the wild. The attack chain below is therefore inferred from the vulnerability class and the NVD description — it should be treated as an analytical reconstruction, not as a verified exploit procedure.

1. Reconnaissance / target identification: The attacker authenticates to the LXD daemon using valid credentials or a client certificate. They enumerate accessible projects and inspect project configuration to identify a target project where restricted.containers.privilege=isolated is enforced. In multi-tenant LXD deployments, the attacker may be a legitimate but low-privilege member of such a project.
2. Triggering the flaw: The attacker submits a request to create a new instance — or to update an existing instance — within the restricted project. The instance configuration deliberately omits the security.idmap.isolated key while otherwise appearing compliant with project rules.
3. Execution at the vulnerability-class level: Because LXD's validation fails to enforce the isolation requirement when the key is missing, the instance is accepted and launched without isolated ID mappings. The project's restricted.containers.privilege=isolated constraint is silently bypassed, and the container runs with a more permissive ID-mapping configuration than the project policy mandates.
4. Post-exploitation impact: The instance now operates outside the project's security envelope. In a shared LXD host, this weakens the trust boundary between projects and may be used as a stepping stone for further attempts to interfere with host resources or co-resident workloads. Per the CVSS vector, the direct integrity and confidentiality impacts are scored as None, and the availability impact as Low — the immediate measurable effect is a policy/authorization violation that degrades the security posture of the affected environment.

Impact Assessment

The CVSS 3.1 base score is 4.3 (Medium) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L. The vector communicates: network-exploitable, low attack complexity, low privileges required, no user interaction, scope unchanged, no direct confidentiality or integrity loss, and a low availability impact.

Business impact is most significant for operators running LXD as a multi-tenant container platform. In such environments, project restrictions are the primary enforcement mechanism for workload isolation; a bypass negates the administrator's security intent. Affected systems are LXD hosts whose projects use restricted.containers.privilege=isolated — and, by extension, every workload governed by those projects. Blast radius includes: degradation of isolation guarantees for tenant workloads, potential cross-tenant resource interference, non-compliance with internal security baselines or regulatory controls that require container isolation, and increased exposure if the bypass is chained with a separate container-escaping vulnerability.

At the time of writing, CVE-2026-63295 is not listed in the CISA Known Exploited Vulnerabilities catalog, and no threat-actor campaigns or exploit-in-the-wild evidence have been reported. The low EPSS percentile corroborates that exploitation in the wild is currently uncommon.

Detection Guidance

Detection is challenging for this vulnerability class because the malicious action is an omission (a missing configuration key) rather than the presence of a distinctive malicious string. Detection should therefore focus on (a) monitoring instance create/update operations in restricted projects, and (b) auditing configuration diffs where security.idmap.isolated disappears or is absent. The rules below target observable events and configuration artifacts; they require that LXD daemon audit logs and/or host process telemetry be forwarded to the SIEM/EDR.

Sigma Rule

title: LXD Instance Create/Update Bypassing restricted.containers.privilege=isolated
id: a3c5b1c1-6329-5c95-8a5d-000000000001
status: experimental
description: Detects lxc/lxd client commands that create or update an instance in a
  project with restricted.containers.privilege=isolated while omitting the
  security.idmap.isolated key.
logsource:
  category: process_creation
  product: linux
detection:
  selection_client:
    Image|endswith:
      - '/lxc'
      - '/lxd'
    CommandLine|contains:
      - 'init'
      - 'launch'
      - 'config set'
  selection_restriction:
    CommandLine|contains:
      - 'restricted.containers.privilege=isolated'
      - 'restricted.containers.privilege'
  filter_explicit_idmap:
    CommandLine|contains: 'security.idmap.isolated'
  condition: selection_client and selection_restriction and not filter_explicit_idmap
falsepositives:
  - Administrators intentionally managing project restrictions and then setting the
    key in a separate command.
  - Automation tooling that sets project restrictions before instance creation.
level: high

YARA Rule

rule lxd_isolation_bypass_config
{
    meta:
        author = "valtersit.com Threat Intelligence"
        description = "Detects LXD instance/project configuration data that references restricted container privilege isolation without including the security.idmap.isolated key."
        reference = "CVE-2026-63295"
        cve = "2026-63295"
        date = "2026-06-01"

    strings:
        $restriction = "restricted.containers.privilege" ascii wide
        $isolated = "isolated" ascii wide
        $idmap = "security.idmap.isolated" ascii wide

    condition:
        $restriction and $isolated and not $idmap
}

Suricata IDS Rule

alert http any any -> any any (msg:"ET POLICY LXD Instance Create Request Missing security.idmap.isolated in Restricted Project"; flow:to_server,established; http.request_body; content:"restricted.containers.privilege"; nocase; content:"isolated"; nocase; content:!"security.idmap.isolated"; classtype:policy-violation; sid:202663295; rev:1; metadata:created_at 2026-06-01, cve CVE-2026-63295;)

Note: Suricata's negated content match (content:!"...") applies to the inspected buffer (HTTP request body). Coverage is limited to plaintext HTTP or HTTP/2 captured traffic in environments where the LXD API is not TLS-encrypted or where TLS interception is deployed.

Elastic Detection

process where event.action == "exec" and
  process.name in ("lxc", "lxd") and
  process.command_line like "*restricted.containers.privilege*" and
  process.command_line like "*isolated*" and
  not process.command_line like "*security.idmap.isolated*"

Splunk SPL Query

index=linux (sourcetype=linux_audit OR sourcetype=process_creation OR sourcetype=sysmon)
| where match(CommandLine, "restricted\\.containers\\.privilege") 
    AND match(CommandLine, "isolated") 
    AND NOT match(CommandLine, "security\\.idmap\\.isolated")
| eval outcome=if(match(CommandLine, "(init|launch|config set)"), "instance_operation", "config_operation")
| table _time, host, user, parent_process_name, process_name, CommandLine, outcome
| sort - _time

Wazuh OSSEC Rule

<group name="lxd,">
  <!-- Requires a custom decoder for LXD daemon JSON logs. Matches policy enforcement
       events referencing restricted container isolation that lack the idmap key. -->
  <rule id="100635" level="8">
    <decoded_as>lxd</decoded_as>
    <field name="config">restricted.containers.privilege</field>
    <field name="config">isolated</field>
    <description>LXD: project restriction event for isolated containers without security.idmap.isolated - possible authorization bypass (CVE-2026-63295)</description>
    <mitre><id>T1068</id></mitre>
    <group>lxd,isolation_bypass,authorization,</group>
  </rule>
</group>

Note: The Wazuh rule requires a custom decoder to extract the config field from LXD's structured logs; the rule above is a starting point and must be validated against real log samples from the affected LXD version.

Mitigation & Patch Guidance

Patch confidence is 2/4 (CLAIMED) — a single OSV source references a fix, but it is not independently confirmed, and no patched version string has been published.

1. Immediate mitigations:

   • Audit all LXD projects that use restricted.containers.privilege=isolated. Enumerate every instance in those projects and verify that security.idmap.isolated is explicitly set (expected value: true/isolated) on each instance and in any applied profiles.
   • Restrict project membership and grant create/update instance permissions only to trusted principals in multi-tenant deployments. Review project-level ACLs and authenticated client certificates.
   • As a compensating control, monitor and alert on any instance create/update request in restricted projects where the configuration lacks security.idmap.isolated (see Detection Guidance).
   • If feasible, enforce isolation at a different layer: run restricted projects on dedicated LXD hosts, or wrap instance creation in an approved automation layer that always injects the required key.

2. Patch / upgrade steps:

   • Track the OSV entry for CVE-2026-63295 and upstream LXD security announcements until the claimed fix is independently confirmed and a release version is identified.
   • Test the patched version in a staging environment with a regression scenario: create a project with restricted.containers.privilege=isolated, then attempt to create an instance without security.idmap.isolated. The patched build must reject or remediate the configuration.
   • After validation, upgrade all production LXD hosts and re-run the audit and regression tests.

3. Long-term hardening:

   • Adopt configuration-as-code for LXD (profiles, project policies) so isolation keys are injected deterministically and drift is detectable.
   • Enable LXD audit logging and forward logs to the SIEM; alert on policy-enforcement failures and on configuration deltas for restricted projects.
   • Apply least privilege to the LXD API (network filtering, TLS client certificates, fine-grained authorization) and segment multi-tenant workloads.
   • Maintain a vulnerability watch on LXD and the Linux Containers project; subscribe to NVD and OSV feeds.
   • Where container isolation is a compliance requirement, supplement project restrictions with host-level controls (e.g., separate VMs or dedicated worker nodes per trust domain).

References

1. NVD Entry — CVE-2026-63295: https://nvd.nist.gov/vuln/detail/CVE-2026-63295
2. OSV Vulnerability Entry — CVE-2026-63295: https://osv.dev/vulnerability/CVE-2026-63295
3. CWE-863 — Incorrect Authorization: https://cwe.mitre.org/data/definitions/863.html
4. MITRE ATT&CK — T1068 Exploitation for Privilege Escalation: https://attack.mitre.org/techniques/T1068/
5. CISA KEV — CVE-2026-63295 is NOT listed (as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No known threat-actor campaigns, exploit-in-the-wild evidence, or public proof-of-concept code for CVE-2026-63295 at the time of writing. The EPSS score (0.00213, 11.8th percentile) indicates a low current probability of exploitation.