CVE-2026-40226 is a systemd-nspawn container escape vulnerability, published in April 2026 and listed by Microsoft’s Security Response Center, affecting systemd versions 233 through 259 before the fixed 260 release and certain backported 257, 258, and 259 patch levels. The uncomfortable part is not that every Linux box is suddenly exposed; it is that the bug sits at the border where administrators often assume container tooling has turned local trust into a hard security boundary. In practice, this is a reminder that container-adjacent does not mean container-proof, especially when image metadata and host-side launch behavior meet. For WindowsForum readers, the Microsoft angle matters because modern Windows estates are rarely Windows-only anymore: WSL, Azure Linux images, CI runners, developer workstations, appliance-like Linux guests, and mixed container pipelines now share the same administrative blast radius.
Microsoft’s presence in this story is easy to misread. CVE-2026-40226 is not a Windows kernel flaw, not a Hyper-V escape, and not a bug in WSL itself based on the public advisory language. It is a vulnerability in systemd-nspawn, the lightweight container and machine manager shipped with systemd on Linux systems.
But Microsoft publishing or tracking the CVE through MSRC changes the audience. A systemd issue that might once have lived purely in a Linux distribution tracker now lands in the same vulnerability workflow used by administrators who manage Microsoft Defender, Azure assets, Microsoft Update guidance, and hybrid fleet dashboards. That is the right place for it, because the modern Microsoft estate includes far more Linux than the old “Windows server room” mental model admits.
The vulnerability affects nspawn in systemd versions 233 through 259 before 260. Public advisory data also identifies patched backport lines at 257.12, 258.6, and 259.4, which matters because many distributions do not simply jump to the newest upstream systemd release. They ship maintained branches with selected fixes, so “am I on systemd 260?” is the wrong first question for a Debian, Ubuntu, Fedora, Azure Linux, or enterprise Linux administrator.
The core description is short enough to sound almost harmless: an escape-to-host action can occur via a crafted optional configuration file. The real significance is buried in the phrase “optional configuration file.” Optional files are precisely the kind of thing administrators may allow to travel with images, templates, build artifacts, or test environments because they are not thought of as the primary executable payload.
That usefulness is also why this bug is interesting. nspawn is commonly treated as infrastructure glue: the thing that spins up the environment before the work begins. Security reviews often focus on what runs inside the container, whether the container has network access, whether bind mounts are read-only, and whether the host is patched. CVE-2026-40226 points at an earlier moment: the interpretation of configuration that determines what the container actually is.
According to the systemd advisory, nspawn supports configuration files that drive container behavior. Those files can accompany images, but they require privileges to be stored in the directories where nspawn automatically picks them up. The vulnerability involves parsing bugs affecting the
That is not a classic “break out after compromise” story. It is more like a rigged stage door. The container boundary is undermined at the moment the machine is launched, before the administrator has any comforting signal that the expected isolation boundary exists.
The impact ratings are high for confidentiality, integrity, and availability. That is the part administrators should not skim past. If successfully exploited in the right circumstances, this is a serious loss-of-boundary issue, not a cosmetic bug or a logging mishap.
The score is pulled down because the attack vector is local, the attack complexity is high, and the privileges required are high. In plain English, an attacker needs meaningful local foothold and the right conditions around where nspawn reads its configuration. This is not a wormable Internet-facing vulnerability, and it should not be triaged like one.
But enterprise risk is not only about anonymous remote attackers. Build systems, shared development hosts, CI runners, lab machines, jump boxes, appliance build pipelines, and multi-user Linux servers all create places where “local” and “privileged enough” are not theoretical. The attacker may be a compromised build account, a poisoned image source, a malicious insider, or a lower-tier automation identity that should never have been able to reshape the host.
In many organizations, executables trigger scanning, code review, signing requirements, or quarantine rules. Config files often get treated as paperwork. They are copied with images, checked into repositories, templated by automation, accepted from upstream projects, or tweaked in troubleshooting sessions and then forgotten.
CVE-2026-40226 makes that habit look sloppy. If an optional configuration file can influence root filesystem selection, user binding, or ephemeral behavior at container launch time, then it is not merely descriptive. It is operational input to a privileged host process.
The systemd workaround says to sanitize storage directories so that no
Developer workstations may run WSL distributions with systemd enabled. Build farms may produce Linux artifacts on Windows-managed infrastructure. Azure estates may include Linux VMs, container hosts, AKS nodes, appliance images, and vendor-managed Linux components. Security teams may ingest MSRC entries into vulnerability management systems without caring whether the affected component is Windows-native or open source.
That does not mean every Windows 11 laptop with WSL is vulnerable in a meaningful way. The bug is specifically about systemd-nspawn and its configuration handling. A user merely having systemd present in a WSL distribution is not the same as using nspawn to launch privileged containers from image directories that include trusted-by-default config files.
The point is narrower and more useful: administrators should inventory where systemd-nspawn is actually installed and used. On some systems it may be absent, unused, or installed only as part of a broader systemd package. On others it may be embedded in workflows that nobody has touched since the engineer who wrote the build script left the company.
Enterprise Linux patching rarely means “install the newest upstream thing.” It means consuming a vendor-maintained build that may carry hundreds of security fixes without changing the major version in a way that looks satisfying to someone checking
A scanner that flags every systemd 257 installation as vulnerable without checking distribution backports may waste time. A human who sees “we are not on 260, therefore we are doomed” may also be wrong. Conversely, a team that assumes “our distro backports everything” without confirming the specific package advisory may leave a real escape condition open.
The operational answer is to check the distribution’s security channel, not just upstream GitHub. If the distro has shipped the relevant fix into its systemd package, the host may be remediated even if it does not report systemd 260. If the distro has not, the workaround around
Still, availability is not the only reason administrators should care. The public CVSS vector rates confidentiality and integrity as high as well. A container spawned unexpectedly on the host root filesystem with elevated privileges is not merely a denial-of-service event in the ordinary sense.
The deeper worry is administrative expectation. The operator thinks they are booting a contained image. The host may instead be exposed as the operating environment. That mismatch is where data theft, tampering, persistence, and destructive actions can follow.
Security incidents often begin with such mismatches. The breach is not always a spectacular exploit chain; sometimes it is a trusted automation path doing precisely the wrong privileged thing because the input it trusted was not actually trustworthy.
nspawn’s
This is not unique to systemd. The broader pattern appears across infrastructure tooling: compose files, Helm charts, cloud-init snippets, unit overrides, CI YAML, Terraform modules, package hooks, and installer manifests. They are all “just configuration” until they are interpreted by something with credentials, filesystem access, or authority over machines.
CVE-2026-40226 belongs to that larger family. It is a reminder that modern infrastructure compromise often travels through declarative control planes rather than obvious binaries.
But shared automation is full of semi-privileged identities. CI services can write artifacts. Deployment users can stage images. Build scripts can invoke privileged helper commands. Administrators sometimes grant narrow sudo rules that are narrow only in appearance, because the allowed command reads complex configuration from paths the user can influence.
Those are the environments where this class of flaw becomes practical. The attacker does not need global root from the beginning if they can control the thing that root later consumes. The exploit path is less “I break the wall” and more “I hand the gatekeeper a forged map.”
Defenders should therefore examine not only who can run systemd-nspawn, but who can write to the image directories and configuration paths it consumes. The write side of the trust boundary is just as important as the execute side.
The difficult part is discovering all the places where
This is where defenders should resist the urge to treat the CVE as a package-only exercise. Patching is necessary, but path hygiene matters too. If your operational model allows untrusted image-adjacent configuration to be auto-discovered by privileged tooling, CVE-2026-40226 is only the latest reason to revisit that design.
The cleaner model is explicitness. Privileged launchers should consume configuration from controlled locations, with ownership and permissions that match the risk. If image-provided metadata is needed, it should be reviewed or transformed before it crosses into a trusted execution path.
That shift can confuse administrators who still map vendor advisories to operating system ownership. A Microsoft CVE listing does not automatically mean the flaw is in Windows. It may mean the affected component appears in Microsoft-supported images, cloud offerings, container ecosystems, or customer environments Microsoft tooling is expected to help defend.
For WindowsForum’s audience, that is a feature rather than a nuisance. The best patch programs already stopped caring whether the vulnerable code was written in Redmond, Raleigh, Berlin, or a maintainer’s spare room. They care where the code runs, what privileges it has, and which business process fails when it is compromised.
CVE-2026-40226 is therefore a small but useful test of organizational maturity. If the response is “not our platform,” the asset inventory is probably lying. If the response is “where do we use nspawn, who can write its config, and which vendor package contains the fix,” the program is asking the right questions.
That said, container escape language deserves attention even when the score is Medium. The whole point of container tooling is to let administrators run one environment inside another while keeping the host in charge. If the launch path can be confused into using the host root filesystem, the trust model has failed at a particularly sensitive point.
The most exposed organizations are likely to be the ones with image-heavy automation and weak provenance around ancillary files. A developer downloading a machine image for local testing is a different risk profile from a production build worker that automatically launches images supplied by multiple teams. A single-user workstation is different from a shared host where “local” access is available to many identities.
The right severity, then, is contextual. For many systems, patch in the normal security cycle and verify no risky
Start with Linux hosts that are part of Windows-managed infrastructure: Azure VMs, self-hosted runners, package builders, test labs, golden-image factories, and developer platforms. Then look for explicit invocations of
The answer may be pleasantly boring. Many environments will discover that nspawn is not installed, not used, or not reachable by less-trusted users. That is still useful evidence, and it should be recorded so the next CVE does not restart the same debate from scratch.
Where nspawn is used, the fix path is clear: apply the vendor’s patched systemd package or move to a fixed upstream line, then sanitize configuration paths and remove trust from image-adjacent
Microsoft’s CVE Listing Pulls Linux Plumbing Into the Windows Admin’s Patch Queue
Microsoft’s presence in this story is easy to misread. CVE-2026-40226 is not a Windows kernel flaw, not a Hyper-V escape, and not a bug in WSL itself based on the public advisory language. It is a vulnerability in systemd-nspawn, the lightweight container and machine manager shipped with systemd on Linux systems.But Microsoft publishing or tracking the CVE through MSRC changes the audience. A systemd issue that might once have lived purely in a Linux distribution tracker now lands in the same vulnerability workflow used by administrators who manage Microsoft Defender, Azure assets, Microsoft Update guidance, and hybrid fleet dashboards. That is the right place for it, because the modern Microsoft estate includes far more Linux than the old “Windows server room” mental model admits.
The vulnerability affects nspawn in systemd versions 233 through 259 before 260. Public advisory data also identifies patched backport lines at 257.12, 258.6, and 259.4, which matters because many distributions do not simply jump to the newest upstream systemd release. They ship maintained branches with selected fixes, so “am I on systemd 260?” is the wrong first question for a Debian, Ubuntu, Fedora, Azure Linux, or enterprise Linux administrator.
The core description is short enough to sound almost harmless: an escape-to-host action can occur via a crafted optional configuration file. The real significance is buried in the phrase “optional configuration file.” Optional files are precisely the kind of thing administrators may allow to travel with images, templates, build artifacts, or test environments because they are not thought of as the primary executable payload.
The Container Escape Is Hidden in the Launch Path, Not the Workload
systemd-nspawn is not Docker, Kubernetes, or Hyper-V. It is closer to a low-friction tool for booting a directory tree or disk image as a container-like system, often used by distribution builders, developers, test harnesses, package maintainers, and administrators who want machine-style isolation without standing up a full orchestration stack. It can be extremely useful, and it is part of systemd’s long-running effort to make Linux user space more coherent.That usefulness is also why this bug is interesting. nspawn is commonly treated as infrastructure glue: the thing that spins up the environment before the work begins. Security reviews often focus on what runs inside the container, whether the container has network access, whether bind mounts are read-only, and whether the host is patched. CVE-2026-40226 points at an earlier moment: the interpretation of configuration that determines what the container actually is.
According to the systemd advisory, nspawn supports configuration files that drive container behavior. Those files can accompany images, but they require privileges to be stored in the directories where nspawn automatically picks them up. The vulnerability involves parsing bugs affecting the
PivotRoot=, BindUser=, and Ephemeral= options, with the result that the container may be spawned on the host root filesystem instead of the container image, with high privileges.That is not a classic “break out after compromise” story. It is more like a rigged stage door. The container boundary is undermined at the moment the machine is launched, before the administrator has any comforting signal that the expected isolation boundary exists.
A Medium Score Can Still Describe a Catastrophic Boundary Failure
The published CVSS 3.1 score for CVE-2026-40226 is 6.4, which lands in Medium territory. That is not a typo, and it is not necessarily evidence that the issue is minor. CVSS is doing what CVSS does: balancing impact against exploitability constraints.The impact ratings are high for confidentiality, integrity, and availability. That is the part administrators should not skim past. If successfully exploited in the right circumstances, this is a serious loss-of-boundary issue, not a cosmetic bug or a logging mishap.
The score is pulled down because the attack vector is local, the attack complexity is high, and the privileges required are high. In plain English, an attacker needs meaningful local foothold and the right conditions around where nspawn reads its configuration. This is not a wormable Internet-facing vulnerability, and it should not be triaged like one.
But enterprise risk is not only about anonymous remote attackers. Build systems, shared development hosts, CI runners, lab machines, jump boxes, appliance build pipelines, and multi-user Linux servers all create places where “local” and “privileged enough” are not theoretical. The attacker may be a compromised build account, a poisoned image source, a malicious insider, or a lower-tier automation identity that should never have been able to reshape the host.
The Optional Config File Is the Trust Boundary Everyone Forgot
The most dangerous software inputs are often the ones that look like administration rather than content. A.nspawn file is not a random attachment from the Internet. It is configuration, which means it tends to pass through different mental filters and different controls.In many organizations, executables trigger scanning, code review, signing requirements, or quarantine rules. Config files often get treated as paperwork. They are copied with images, checked into repositories, templated by automation, accepted from upstream projects, or tweaked in troubleshooting sessions and then forgotten.
CVE-2026-40226 makes that habit look sloppy. If an optional configuration file can influence root filesystem selection, user binding, or ephemeral behavior at container launch time, then it is not merely descriptive. It is operational input to a privileged host process.
The systemd workaround says to sanitize storage directories so that no
.nspawn files are used, or so that they do not use the vulnerable options. That is practical advice, but it is also a philosophy lesson. If a privileged launcher automatically discovers configuration beside an image, the storage location becomes part of the trusted computing base.This Is Where Windows Shops Meet Linux Reality
For a Windows-centric administrator, the temptation is to file this under “Linux people problem.” That would be a mistake. Most Windows estates now have Linux seams, and those seams tend to appear exactly where privilege and automation are dense.Developer workstations may run WSL distributions with systemd enabled. Build farms may produce Linux artifacts on Windows-managed infrastructure. Azure estates may include Linux VMs, container hosts, AKS nodes, appliance images, and vendor-managed Linux components. Security teams may ingest MSRC entries into vulnerability management systems without caring whether the affected component is Windows-native or open source.
That does not mean every Windows 11 laptop with WSL is vulnerable in a meaningful way. The bug is specifically about systemd-nspawn and its configuration handling. A user merely having systemd present in a WSL distribution is not the same as using nspawn to launch privileged containers from image directories that include trusted-by-default config files.
The point is narrower and more useful: administrators should inventory where systemd-nspawn is actually installed and used. On some systems it may be absent, unused, or installed only as part of a broader systemd package. On others it may be embedded in workflows that nobody has touched since the engineer who wrote the build script left the company.
The Patch Story Is a Branch Story
The upstream fix line is straightforward at first glance: systemd 260 fixes the issue. The advisory also lists patched versions 259.4, 258.6, and 257.12. Those backports are not a footnote; they are the versioning reality most administrators live in.Enterprise Linux patching rarely means “install the newest upstream thing.” It means consuming a vendor-maintained build that may carry hundreds of security fixes without changing the major version in a way that looks satisfying to someone checking
systemd --version. This is why CVE triage by naive version comparison can generate both false alarms and false comfort.A scanner that flags every systemd 257 installation as vulnerable without checking distribution backports may waste time. A human who sees “we are not on 260, therefore we are doomed” may also be wrong. Conversely, a team that assumes “our distro backports everything” without confirming the specific package advisory may leave a real escape condition open.
The operational answer is to check the distribution’s security channel, not just upstream GitHub. If the distro has shipped the relevant fix into its systemd package, the host may be remediated even if it does not report systemd 260. If the distro has not, the workaround around
.nspawn files and vulnerable options becomes more important until package updates arrive.Availability Language Understates the Host Compromise Anxiety
The user-supplied MSRC language emphasizes total loss of availability: an attacker can fully deny access to resources in the impacted component, either persistently or while the attack is sustained. That is one way to describe the risk, and availability is genuinely important for container hosts and build systems. A host that can be wedged, repurposed, or made unavailable at the container launch layer can halt pipelines and services in ways that are painful to diagnose.Still, availability is not the only reason administrators should care. The public CVSS vector rates confidentiality and integrity as high as well. A container spawned unexpectedly on the host root filesystem with elevated privileges is not merely a denial-of-service event in the ordinary sense.
The deeper worry is administrative expectation. The operator thinks they are booting a contained image. The host may instead be exposed as the operating environment. That mismatch is where data theft, tampering, persistence, and destructive actions can follow.
Security incidents often begin with such mismatches. The breach is not always a spectacular exploit chain; sometimes it is a trusted automation path doing precisely the wrong privileged thing because the input it trusted was not actually trustworthy.
The Bug Rewards Messy Image Supply Chains
The advisory’s note that configuration files can be downloaded together with images is the part that should make build engineers uncomfortable. Container and machine images are increasingly treated as portable artifacts, but the metadata around them is often less controlled than the images themselves. A disk image may be verified while adjacent helper files are not.nspawn’s
.nspawn files can be convenient because they encode how a given image should be launched. Convenience, however, becomes a liability when launch behavior is privileged and automatic. If a crafted optional file rides along with an image into a trusted storage directory, the host may honor it before anyone has reviewed its semantics.This is not unique to systemd. The broader pattern appears across infrastructure tooling: compose files, Helm charts, cloud-init snippets, unit overrides, CI YAML, Terraform modules, package hooks, and installer manifests. They are all “just configuration” until they are interpreted by something with credentials, filesystem access, or authority over machines.
CVE-2026-40226 belongs to that larger family. It is a reminder that modern infrastructure compromise often travels through declarative control planes rather than obvious binaries.
High Privilege Requirements Do Not Save Shared Automation
The high-privilege requirement is real, and it should prevent panic. An unprivileged user randomly dropping a file anywhere on a host should not be able to trigger this vulnerability unless they can get that file into a location nspawn uses and influence a privileged launch. That distinction matters.But shared automation is full of semi-privileged identities. CI services can write artifacts. Deployment users can stage images. Build scripts can invoke privileged helper commands. Administrators sometimes grant narrow sudo rules that are narrow only in appearance, because the allowed command reads complex configuration from paths the user can influence.
Those are the environments where this class of flaw becomes practical. The attacker does not need global root from the beginning if they can control the thing that root later consumes. The exploit path is less “I break the wall” and more “I hand the gatekeeper a forged map.”
Defenders should therefore examine not only who can run systemd-nspawn, but who can write to the image directories and configuration paths it consumes. The write side of the trust boundary is just as important as the execute side.
The Workaround Is Simple, but the Audit Is Not
The upstream workaround is admirably direct: sanitize storage directories so that.nspawn files are not used, or ensure they do not use PivotRoot=, BindUser=, or Ephemeral=. For a single lab host, that is quick. For a fleet with years of accumulated build machinery, it may be a scavenger hunt.The difficult part is discovering all the places where
.nspawn files matter. Some administrators will know immediately because nspawn is a deliberate part of their workflow. Others may find it inside distribution build scripts, image test harnesses, old documentation, or internal tooling that nobody thinks of as a container platform.This is where defenders should resist the urge to treat the CVE as a package-only exercise. Patching is necessary, but path hygiene matters too. If your operational model allows untrusted image-adjacent configuration to be auto-discovered by privileged tooling, CVE-2026-40226 is only the latest reason to revisit that design.
The cleaner model is explicitness. Privileged launchers should consume configuration from controlled locations, with ownership and permissions that match the risk. If image-provided metadata is needed, it should be reviewed or transformed before it crosses into a trusted execution path.
Microsoft’s Security Feed Is Becoming a Hybrid Infrastructure Map
The MSRC entry is also a sign of how vulnerability management has changed. Microsoft no longer lives only at the boundary of Windows, Office, Exchange, SQL Server, and Azure control planes. It is a distributor, consumer, scanner, and security publisher for a hybrid estate that includes Linux and open-source infrastructure.That shift can confuse administrators who still map vendor advisories to operating system ownership. A Microsoft CVE listing does not automatically mean the flaw is in Windows. It may mean the affected component appears in Microsoft-supported images, cloud offerings, container ecosystems, or customer environments Microsoft tooling is expected to help defend.
For WindowsForum’s audience, that is a feature rather than a nuisance. The best patch programs already stopped caring whether the vulnerable code was written in Redmond, Raleigh, Berlin, or a maintainer’s spare room. They care where the code runs, what privileges it has, and which business process fails when it is compromised.
CVE-2026-40226 is therefore a small but useful test of organizational maturity. If the response is “not our platform,” the asset inventory is probably lying. If the response is “where do we use nspawn, who can write its config, and which vendor package contains the fix,” the program is asking the right questions.
The Practical Read Is Narrow, but Not Comfortable
No one should inflate this into a universal Linux container apocalypse. The vulnerability requires specific systemd-nspawn usage and specific trust conditions around optional configuration files. It has high attack complexity and high privilege requirements, and it is not the same category of emergency as a remotely exploitable pre-authentication service bug.That said, container escape language deserves attention even when the score is Medium. The whole point of container tooling is to let administrators run one environment inside another while keeping the host in charge. If the launch path can be confused into using the host root filesystem, the trust model has failed at a particularly sensitive point.
The most exposed organizations are likely to be the ones with image-heavy automation and weak provenance around ancillary files. A developer downloading a machine image for local testing is a different risk profile from a production build worker that automatically launches images supplied by multiple teams. A single-user workstation is different from a shared host where “local” access is available to many identities.
The right severity, then, is contextual. For many systems, patch in the normal security cycle and verify no risky
.nspawn usage exists. For shared builders, privileged test infrastructure, and image ingestion pipelines, treat this as a boundary review.The Admin’s Job Is to Find the Hidden nspawn
Most security teams will not find CVE-2026-40226 by asking application owners whether they run systemd-nspawn. The better approach is to query packages, scripts, service units, sudo rules, and build definitions. Tooling that no one thinks of as a production dependency has a habit of becoming one.Start with Linux hosts that are part of Windows-managed infrastructure: Azure VMs, self-hosted runners, package builders, test labs, golden-image factories, and developer platforms. Then look for explicit invocations of
systemd-nspawn, machinectl, and service units based on the nspawn template. Finally, check writable image stores and the presence of .nspawn files.The answer may be pleasantly boring. Many environments will discover that nspawn is not installed, not used, or not reachable by less-trusted users. That is still useful evidence, and it should be recorded so the next CVE does not restart the same debate from scratch.
Where nspawn is used, the fix path is clear: apply the vendor’s patched systemd package or move to a fixed upstream line, then sanitize configuration paths and remove trust from image-adjacent
.nspawn files unless there is a deliberate reason to keep them.The Small File Beside the Image Is Now Part of the Threat Model
Here is the operational version of the story, stripped of both panic and complacency.- CVE-2026-40226 affects systemd-nspawn in systemd 233 through 259 before the fixed 260 release, with patched backports identified for 257.12, 258.6, and 259.4.
- The bug involves malformed optional
.nspawnconfiguration affecting options such asPivotRoot=,BindUser=, andEphemeral=. - The practical risk depends on whether a host actually uses systemd-nspawn and whether less-trusted users or artifacts can influence configuration files that privileged launches consume.
- The Medium CVSS score reflects local access, high complexity, and high required privileges, but the potential impact includes high confidentiality, integrity, and availability loss.
- The immediate mitigation is to patch through the distribution vendor and sanitize nspawn storage directories so untrusted
.nspawnfiles or vulnerable options are not honored. - Windows administrators should treat the MSRC listing as a hybrid-fleet signal, not as evidence of a native Windows flaw.
References
- Primary source: MSRC
Published: 2026-05-27T01:40:43-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: securityvulnerability.io
CVE-2026-40226 : Systemd Nspawn Vulnerability in Specific Versions
Learn about a vulnerability in Systemd's Nspawn affecting versions 233 to 259, allowing escape-to-host actions.securityvulnerability.io
- Related coverage: service.securitm.ru
CVE-2026-40226 - CVE уязвимости - SECURITM
In nspawn in systemd 233 through 259 before 260, an escape-to-host action can occur via a crafted optional config file.service.securitm.ru
- Related coverage: thehackerwire.com
CVE-2026-40226 - Medium Vulnerability
CVE-2026-40226 is a Medium severity vulnerability (CVSS 6.4). In nspawn in systemd 233 through 259 before 260, an escape-to-host action can occur via a crafted optional config file.www.thehackerwire.com
- Related coverage: sentinelone.com
CVE-2026-40226: systemd nspawn Privilege Escalation Flaw
CVE-2026-40226 is a privilege escalation vulnerability in systemd nspawn. Learn about its impact, affected versions, and mitigation methods.www.sentinelone.com