CVE-2026-23953
Linuxcontainers Incus ≤ 6.0.5
Raw vector
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:NSummary
CVE-2026-23953 is a high-severity CRLF Injection (CWE-93) vulnerability in Linuxcontainers Incus. Its CVSS base score is 8.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Content Injection (T1659); ranked at the 39th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-23953 is a newline injection vulnerability in Incus, a system container and virtual machine manager, affecting versions 6.20.0 and below. The issue arises when a user launches a container with a custom YAML configuration, allowing them to inject newlines into an environment variable. This injection appends unauthorized configuration items to the container's lxc.conf file, including arbitrary lifecycle hooks.
A member of the 'incus' group or any user able to launch containers with custom YAML can exploit this vulnerability. Successful exploitation enables arbitrary command execution on the host system. On IncusOS, attackers must modify the payload to use a writable directory like /tmp for the validation step, which can be verified using a second privileged container mounting /tmp from the host.
The GitHub security advisory (GHSA-x6jc-phwx-hp32) details the issue, with a proof-of-concept script and patch available in referenced attachments. A fix is planned for Incus versions 6.0.6 and 6.21.0, but these have not been released as of the CVE publication on 2026-01-22. The vulnerability has a CVSS v3.1 base score of 8.7 (AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) and is associated with CWE-93.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-3804
Vulnerability Data
Incus is a system container and virtual machine manager. In versions 6.20.0 and below, a user with the ability to launch a container with a custom YAML configuration (e.g a member of the ‘incus’ group) can create an environment variable…
more
containing newlines, which can be used to add additional configuration items in the container’s lxc.conf due to newline injection. This can allow adding arbitrary lifecycle hooks, ultimately resulting in arbitrary command execution on the host. Exploiting this issue on IncusOS requires a slight modification of the payload to change to a different writable directory for the validation step (e.g /tmp). This can be confirmed with a second container with /tmp mounted from the host (A privileged action for validation only). A fix is planned for versions 6.0.6 and 6.21.0, but they have not been released at the time of publication.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V4.2.4
Mitigating Controls (NIST 800-53 r5) AI
Input validation directly stops untrusted data containing CRLF sequences from reaching the component that treats CRLF as a delimiter.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require input neutralization and validation to block CRLF injection.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect CRLF flaws but does not itself implement the neutralization.
Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection.
Application security requirements include rules for neutralizing special characters such as CRLF in inputs.
Secure architecture principles encourage safe handling of untrusted data but do not prescribe specific CRLF controls.
Secure coding standards explicitly require neutralization of CRLF sequences, fully addressing this weakness.