CVE-2026-53657: Privilege Escalation via Overly Permissive Unix Domain Socket in Lima Guest Agent

Lima is an open-source virtual machine manager designed to run Linux virtual machines and container environments, primarily on macOS systems. The utility automates the provisioning of core guest services such as containerd and nerdctl to provide developers with a local container workspace. To coordinate system configurations, port forwarding, and network rules, Lima runs a specialized guest daemon known as lima-guestagent inside the virtual environment.

The lima-guestagent process executes with elevated root privileges within the guest kernel space. This design allows the agent to execute low-level operations such as modifying IPTables rules, managing networking interfaces, and establishing local port-forwarding mappings on behalf of the host machine. When Lima is configured with the QEMU virtualization driver, communications between the host and guest agent are facilitated via a UNIX domain socket designated as /run/lima-guestagent.sock.

The vulnerability, registered as CVE-2026-53657, stems from insecure Discretionary Access Control (DAC) permissions assigned to this Unix domain socket file during initialization. In affected versions of Lima, the socket was created with world-writable file permissions (0o777). This configuration creates an exposed attack surface by allowing any local, unprivileged process executing within the guest virtual machine to read from and write to the socket, bypassing standard access control controls.

The resulting impact is local privilege escalation from any standard guest VM user to the root user. Because the guest agent possesses tunneling capabilities, an unprivileged user can leverage the agent to route traffic to administrative control points. This allows malicious actors to execute arbitrary code or alter administrative system settings with full root-level execution privileges.

The primary technical defect behind CVE-2026-53657 lies in the insecure permissions set during the initialization sequence of the UNIX domain socket. In Go-based daemons, the standard socket instantiation process involves calling net.Listen followed by adjusting the permissions of the resulting file path on the filesystem. The lima-guestagent implementation explicitly adjusted the socket file permissions to 0o777 (world-readable and world-writable), exposing the socket interface to all security contexts inside the VM.

While the socket was meant to allow communication between the host and the guest VM's admin process, setting the permissions to 0o777 ignores local privilege boundaries. Any unprivileged process or container running within the guest can establish a direct local connection to the socket file. This introduces a structural vulnerability because the daemon exposes general-purpose socket tunneling functions designed to forward connections to arbitrary addresses inside the VM.

This architecture results in a classic Confused Deputy vulnerability. When an unprivileged client instructs the root-privileged lima-guestagent to connect to another internal UNIX socket, the guest agent carries out the connection request. When the target service verifies the identity of the incoming connection using the kernel-level SO_PEERCRED socket option, it sees the connection originating from the root user (UID 0), the actual owner of the guest agent process.

The local kernel authenticates the connection as originating from the root user because the credential checking mechanism evaluates the socket-endpoint owner, not the cascading chain of callers. Consequently, the target service grants full administrative authority to the connection. This bypasses the local authorization barriers, allowing an unprivileged user inside the guest VM to manipulate privileged system services such as systemd or D-Bus.

The remediation of CVE-2026-53657 involved replacing the unrestricted 0o777 socket permission logic with a mechanism that transfers file ownership to the primary non-root user and restricts access to user-only read/write (0o600). This ensures only authorized administrators or the primary user who initiated the virtual machine can interact with the guest agent's socket.

Analyzing the code changes in cmd/lima-guestagent/daemon_linux.go shows how the parameter list was updated to track the socket owner UID. The newly added --socket-owner parameter specifies which unprivileged user should hold exclusive rights to the control interface:

// cmd/lima-guestagent/daemon_linux.go
 
	daemonCommand.Flags().Duration("tick", 3*time.Second, "Tick for polling events")
	daemonCommand.Flags().Int("vsock-port", 0, "Use vsock server instead a UNIX socket")
	daemonCommand.Flags().String("virtio-port", "", "Use virtio server instead a UNIX socket")
+	daemonCommand.Flags().Int("socket-owner", 0, "UID of the main user that owns the UNIX socket (0 for root)")
	return daemonCommand

The socket setup routine was updated to conditionally execute the os.Chown system call before restricting the filesystem permissions. By transferring ownership of the socket file to the non-root primary user, the daemon can strictly enforce 0o600 permissions while maintaining compatibility with host-to-guest port-forwarding tools:

// cmd/lima-guestagent/daemon_linux.go
 
			return err
		}
