Omarchy flaw allowed any user process to become root without a password

A flaw in the default configuration of Omarchy, the Arch-based Linux distribution created by David Heinemeier Hansson (DHH), allowed practically any process running in the user's session to escalate to root without a password, without sudo, and without any privilege prompt. The issue was reported privately, has already been fixed, and the guidance for anyone using the system is direct: update to version 4.0.1.

What caused the problem

Omarchy configured the default user as a member of Linux's docker group. This allows running commands like docker run ... without typing sudo, which sounds convenient, but carries a security implication that Docker's own documentation explicitly warns about: belonging to the docker group is equivalent to granting the user root privileges.

On Arch, the Docker daemon runs as root and listens on the /var/run/docker.sock socket. Members of the docker group can communicate with that socket, and a process with access to it can ask the daemon (which is root) to spin up a container as root, mount arbitrary parts of the host's filesystem inside it, and operate on those files with full privilege.

The proof of concept published by the researcher shows the mechanics in a didactic way. On an affected installation, reading a protected file fails:

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

But the same user appears in the docker group (id 967 in the example):

$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)

And then the file falls without resistance, using Docker as a root intermediary:

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

The command is launched by an ordinary user process, but the actual filesystem access happens through a daemon running as root.

Why this affects the entire session

The detail that turns a theoretical risk into an immediate problem: supplementary groups in Linux are inherited by child processes. When inspecting the process tree under the systemd --user instance, the docker group showed up in practically every normal process in the session.

In practice, almost every place where untrusted code can run gains a path to root, including:

• AI coding agents and their harnesses
• web browsers
• editors and IDEs
• npm scripts
• various development tools
• background processes

In other words: the compromise of a common user application would become total compromise of the machine. For anyone running third-party packages, executing arbitrary build scripts, or letting AI agents operate with autonomy, this is exactly the attack surface that is growing the most.

The point about insecure defaults

The researcher points out that the configuration was opt-out, not opt-in. The user didn't even need to use Docker to carry the risk: the security tradeoff was already applied to the default account, without being explained. Worse, Omarchy's development tools documentation mentioned that it installed "the user group changes needed for you to run Docker as a normal user rather than as root," a phrase from which a reader would reasonably conclude that Docker was configured in rootless mode. It wasn't.

The flaw affects versions prior to 4.0.1, and was also confirmed in the latest ISO of the 3.x series (3.8.4). The docker group was introduced into the default on June 1, 2025, and removed on August 24, 2026.

The community's reaction

The Hacker News thread concentrated on two lines of discussion. The first, nearly unanimous, is that daemon-based Docker shouldn't be in the default of a developer distro in 2026. In the thread, antiloper was direct: "Installing docker by default is completely insane. What are they doing? Rootless podman has been around for many years at this point."

The report's own author recommends Podman as an alternative: being daemonless, containers run as normal child processes in their own user namespaces and don't require root access.

There were also those who downplayed the impact on a single-user desktop. qweqwe14 argued that access to the home directory is already extremely severe on its own and that there are countless other paths to root, and exitb weighed in: "It's not great, but I'm not sure this should be framed as Omarchy-specific, when it's a very common setup to add regular user to the docker group."

A comment sums up why this kind of misconfiguration is no longer academic in the era of agents:

Lol. This misconfiguration is so common and so trivial that LLMs have been known to exploit it unprompted, to complete their task.

>

-- Retr0id

What to do

For anyone using Omarchy, the mandatory step is to update to 4.0.1. But the warning applies to any Linux development machine, not just this particular distro: if your user is in the docker group, check with id. If it is, and you don't want that tradeoff, evaluating a migration to rootless Podman is the path pointed to by both the researcher and the community.

The reporter credits the project's quick response as a healthy sign and attributes the decision to an oversight, but notes discomfort with Omarchy's security decision-making process. It remains an open question how much developer-focused distributions will review their defaults at a time when the dev machine is a high-value target, with credentials in dotfiles and guardrails turned off for convenience.