CVE-2026-4105

What it actually does

CVE-2026-4105 is a local privilege escalation flaw in systemd-machined, the systemd service that manages local virtual machines and containers through D-Bus. The vulnerable RegisterMachine D-Bus method does not sufficiently validate the supplied machine class parameter. A low-privileged local user may be able to create or leave behind an attacker-controlled machine object that is still treated as privileged by systemd-machined. If successful, the attacker can invoke methods on that object and cause commands to execute with root privileges on the host. Exploitation requires local access, valid low-privileged credentials, and specific interaction/conditions, but successful exploitation can fully compromise confidentiality, integrity, and availability of the host.

Why it matters to the business

An attacker who already has limited access to a Linux system could turn that access into full administrator control. This can enable theft of sensitive data, installation of persistence, disabling of security tooling, lateral movement, tampering with hosted workloads, and service disruption. The current EPSS score is low and it is not listed in CISA KEV, which suggests no broad public exploitation signal at this time; however, privilege escalation flaws are commonly chained with initial access vulnerabilities, so exposed multi-user Linux systems, developer workstations, container/VM hosts, and servers running systemd-machined should still be prioritized for remediation.

How an attack unfolds

An attacker first obtains local, unprivileged access to a Linux host where systemd-machined is installed and reachable over the system D-Bus. The attacker then sends a crafted RegisterMachine request to org.freedesktop.machine1, supplying a machine class value that is not properly validated. Under vulnerable conditions, systemd-machined may create or retain a machine object controlled by the attacker while still exposing privileged management methods. The attacker then interacts with that object over D-Bus to trigger privileged behavior, ultimately causing arbitrary commands to run as root on the host. After gaining root, the attacker may add users or SSH keys, modify sudoers or systemd unit files, deploy malware, disable logging or endpoint controls, and use the host as a pivot point.

How to fix it

Apply vendor-provided systemd updates as soon as they are available for the affected distribution. No exact fixed package versions were provided in the input, so remediation should be tracked through the operating system vendor’s security advisories for systemd and systemd-machined. Where immediate patching is not possible, reduce exposure by disabling or masking systemd-machined on systems that do not require local machine/container/VM registration functionality, for example by stopping and masking systemd-machined.service and systemd-machined.socket after confirming business impact. Restrict local shell access to trusted users, remove unnecessary accounts, enforce least privilege, and monitor D-Bus access to org.freedesktop.machine1. Avoid broad workarounds that break legitimate container, VM, or development workflows without testing, because systemd-machined may be used by tools such as machinectl, systemd-nspawn, and virtualization/container management stacks.

How to confirm the fix worked

Confirm the installed systemd package version against the relevant Linux distribution advisory once fixed packages are published. Verify whether systemd-machined is present and active using commands such as systemctl status systemd-machined.service and systemctl status systemd-machined.socket. Confirm whether org.freedesktop.machine1 is registered or activatable on the system D-Bus using busctl or equivalent tooling. After patching or mitigation, validate that normal business-required container/VM workflows still function and that unprivileged users cannot create unexpected machine objects through RegisterMachine. Review package-manager history to confirm the systemd update was installed, and where systemd-machined is not needed, confirm the service/socket remain disabled or masked after reboot.

Typical attack path

1. Gain local low-privileged access to a Linux host through credentials, an interactive shell, SSH, a compromised application account, or another vulnerability.
2. Confirm that systemd-machined is installed, active, or D-Bus activatable via org.freedesktop.machine1.
3. Issue a crafted D-Bus RegisterMachine call with a class parameter value that triggers the improper access-control behavior.
4. Obtain or retain an attacker-controlled machine object exposed by systemd-machined.
5. Invoke privileged methods on the machine object to cause root-level command execution on the host.
6. Establish persistence, collect data, alter host configuration, disable defenses, or move laterally.

How to detect it

To determine whether exploitation may have already occurred, review system logs, journald records, auditd events, D-Bus monitoring logs if available, shell history, EDR telemetry, and process execution data for unusual interactions with systemd-machined. Focus on non-administrative users invoking busctl, dbus-send, gdbus, machinectl, or systemd-nspawn, especially followed by new root-owned processes, changes to users/groups, sudoers modifications, SSH key additions, new systemd services, or security-control tampering. In journald, look for unexpected systemd-machined activity, unexpected machine registrations, machine object creation/removal events, or systemd-machined activation at unusual times. In audit logs, correlate D-Bus method calls or executions of D-Bus tooling by low-privileged users with subsequent root-level command execution. Also inspect persistence locations such as /etc/systemd/system/, /etc/sudoers, /etc/sudoers.d/, /root/.ssh/authorized_keys, cron directories, and newly created SUID binaries. Absence of these artifacts does not prove non-exploitation because the specific crafted class value and reliable exploit artifacts are not publicly defined in the supplied data.

• systemd-machined
• org.freedesktop.machine1
• RegisterMachine
• /org/freedesktop/machine1
• busctl call org.freedesktop.machine1
• dbus-send --system --dest=org.freedesktop.machine1
• gdbus call --system --dest org.freedesktop.machine1
• machinectl
• systemd-nspawn
• systemd-machined.service
• systemd-machined.socket
• /etc/systemd/system/
• /etc/sudoers.d/
• /root/.ssh/authorized_keys
• /etc/cron.d/
• /var/spool/cron/

What your security team should do

• Inventory Linux systems running systemd-machined or exposing org.freedesktop.machine1 over the system D-Bus, with priority on shared servers, developer workstations, build systems, container hosts, virtualization hosts, and internet-facing systems where initial access chaining is more likely.
• Track operating system vendor advisories and patch systemd/systemd-machined when fixed packages become available; prioritize systems with multiple local users or higher-value workloads.
• If systemd-machined is not required, stop and mask systemd-machined.service and systemd-machined.socket after compatibility testing.
• Harden local access by removing stale accounts, limiting SSH access, enforcing MFA where applicable, and ensuring application service accounts cannot obtain interactive shells unless required.
• Add monitoring for unusual D-Bus calls to org.freedesktop.machine1, unexpected machine registrations, and suspicious activity by unprivileged users followed by root command execution.
• Investigate any unexplained machinectl, systemd-nspawn, busctl, dbus-send, or gdbus usage by non-administrative users.
• Because this is not currently KEV-listed and has low EPSS, treat it as a defense-in-depth priority unless credible exploit code, exploitation attempts, or vendor emergency guidance emerges.