-		if err := os.Chmod(socket, 0o777); err != nil {
+		// The daemon runs as root (for iptables), but the host connects to the
+		// socket as the main user over an SSH local-forward. Hand the socket to
+		// that user so 0600 restricts access to the main user rather than root.
+		if socketOwner > 0 {
+			if err := os.Chown(socket, socketOwner, -1); err != nil {
+				return err
+			}
+		}
+		if err := os.Chmod(socket, 0o600); err != nil {
			return err
		}
		l = socketL

Additionally, the template scripts inside pkg/cidata/cidata.TEMPLATE.d/boot.Linux/25-guestagent-base.sh were updated to populate the --socket-owner argument with ${LIMA_CIDATA_UID}, which represents the UID of the primary user provisioned by cloud-init during VM startup. This change ensures that the guest agent socket is dynamically locked down to the owner of the VM instance.

Exploitation of CVE-2026-53657 requires local access within the guest virtual machine. An attacker must have established a low-privilege execution context inside the VM, such as an unprivileged user shell or a compromised application running in a non-root container container. The attack is entirely local and does not require host-level access to initiate.

First, the attacker identifies the presence of the world-writable socket at /run/lima-guestagent.sock. Because the socket is created with permission mask 0o777, standard unprivileged utilities like socat, nc.openbsd, or custom python scripts can open a stream connection directly to it. No authentication handshake is enforced by the guest agent daemon prior to handling client tunnel directives.

Once connected, the attacker utilizes the tunneling protocol supported by lima-guestagent to request a proxy connection to /run/dbus/system_bus_socket. The guest agent receives this request and, running under root privileges, establishes the outbound connection to the D-Bus socket. Since the D-Bus daemon verifies peer credentials via the SO_PEERCRED socket option, the operating system kernel verifies that the process initiating the connection is indeed lima-guestagent (UID 0), granting root-level access to the D-Bus system bus.

Through this established channel, the attacker can transmit D-Bus control commands to systemd-logind, systemd-networkd, or other system administration services running on the VM. This enables the execution of arbitrary administrative actions, such as spawning new shell processes with root privileges or modifying boot configurations. This completely compromises the security boundary inside the virtual machine.

The direct security consequence of CVE-2026-53657 is a complete compromise of the privilege isolation boundaries within the guest virtual machine. While the CVSS evaluation assigned a High Privileges Required (PR:H) metric, this corresponds to the administrative role of the host operator managing the VM launcher, whereas any standard local user inside the guest can execute the exploit to scale their permissions to root.

Once root execution is achieved inside the guest VM, the attacker gains full control over the local operating system, including the ability to inspect running container memory, modify kernel parameters, and extract sensitive API credentials or SSH keys stored within the virtual disk. In multi-tenant environments or shared container workspaces, this vulnerability invalidates security assurances between distinct user containers.

Furthermore, because Lima is commonly used to run developer container runtimes with direct host mount sharing, a compromise of the guest VM significantly escalates the risk of a container escape to the host macOS system. While a VM boundary still exists, possessing root-level control over the kernel driving the hypervisor client simplifies host-to-guest file system manipulation and exploitation of potential hypervisor vulnerabilities.

To date, there are no documented instances of CVE-2026-53657 being exploited in the wild, nor have any weaponized automated exploits been released publicly. The EPSS score remains low at 0.00129, reflecting the local nature of the vulnerability and the requirement for an active local footprint inside a Lima-managed virtual machine.

Detecting vulnerable installations involves auditing the file system permissions of the active socket within the running guest virtual machine. Security administrators should execute a standard file status inquiry to evaluate the owner and permission flags of the target path:

# Audit the guest agent socket permissions
stat -c "%a %U %G" /run/lima-guestagent.sock

If the returned output is 777 root root, the virtual machine is vulnerable and open to exploitation by local users. If the output is configured as 600 <username> root, the socket has been successfully restricted to the owner of the virtual machine and is secure against unauthorized local access.

To remediate the vulnerability permanently, users must upgrade their local installation of Lima to version 2.1.3 or later on the host machine. Upgrading the host application updates the embedded provisioning scripts, ensuring that newly deployed guest agents run with the correct --socket-owner parameter and execute the socket handoff logic.

In environments where immediate software upgrades are not feasible, administrators can apply a temporary mitigation by manually reconfiguring the socket ownership inside the guest. Running the following sequence as root restricts unauthorized access, although the change may be reverted if the guest daemon restarts:

# Identify the primary VM user's UID (e.g., 1000) and restrict permissions
chown 1000:root /run/lima-guestagent.sock
chmod 0600 /run/lima-guestagent.sock