CVE-2026-40226

What it actually does

CVE-2026-40226 is a local, high-privilege container escape issue in systemd-nspawn affecting systemd versions 233 through 259 before 260. A user with sufficient privileges to influence or provide a crafted optional nspawn configuration file can trigger behavior that breaks expected container isolation and performs actions on the host. If successfully exploited, the impact is host-level compromise of confidentiality, integrity, and availability from a container-management context. The high attack complexity and requirement for high privileges limit opportunistic exploitation, but the consequence is severe where untrusted or semi-trusted users can create, modify, or launch nspawn containers.

Why it matters to the business

Organizations using systemd-nspawn for containerized workloads, build environments, development sandboxes, CI jobs, or lightweight service isolation could lose the security boundary between a container and its host. A successful escape may allow an attacker to access host data, alter host configuration, disrupt services, or pivot to other workloads on the same system. The current EPSS is very low and stable, the vulnerability is not listed in CISA KEV, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely at present; however, systems that allow users or automation to supply nspawn configuration files should treat this as a meaningful host-compromise risk.

How an attack unfolds

An attacker first needs local access and high privileges in a context where systemd-nspawn is used, such as the ability to create or run an nspawn container or provide optional configuration consumed by nspawn. The attacker crafts a malicious optional configuration file that abuses the vulnerable nspawn handling in affected systemd releases. When nspawn processes that configuration during container startup or management, the intended isolation assumptions can be bypassed and an action can occur on the host rather than remaining confined to the container. The attacker can then use the escaped host-level effect to read sensitive host files, modify system state, plant persistence, interfere with services, or move laterally from the host. There are no named threat actors or active exploitation reports associated with this issue in the provided data.

How to fix it

Upgrade systemd to version 260 or later, or apply the vendor backported fix for the affected operating system distribution. Because no per-package fixed versions were provided, use the security advisory and package repositories for the relevant Linux distribution to identify the corrected systemd build. After updating, restart affected services and reboot hosts where required so the patched systemd-nspawn components are active. As interim mitigation, restrict who can create, edit, or run systemd-nspawn containers; prevent untrusted users or automation from supplying optional nspawn configuration files; review permissions on nspawn-related configuration directories; avoid running untrusted workloads with systemd-nspawn on affected hosts; and prefer hardened isolation controls such as MAC policy, least privilege, separate build hosts, and host filesystem restrictions.

How to confirm the fix worked

Confirm the installed systemd version is 260 or later, or verify that the distribution package changelog includes the vendor backport for CVE-2026-40226. Check package inventory across hosts for systemd versions 233 through 259 and prioritize those where systemd-nspawn is installed or actively used. Validate that nspawn-related configuration files are owned by trusted administrative accounts and are not writable by untrusted users, build jobs, or application service accounts. Test representative nspawn workloads after patching to ensure container startup behavior remains functional. Where a vendor backport is used, do not rely solely on the upstream version number; confirm the package release notes or advisory explicitly mention the fix.

Typical attack path

1. Gain local access to a system where systemd-nspawn is installed and used.
2. Obtain high-privilege control over container launch, container configuration, or optional nspawn configuration files.
3. Create or modify a crafted optional systemd-nspawn configuration file that triggers the escape condition.
4. Start or cause systemd-nspawn to process the crafted configuration.
5. Abuse the escape-to-host behavior to affect host files, processes, configuration, or services.
6. Perform post-exploitation actions such as credential access, persistence, service disruption, or lateral movement.

How to detect it

To determine whether exploitation already occurred, focus on hosts that run systemd-nspawn and review activity around container starts, configuration changes, and unexpected host-level modifications. Collect system journal logs, auditd records, package manager logs, shell history for administrative users, file integrity monitoring alerts, and endpoint telemetry for process execution involving systemd-nspawn or machinectl. Look for nspawn invocations that reference unusual or recently created optional configuration files, changes to nspawn configuration directories shortly before container startup, host filesystem changes made by accounts associated with container management, and privileged process execution that follows nspawn activity. Investigate unexpected writes to system directories, new systemd unit files, new privileged users or SSH keys, altered sudoers files, unusual mounts, or service disruptions coinciding with nspawn launches. Because no public exploit indicators are provided, detection should be behavior-based rather than signature-based.

• systemd-nspawn
• machinectl
• /etc/systemd/nspawn/
• *.nspawn
• /run/systemd/nspawn/
• /var/lib/machines/
• SYSTEMD_NSPAWN
• Created slice machine.slice
• Started Container
• New machine

What your security team should do

• Inventory Linux hosts using systemd-nspawn and identify systems running systemd versions 233 through 259.
• Prioritize remediation on multi-user hosts, CI/build infrastructure, development sandboxes, and any environment where users or jobs can influence nspawn configuration.
• Upgrade to systemd 260 or a vendor-fixed backport, then reboot or restart affected components as required by the operating system vendor.
• Audit permissions and ownership of nspawn configuration paths and remove write access for non-administrative users and automation that does not require it.
• Temporarily suspend use of systemd-nspawn for untrusted workloads on affected systems until patched.
• Monitor for unexpected host file modifications, privileged process execution, or configuration changes temporally associated with nspawn container starts.
• Track vendor advisories because fixed package versions may differ across Linux distributions due to backporting.