CVE-2026-63293

Executive Summary

CVE-2026-63293 is a critical (CVSS 9.9) link-following vulnerability (CWE-59) in LXD, a system container and virtual machine manager. An authenticated attacker can supply a crafted image archive where metadata.yaml is a symbolic link pointing to arbitrary paths on the host filesystem. During image import or unpacking, LXD fails to validate this symlink, enabling arbitrary file read and write operations with the privileges of the LXD daemon, which typically runs with elevated (root) permissions. This results in full host system compromise, including potential container breakout and lateral movement within the environment. As of this writing, the vulnerability is unpatched, with no vendor advisory, patch, or public exploit published.

Technical Analysis

Vulnerability Class: CWE-59 — Improper Link Resolution Before File Access ("Link Following")

Affected Component: LXD image import/unpacking mechanism. LXD containers and virtual machines are provisioned from image archives that include filesystem layers and a metadata manifest named metadata.yaml. This metadata file contains container configuration, including runtime settings, environment variables, and device definitions.

Root Cause: The NVD description states that when importing or unpacking an image archive, LXD "fails to validate whether the metadata.yaml file is a symbolic link." The import routine presumably performs a standard file-write operation (e.g., opening a file handle and writing the archive's contents) without first checking whether the target path resolves to a symlink. On typical Unix-like systems, if metadata.yaml is a symlink, the write operation follows the link and writes to the ultimate target — regardless of an LXD-specific path check on the metadata.yaml itself.

Attack Surface:

• Authentication: CVSS vector indicates PR:L (low privileges), meaning an authenticated LXD user can trigger exploitation. The user does not need root privileges; membership in the lxd group or access to the LXD REST API is sufficient.
• Network Exposure: AV:N (network) — if the LXD API is exposed beyond localhost, the attack can be performed remotely.
• Scope Change: S:C — the vulnerability crosses a trust boundary. The attacker operates inside a container/image context but achieves impact on the host.

Preconditions for Exploitation:

1. Attacker must have the ability to create or upload an image archive to the LXD host (requires authenticated access to the LXD API or the lxd group).
2. The LXD server must have image import/unpacking enabled (default behavior).
3. No symlink validation exists in the image-processing pipeline.

Technical Insufficiency Note: The NVD description does not specify whether the vulnerable function is invoked during lxc image import, lxc image copy, container creation from a remote image, or the initial image cache population. It also does not name the specific Go function or package responsible for the flaw. Sufficient technical detail to enumerate exact vulnerable code paths is not available at this time; analysis is presented at the vulnerability-class level.

Exploitation Scenarios

No public PoC or exploit code is currently available. The attack chain below is inferred from the vulnerability class and the NVD description.

Scenario 1: Host SSH Key Overwrite (Privilege Escalation)

1. Reconnaissance/Target Identification: The attacker identifies an LXD server (via network scanning for the LXD API port, typically TCP/8443, or gains local access through a compromised user account that is a member of the lxd group).
2. Flaw Trigger: The attacker crafts an image archive (tar.gz or similar format) containing:
   • A legitimate filesystem layer.
   • A metadata.yaml entry that is a symbolic link pointing to /root/.ssh/authorized_keys (or another host path).
3. Payload/Execution: The attacker initiates lxc image import <crafted-archive> (or uses the API equivalent). During unpacking, LXD writes the metadata content to metadata.yaml, which resolves through the symlink and overwrites /root/.ssh/authorized_keys with attacker-controlled content (the attacker's public SSH key).
4. Post-Exploitation Impact: The attacker SSHes into the host as root, achieving full host compromise. From here, they can pivot to other systems, deploy persistence mechanisms, or exfiltrate sensitive data.

Scenario 2: Arbitrary File Read via devlxd

1. Reconnaissance: Same as Scenario 1; attacker has authenticated access to the LXD API.
2. Flaw Trigger: The attacker crafts an image archive where metadata.yaml is a symlink to a sensitive file on the host, for example, /etc/shadow or /var/lib/lxd/containers/<container>/backup.yaml.
3. Payload/Execution: During import, LXD reads the symlink target's content (in some configurations, the image metadata is echoed back via API responses or written into the container's config directory, which the attacker can read). This achieves arbitrary file read.
4. Post-Exploitation: The attacker harvests credentials from /etc/shadow, obtains LXD secrets from /var/lib/lxd/, and uses them for lateral movement or further privilege escalation.

Scenario 3: Container Breakout

1. Reconnaissance: Attacker is an unprivileged user with access to a running container on the LXD host.
2. Flaw Trigger: The attacker publishes a malicious image from their running container (via lxc publish), placing a symlinked metadata.yaml inside.
3. Payload/Execution: When another user or an automated system imports that published image, the symlink is followed on the host during unpacking, writing arbitrary host files.
4. Post-Exploitation: The attacker gains host code execution via cron job overwrite (/etc/cron.d/), systemd unit file replacement, or SSH key injection, escaping the container boundary.

In summary, the exploitation chain is: craft image → trigger import → symlink resolution on host → arbitrary file read/write → host compromise.

Impact Assessment

Business Impact:

• Full Host Compromise: Arbitrary file write as root on the host effectively means total system takeover.
• Multi-Tenant Exposure: In environments where LXD is used for multi-tenant container hosting, this vulnerability allows any tenant to compromise the host and potentially access other tenants' containers and data.
• Lateral Movement: A compromised LXD host becomes a pivot point into the broader internal network.
• Compliance Violation: Unpatched critical vulnerability in production may violate internal security policies or regulatory requirements (PCI-DSS, SOC 2, etc.).

Affected Systems: All LXD deployments where image import/unpacking is enabled — including standalone LXD installations, Proxmox VE hosts (which embed LXD), and cloud environments using LXD as an infrastructure layer. The specific version range is unknown; no version information is available from the CVE data.

Blast Radius: If the host is compromised, all containers on that host, the host's own filesystem, and any network-accessible systems reachable from the host are at risk.

Detection Guidance

The following detection content focuses on anomalous image-import operations, symlink presence in archives, and unexpected file writes during the LXD image build process. These are heuristic detections; specific rule tuning will be required for individual environments.

Sigma Rule

title: Suspicious LXD Image Import with Symlinked Metadata
id: 9f2c2f2c-8e68-4f19-a4ad-7f2c4c9e3d8f
status: experimental
description: >
  Detects LXD image import operations where the metadata.yaml file is a symlink.
  Exploitation of CVE-2026-63293 requires a crafted archive with a symlinked
  metadata.yaml. This Sigma rule relies on a behavioral indicator: LXD daemon
  file access to symlinks during image unpacking.
author: ValtersIT Threat Intel Team
date: 2026/01/15
logsource:
  category: process_creation
  product: linux
detection:
  selection_lxd_import:
    Image|endswith:
      - 'lxd'
      - 'lxd-agent'
      - 'lxc'
    CommandLine|contains:
      - 'image import'
      - 'image copy'
      - 'publish'
  selection_symlink:
    # This would need a cross-reference with filesystem event logs
    # that indicate reading/writing via symlink
    Image|endswith: 'lxd'
    CommandLine|contains:
      - 'metadata.yaml'
      - '.tar'
  condition: selection_lxd_import or selection_symlink
falsepositives:
  - Legitimate image imports by administrators
  - Automated CI/CD pipelines using LXD images
level: high
tags:
  - attack.t1190
  - cve.2026.63293
  - cwe.59

YARA Rule

rule CVE_2026_63293_Symlinked_Metadata_YAML
{
    meta:
        author      = "ValtersIT Threat Intel"
        description = "Detects crafted LXD image archives containing a symlinked metadata.yaml entry"
        date        = "2026-01-15"
        cvss        = "9.9"
        cve         = "CVE-2026-63293"
        cwe         = "CWE-59"
        reference   = "NVD Description for CVE-2026-63293"
    strings:
        $symlink_tar = { 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }  // placeholder for tar symlink typeflag
        $metadata_name = "metadata.yaml"
        $path_sensitive = /\.\./|\/etc\/|\/root\/|\/var\/lib\/lxd\//
    condition:
        uint32(0) == 0x8B1F or // gzip magic for tar.gz
        uint32(0) == 0x04034B50 or // zip magic
        (
            $metadata_name and $path_sensitive
        )
}

Note: YARA-specific tar symlink byte patterns are not included; the rule is intentionally heuristic and should be adapted to inspect actual tar header structures (typeflag field 5 for symlink in ustar format) in your environment.

Suricata IDS Rule

alert http any any -> any any (
    msg:"CVE-2026-63293 - LXD Image Import with Suspicious Payload";
    flow:to_server,established;
    content:"metadata.yaml";
    nocase;
    distance:0;
    http.request_body;
    pcre:"/(\x00|\x2e\x2e\/|etc\/shadow|root\/\.ssh)/i";
    classtype:attempted-admin;
    sid:20266329301;
    rev:1;
    metadata:cvss_score 9.9, cve CVE-2026-63293, mitre_tactic T1190;
)

Note: This rule detects HTTP POSTs to the LXD REST API containing metadata.yaml and suspicious path traversal or sensitive-path content. Network-based detection is limited because image transfers may use encrypted TLS or non-HTTP protocols; filesystem-level detection is recommended.

Elastic Detection

// EQL rule for detecting LXD daemon writes to sensitive paths (potential CVE-2026-63293 exploitation)
// Requires system/filebeat with file integrity monitoring on sensitive paths
sequence by host.name
  [any where process.name == "lxd" and
     event.action == "write" and
     file.path == "/etc/cron.d/*" or
     file.path == "/root/.ssh/authorized_keys" or
     file.path == "/etc/shadow" or
     file.path == "/var/spool/cron/*"
  ] with runs=3
| filter
  // Correlation: LXD was performing image import in preceding 5 minutes
  let importProcess = any where process.name == "lxd" and
     process.args contains "import" or process.args contains "publish"
  let importTime = importProcess.timestamp <= timestamp_now()
  importTime >= timestamp-5m

Splunk SPL Query

index=linux OR index=sysmon sourcetype=linux_audit OR EventCode=11
| search (process="lxd" OR process_path="*lxd*")
| search (command_line="*import*" OR command_line="*publish*" OR command_line="*copy*")
| lookup lxd_sensitive_paths.csv path AS file_path OUTPUT is_sensitive
| search is_sensitive=true
| table _time, host, user, process, command_line, file_path, result
| sort _time desc
| eval detection = "CVE-2026-63293"
| eval confidence = "high"
| eval action = if(result=="success", "ALERT", "INFO")

This query correlates LXD process activity with writes to sensitive filesystem paths. In practice, create a lookup CSV listing sensitive paths (/root/.ssh/authorized_keys, /etc/cron.d/*, /etc/shadow, /var/lib/lxd/*, etc.).

Wazuh OSSEC Rule

<group name="lxd, cve-2026-63293, cwe-59,">
  <rule id="632930" level="12">
    <if_sid>80700</if_sid> <!-- Audit write events to root-owned paths -->
    <field name="audit.data.syscall">write|openat|creat</field>
    <field name="audit.data.path">/root/\.ssh/|/etc/cron\.d/|/etc/shadow|/var/lib/lxd/</field>
    <match>metadata.yaml</match>
    <description>CVE-2026-63293: LXD attempting write to sensitive host path via symlinked metadata.yaml</description>
    <group>pci_dss_6.5.1,gdpr_32,hipaa_164.312.c,</group>
  </rule>

  <rule id="632931" level="10">
    <if_sid>502</if_sid> <!-- syscheck modified file -->
    <field name="file">metadata.yaml</field>
    <description>CVE-2026-63293: metadata.yaml file modified during LXD image import</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source. A vendor advisory has not been issued, and no fixed LXD version is available.

Immediate Mitigations (compensating controls):

1. Restrict LXD Group Membership: Remove all non-administrative users from the lxd group. Membership grants full control over the LXD daemon, which includes image import capabilities. This is the highest-impact immediate control.
2. Network Isolation: Do not expose the LXD REST API (TCP/8443 default) on non-trusted networks. Bind the API to localhost (lxc config set core.https_address 127.0.0.1:8443) or use a firewall to restrict access to administrative hosts only.
3. Disable Image Import Where Possible: If image import is not essential for the environment, disable it temporarily. LXD does not have a direct --disable-import switch; the most practical approach is to use RBAC to restrict image permissions to a minimal administrative group.
4. File Integrity Monitoring: Deploy FIM on sensitive host paths (/root/.ssh/, /etc/cron.d/, /etc/systemd/system/, /var/lib/lxd/) to alert on unexpected writes.
5. Audit Logging: Enable Linux auditd rules for the lxd binary and watch sensitive paths.

Patch/Upgrade Steps:

• Monitor the LXD GitHub repository (https://github.com/canonical/lxd) and canonical.com security advisories for a security release.
• Once a patched version is available, apply the upgrade immediately via the distribution's package manager (apt upgrade lxd lxd-client on Ubuntu, snap refresh lxd for snap-based installs).
• After patching, restart the LXD daemon (systemctl restart lxd or snap restart lxd).

Long-Term Hardening:

• Run LXD daemon under a dedicated non-root system account where possible (though this requires substantial LXD configuration changes).
• Adopt a container image signing policy to ensure only trusted images are imported.
• Implement microsegmentation to limit the blast radius of any LXD host compromise.
• Institute a formal patch-management process that tracks LXD security advisories.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-63293
2. CWE-59 Reference: https://cwe.mitre.org/data/definitions/59.html
3. LXD Project (Canonical): https://github.com/canonical/lxd
4. LXD Security Advisories: https://github.com/canonical/lxd/security/advisories (no advisory for CVE-2026-63293 published as of this writing)
5. MITRE ATT&CK T1190: https://attack.mitre.org/techniques/T1190/

Threat Actor Campaigns / Exploit-in-the-Wild Evidence: None reported. CISA KEV status: NO. No PoC or exploit code is publicly available. The vulnerability is unpatched, and unknown threat actors may be targeting it given the critical CVSS rating; however, no in-the-wild exploitation has been confirmed to date.