CVE-2026-63298

Executive Summary

CVE-2026-63298 is an improper neutralization of special elements (CWE-78, OS command injection class) vulnerability in Canonical LXD's handling of NVIDIA instance configuration values. An authenticated attacker who can set container/VM configuration keys — specifically nvidia.driver.capabilities or any nvidia.require.* value — can embed newline characters that inject arbitrary directives into the generated lxc.conf file, ultimately executing code on the host with the privileges of the LXD daemon. With a CVSS base score of 9.9 (Scope:Changed, Confidentiality/Integrity/Availability all High), the flaw is critical: successful exploitation crosses a privilege boundary from a tenant-level LXD user to full host control.

Technical Analysis

LXD generates an lxc.conf configuration file for each instance it manages; this file is consumed by the underlying LXC runtime when the instance is started. Several NVIDIA-related configuration keys — nvidia.driver.capabilities and any key under the nvidia.require.* namespace — are written verbatim into that generated configuration. The vulnerability is that these values are not validated or sanitized for embedded special elements, specifically newline (\n) characters.

Because the configuration file format is line-oriented, a newline embedded in a value terminates that logical line and begins a new one. Everything after the injected newline is therefore interpreted by LXC as an independent configuration directive rather than as part of the NVIDIA capability string. This is the classic "configuration file injection via newline" pattern that underlies CWE-78 command-injection findings in configuration-generation subsystems.

The practical consequence is that an authenticated attacker with the ability to write the affected configuration keys can append arbitrary LXC directives to the instance's generated lxc.conf. Certain LXC configuration directives cause the runtime to execute external programs on the host (for example, hook directives that run a script at defined lifecycle points). By injecting such a directive, the attacker causes the LXC runtime — which executes as the LXD daemon, typically root — to run an attacker-controlled command on the host.

Key characteristics:

• Attack vector: Network (AV:N) — LXD exposes a REST API over the network (commonly TLS on port 8443) for remote client management.
• Privileges required: Low (PR:L) — the attacker must be authenticated to the LXD API and authorized to modify the affected instance configuration.
• User interaction: None (UI:N).
• Scope: Changed (S:C) — exploitation escapes the instance/tenant boundary and impacts the host, which is why the score reaches 9.9 despite low privileges being required. A mere scope-unchanged command injection would not carry this severity.
• Impact: Full compromise of host confidentiality, integrity, and availability (C:H/I:H/A:H).

No public proof-of-concept was identified in the supplied data (Exploit Code: NO, Nuclei Template: NO), though the PoC status is recorded as Public. The attack chain below is therefore described at the vulnerability-class level in accordance with the available description.

Exploitation Scenarios

1) Reconnaissance / target identification. The attacker identifies a reachable LXD API endpoint. LXD's remote API is network-exposed and can be fingerprinted (TLS certificate subject, API banner, port 8443). The attacker requires valid credentials or an existing trusted client certificate granting rights to manage instances and set configuration.

2) Triggering the flaw. With authenticated access, the attacker creates or modifies an instance whose configuration includes an NVIDIA-related key. The attacker sets nvidia.driver.capabilities (or an nvidia.require.* key) to a value that contains a newline character followed by additional content. At this stage the only requirement imposed by the vulnerability class is that the value reaches the lxc.conf generator without sanitization of embedded newlines.

3) Payload / execution mechanism (class-level). When LXD writes the instance configuration, the newline splits the value and the trailing text is emitted as a new, attacker-chosen directive in lxc.conf. When the instance is next started (or the configuration regenerated and applied), the LXC runtime parses that injected directive and acts on it. Because directives exist that cause host-side program execution, the injected directive results in attacker-controlled code running on the host under the identity of the LXD daemon (typically root). No specific lxc.conf directive name is asserted here beyond the keys explicitly named in the NVD description (nvidia.driver.capabilities, nvidia.require.*); the exact injected directive depends on the LXC runtime version and is not enumerated in the source data.

4) Post-exploitation impact. The attacker obtains command execution as the LXD daemon user on the physical/virtual host — not merely inside the container. From that position the attacker can read or modify any host data accessible to the daemon, persist, pivot to other instances and the control plane, and disrupt all hosted workloads.

Note: No public exploit code was provided in the intelligence data; the chain above is inferred from the documented vulnerability class and the explicitly named configuration keys. Any implementation-specific details (exact injected directive, exact LXD API call) should be confirmed against the vendor advisory before operational use.

Impact Assessment

The CVSS v3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (base 9.9) maps to severe, host-wide impact:

• Confidentiality (High): The daemon runs with broad host filesystem and process access; host secrets, instance disks, and other tenants' data become readable.
• Integrity (High): Arbitrary code execution as the daemon permits modification of host configuration, instance images, and the LXD control plane.
• Availability (High): Host or instance disruption, malicious instance termination, or denial of all hosted services.
• Scope (Changed): The vulnerable component (instance configuration handling) is compromised in a way that affects resources beyond its security scope (the host). This is the single most important severity driver — a tenant-level user reaches host root-equivalent control.

Blast radius: Any organization self-hosting LXD — particularly multi-tenant cloud, virtualization, or container-hosting providers — is exposed. A compromised host may cascade to every instance it runs. Single-tenant lab deployments are lower risk but still allow host takeover by any LXD-authorized user.

EPSS is 0.00355 (28.8th percentile), indicating low currently-observed exploitation probability; there is no CISA KEV listing. However, given the CVSS 9.9 severity and the public PoC status, organizations should treat this as a high-priority remediation regardless of EPSS.

Detection Guidance

Sigma Rule

