A security issue in Omarchy’s default Docker configuration meant that essentially every program running in a user’s desktop session could escalate to root without a password, sudo, or a privilege prompt. The problem stemmed from Omarchy configuring its default user as a member of the Linux docker group. On Arch, the Docker daemon runs as root and listens on /var/run/docker.sock. Members of the docker group can communicate with that socket, and Docker itself warns that the docker group grants root‑level privileges to the user. A process with access to the Docker socket can ask the root‑owned Docker daemon to launch a container as root, mount arbitrary portions of the host filesystem into it, operate on those files as root, and run code as root. On affected Omarchy systems, this means that the default user and all processes launched in that user session have access to root. The author demonstrated a proof of concept by trying to read /etc/shadow, which initially failed with a permission denied error. After checking group membership with id, the user was shown to belong to the docker group. Using docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow then revealed the shadow file, showing that an ordinary user process could read a file normally only readable by root. Because Linux supplementary groups are inherited by child processes, the docker group membership propagates throughout the entire user session. Walking the process tree below the user’s systemd –user instance showed the docker group present on essentially every normal process in the session. This means nearly every process where untrusted code could run—including AI coding agents and agent harnesses, web browsers, editors and IDEs, npm scripts, random development tools, and background processes—could obtain root access. Consequently, a compromise of a normal user application could immediately become a full machine compromise. The configuration was opt‑out rather than opt‑in; users did not have to actually use Docker for the setting to apply, and the security trade‑off was not explained to the user. Omarchy’s development‑tools documentation mentioned the Docker group, stating that Omarchy installs everything needed to run Docker well, including the user group changes needed to run Docker as the normal user and not as root. The author noted that the phrasing could lead a reader to infer a rootless mode, which was not the case. The issue affected versions prior to 4.0.1; the author tested it on the latest 3.x ISO (3.8.4) and confirmed it was impacted. A timeline of commits shows the docker group membership was introduced on June 1, 2025, temporarily disabled on June 2, 2025, re‑enabled on June 17, 2025, and finally removed from the default configuration on August 24, 2026. The author reported the issue privately through the project’s responsible‑disclosure process; the underlying configuration has since been patched, prompting the public disclosure to inform users to update to version 4.0.1. The discussion also notes that developers are high‑value targets because their machines often store credentials in plain‑text dotfiles and accumulate access to systems, and suggests Podman as a daemonless alternative that does not require root access for containers.
