Your browser tab runs as root on Omarchy

On an Omarchy install before 4.0.1, the default user could read /etc/shadow with a single command:

$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...

Run cat /etc/shadow directly and you get permission denied. Route the same read through Docker and the hashes come back. The gap comes from one line of default configuration: Omarchy added its default user to the Linux docker group.

On Arch the Docker daemon runs as root and listens on /var/run/docker.sock. Any member of the docker group can talk to that socket, and anyone who can talk to the socket can ask the root-owned daemon to launch a container, mount arbitrary parts of the host filesystem into it, and act on those files as root. Docker's own documentation states plainly that membership of the docker group grants root-level privileges. The container in the proof of concept mounts / and reads the shadow file; it could just as easily write to it.

What makes this more than a clever one-liner is how Linux handles supplementary groups. Child processes inherit them. The researcher walked the process tree below the user's systemd --user instance and found the docker group present on essentially every normal process in the session. The escalation path is open from anything the user runs: web browsers, editors and IDEs, AI coding agents and their harnesses, npm scripts, assorted development tools, background daemons. Any one of those running untrusted code, a malicious dependency, a compromised extension, a prompt-injected agent, goes straight from user-level code execution to full root on the box.

The configuration was opt-out, not opt-in. A user who never ran a single container still had the membership applied to their default account, and nothing in the install explained the tradeoff. Omarchy's development-tools documentation did mention it, describing "the user group changes needed for you to run Docker as the normal user and not as root." A reasonable reader takes "not as root" to mean rootless mode. It meant the opposite: the user had a standing, passwordless path to root.

The membership landed on June 1, 2025, was disabled a day later, then re-enabled on June 17, 2025, and was finally removed from the default configuration on August 24, 2026. Everything before 4.0.1 is affected, including the 3.8.4 ISO the researcher tested. The issue was reported through the project's responsible-disclosure process and patched before the writeup went public.

If you run Omarchy, update to 4.0.1. If you spent time on an affected version with a browser, an editor, or an agent that pulls arbitrary code, treat the machine as having carried a root-equivalent exposure for the whole period, and rotate anything that lived on it: SSH keys, cloud credentials, tokens in dotfiles. Developer machines are a worthwhile target precisely because they hoard that access, and a distro aimed at developers is the wrong place to disable a guardrail silently.

For containers without the standing root grant, Podman is the straightforward swap. It is daemonless, so there is no root-owned socket to join a group for; containers run as ordinary child processes in their own user namespaces and need no root access. The researcher reports running it as a complete replacement for their Docker workflows for months.