title: LXD NVIDIA Configuration Newline Injection (CVE-2026-63298)
id: 9f2a5c1e-6329-8a41-b7d0-2c7e41ab9e10
status: experimental
description: Detects attempts to set LXD nvidia.driver.capabilities or nvidia.require.*
  configuration values containing newline characters, indicating config injection.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-63298
author: valtersit.com
date: 2026/01/01
logsource:
  product: linux
  service: lxd
detection:
  selection_keys:
    - 'nvidia.driver.capabilities'
    - 'nvidia.require'
  selection_newline:
    - '\n'
    - '\r'
    - '%0a'
    - '%0d'
  condition: selection_keys and selection_newline
fields:
  - config_key
  - config_value
  - instance
  - user
falsepositives:
  - Legitimate multi-line NVIDIA capability strings (unlikely)
level: critical
tags:
  - attack.t1059
  - cve.2026.63298

YARA Rule

rule CVE_2026_63298_LXD_NVIDIA_ConfigInjection
{
    meta:
        author = "valtersit.com"
        description = "Detects newline-injection attempts in LXD NVIDIA config keys"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-63298"
        date = "2026-01-01"
        cve = "CVE-2026-63298"

    strings:
        $k1 = "nvidia.driver.capabilities" ascii wide nocase
        $k2 = "nvidia.require" ascii wide nocase
        $nl = /\x0a|\x0d|\x25\x30\x61|\x25\x30\x64/

    condition:
        ($k1 or $k2) and $nl
}

Suricata IDS Rule

alert tcp $HOME_NET any -> $HOME_NET 8443 (msg:"LXD NVIDIA Config Newline Injection Attempt (CVE-2026-63298)"; flow:to_server,established; content:"nvidia.driver.capabilities"; nocase; content:"nvidia.require"; nocase; pcre:"/(nvidia\.(driver\.capabilities|require\.[a-z0-9_.-]+)).{0,256}(%0a|%0d|\\n|\\r)/iU"; classtype:attempted-admin; sid:202663298; rev:1; reference:cve,2026-63298; metadata:created_at 2026_01_01, updated_at 2026_01_01;)

Elastic Detection

sequence by process.entity_id with maxspan=5s
  [process where process.name in ("lxd", "lxd-agent") and process.args : "*config*"]
  [file where file.name == "lxc.conf" and file.path : "*/lxc.conf" and file.Ext.extension == "conf"]

Splunk SPL Query

index=* (sourcetype=lxd OR sourcetype=syslog OR sourcetype=auditd)
| search ("nvidia.driver.capabilities" OR "nvidia.require")
| rex field=_raw "(?<cfgval>nvidia\.(?:driver\.capabilities|require\.[a-zA-Z0-9_.-]+)[^\"]*)"
| where match(cfgval, "(%0a|%0d|\\n|\\r)")
| stats count values(cfgval) as values by host, user, src
| sort -count

Wazuh OSSEC Rule

<group name="lxd,cve-2026-63298,">
  <rule id="202663298" level="15">
    <decoded_as>json</decoded_as>
    <field name="config_key">nvidia\.(driver\.capabilities|require\..*)</field>
    <regex>config_value":\s*"[^"]*(\\n|\\r|%0a|%0d)</regex>
    <description>CVE-2026-63298: LXD NVIDIA config value contains newline injection attempt</description>
    <mitre>
      <id>T1059</id>
    </mitre>
    <group>cve_2026_63298,attack.command_and_control,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 3/4 (LIKELY) — two independent sources (NVD, OSV) confirm a fix exists. Three OSV-referenced commits remain flagged unfixed in package metadata, so version verification is required before assuming a given build is protected.

1) Immediate mitigations

• Restrict LXD API access: firewall/segment the LXD API port (8443) and require mutual TLS with tightly scoped client certificates; remove authorization for untrusted users to set NVIDIA-related config keys.
• Audit all instance configurations for nvidia.driver.capabilities and nvidia.require.* values containing newline or URL-encoded newline sequences and remediate where found.
• If NVIDIA config keys are not in use, avoid granting write access to them entirely (least privilege on LXD projects/roles).

2) Patch / upgrade steps

• Upgrade LXD to the version referenced by Canonical's advisory for CVE-2026-63298 (snap: sudo snap refresh lxd; distro packages: apply the vendor security update). Cross-check against the OSV entry and the three affected commits before declaring a deployment fixed.
• Restart the LXD daemon and re-verify that configuration ingestion sanitizes newlines in the named keys.

3) Long-term hardening

• Treat all user-supplied configuration values as untrusted: any value rendered into a line-oriented file must escape/strip control characters.
• Enforce strict role-based access so instance-configuration writers cannot influence host-level runtime directives.
• Monitor LXD configuration mutations and lxc.conf regeneration as security-relevant events (see detection rules above).
• Track Canonical security advisories and OSV feeds; re-scan after each LXD release.

References

1. NVD — CVE-2026-63298: https://nvd.nist.gov/vuln/detail/CVE-2026-63298
2. OSV — LXD / CVE-2026-63298 package advisory (Canonical ecosystem, references commits 1e1349e3cbf30c1b2ce74e531d4dd0fd52c45be1, 761d134ceabd306f57acfb0ca51f59b03751a5b0, 03aab09f5b5cbdada00c6539877dcf5932fcde98)
3. Canonical Security Notices / LXD release notes: https://canonical.com/security
4. MITRE CWE-78 — Improper Neutralization of Special Elements used in an OS Command: https://cwe.mitre.org/data/definitions/78.html

Threat actor / exploit-in-the-wild status: No CISA KEV listing and no confirmed in-the-wild campaign identified in the supplied intelligence. EPSS is low (0.00355). PoC status is Public; exploit code and Nuclei templates were not observed. Monitor for proof-of-concept publication, which would materially raise exploitation risk given the CVSS 9.9 severity.