Severity High — CVSS 3.1: 8.2 (AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) (per Lima) Asset lima-vm/lima — lima-guestagent Unix socket (QEMU driver) Affected Lima <= v2.1.2 Fixed in v2.1.3 (2026-06-19) CVE CVE-2026-53657 (GHSA-2j9v-p4xj-cjw2) TL;DR (for the non-technical reader) Lima runs Linux virtual machines on your laptop — it is the engine behind a lot of local container and dev tooling on macOS and Linux. Inside each VM, Lima runs a small helper process called the guest agent . On the QEMU backend, that agent ran as root and left its control socket open to every user account in the VM. Any unprivileged user in the guest could talk to it and, through a feature meant for connection forwarding, borrow the agent’s root identity to run commands as root — inside that VM . This is a privilege escalation within the guest, not a way out of the VM onto your host. Lima fixed it in v2.1.3 by locking the socket down to a single owner. It only ever affected the QEMU driver; the macOS default (the VZ driver) was never exposed. If you run Lima with --vm-type=qemu , or on Linux, upgrade. What’s vulnerable The Lima guest agent ( lima-guestagent ) runs inside the VM and gives the host a control channel for the things a VM-management tool needs: port forwarding, time synchronisation, and a stream of guest events. The host talks to it over a gRPC API. On the QEMU driver, that API is exposed through a Unix domain socket inside the guest, /run/lima-guestagent.sock . The agent runs as root — it needs root to program iptables for port forwarding. The host reaches the socket over an SSH local-forward, so in normal operation the socket only ever needs to be reachable by Lima’s own machinery. The macOS default driver, VZ (Apple Virtualization.framework), does not use this socket at all — it talks to the agent over a vsock port with host-CID filtering. That path was never affected. The shape of the bug Two design facts combined into a privilege-escalation primitive: The root-owned socket was created world-writable , so any local user in the guest could connect to it. The gRPC server behind it had no authentication — no TLS, no caller check. Anyone who could open the socket could call any RPC. That alone is an exposure problem. What turns it into root execution is one of the RPCs the agent offers: a Tunnel call that opens an outbound connection to a caller-supplied address — and does so under the agent’s own (root) credentials, with no allowlist of where it may connect. So an unprivileged caller can ask the root agent to reach a destination that only root is supposed to reach, and then ride that connection. flowchart LR U["unprivileged guest user"]:::accent S["/run/lima-guestagent.sock world-writable, root-owned"]:::accent G["guest-agent gRPC no authentication"]:::n T["Tunnel RPC dials any address as root"]:::n I["root-only local IPC (reached on the agent's behalf)"]:::n R["command runs as root in the guest"]:::alert U --> S --> G --> T --> I --> R classDef n fill:#1A1A1C,stroke:#2A2A2D,color:#EDEAE3 classDef accent fill:#0A0A0B,stroke:#FF4A1C,color:#EDEAE3 classDef alert fill:#0A0A0B,stroke:#E8342B,color:#EDEAE3 Vulnerable code path The root cause is a single line. When the daemon creates the socket, it sets the mode to world-readable, world-writable: // cmd/lima-guestagent/daemon_linux.go:141 (Lima v2.1.2) if err := os . Chmod ( socket , 0 o777 ); err != nil { return err } The daemon runs as root (it checks os.Geteuid() during startup), and the gRPC server it stands up registers no authentication or authorization interceptors. Mode 0o777 on a root-owned control socket means every account in the VM has a direct, unauthenticated line to a root service. The v2.1.2 source shows the pre-fix daemon. Why this pattern recurs A privileged daemon that exposes a world-accessible IPC socket with no authentication is a recurring footgun in container and VM tooling. The Docker socket is the canonical example: “access to docker.sock is root” is by now folklore, precisely because a permissive socket in front of a privileged service collapses the boundary between the caller and the daemon. The subtler half here is credential confusion . When a process connects to a local IPC service, the service often identifies the peer by its kernel-reported credentials ( SO_PEERCRED ). If a low-privileged client persuades a root daemon to make the connection on its behalf, the downstream service sees the daemon’s identity — root — not the original caller’s. A forwarding primitive that doesn’t constrain its destinations turns “I can talk to a root process” into “I can act as that root process toward anything it can reach.” That is the whole escalation, in one sentence. What we confirmed We reported this through a private GitHub Security Advisory and verified the full chain dynamically against Lima v2.1.2 (QEMU driver, Ubuntu 25.10 arm64): starting from a freshly created, non-sudo guest account, we reached uid=0 command execution inside the VM. We also confirmed that ...