Omarchy: Critical Privilege Escalation Vulnerability

Date: 2026-08-28
Subject: Any user-level process can escalate to root privileges.

A significant security flaw was discovered in the default Docker configuration of Omarchy. This vulnerability allowed virtually any application running within a user's desktop session to gain root access without requiring a password, sudo permissions, or any form of authorization prompt.

[!IMPORTANT] If you are currently using Omarchy, the immediate solution is: Update to version 4.0.1.

I followed the project's responsible-disclosure protocol to report this privately. Now that the configuration has been patched, I am sharing the technical details to educate users and ensure everyone updates their systems.

---

🛠️ The Technical Breakdown

The vulnerability stemmed from Omarchy adding the default user to the Linux docker group by default.

On Arch-based systems, the Docker daemon operates as the root user and monitors the following socket: /var/run/docker.sock. Any user belonging to the docker group is permitted to communicate with this socket. As Docker explicitly warns in its own documentation, membership in the docker group is functionally equivalent to having root privileges.

The Attack Vector

A process with access to the Docker socket can instruct the root-owned daemon to:

1. Start a container with root privileges.
2. Mount the host's entire filesystem into that container.
3. Modify or read any file on the host as the root user.

Mathematically, the privilege level $P$ of a process in the user session became: $P_{user} \xrightarrow{\text{docker.sock}} P_{root}$

Proof of Concept (PoC)

On a vulnerable Omarchy installation, a standard user cannot normally read the shadow file:

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

However, checking group memberships reveals the docker group: $ id $\rightarrow$ uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)

By leveraging Docker, the user can bypass these restrictions:

# Run a container, mount the host root to /hostroot, and read the shadow file
$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...

In this scenario, while the docker command is issued by a non-privileged user, the actual file access is executed by the root-level daemon.

---

🌐 Scope of Impact

Because Linux supplementary groups are inherited by child processes, this vulnerability extends to the entire user session. By analyzing the process tree beneath the systemd --user instance, it was confirmed that the Docker group was present in almost every active process.

High-Risk Applications

Any application capable of running untrusted code could potentially seize root control, including:

• AI Coding Agents and their respective harnesses.
• Web Browsers (via exploits).
• IDEs and text editors.
• npm scripts or other package manager hooks.
• Various background development utilities.

Essentially, a compromise of a single user-space application results in a partial full machine compromise.

Escalation Flow

---

⚠️ Security Defaults & Documentation

This issue highlights a critical failure in security defaults. The decision to trade security for convenience was made on behalf of the user, applied to the default account, and never explicitly disclosed. Most users assume that an OS is secure by default and will be prompted before opting into risky configurations.

Misleading Guidance

The Omarchy documentation regarding development tools was particularly confusing:

"Omarchy installs everything needed to run [docker] well. This includes [ ] the user group changes needed for you to run Docker as the normal user and not as root."

A reader might interpret "not as root" to mean that Omarchy utilizes a rootless Docker configuration. In reality, the implication was the exact opposite.

---

📅 Timeline of Events

---

🧠 The Broader Context

As AI-generated code increases the frequency of high-severity CVEs, security must be a priority—especially for distributions aimed at developers. Developer machines are "high-value targets" because:

1. They often have broad access to production systems.
2. Security guardrails are frequently disabled for convenience.
3. Credentials are often stored in plain-text .dotfiles.

While this was likely an oversight by DHH regarding the implications of the docker group, it is a concerning lapse. I was impressed by the speed of the fix, which is a positive sign. However, this isn't the first security issue I've encountered with Omarchy, and I currently lack confidence in their security decision-making process.

---

🚀 Recommendation: Podman

If you need to run containers on Linux without granting root privileges (even via sudo), I strongly suggest Podman.

• Rootless by Design: Containers run as child processes in their own user namespaces.
• No Daemon: No root-owned socket to exploit.
• Compatibility: It has completely replaced my Docker workflow.

Final Checklist

• Update Omarchy to 4.0.1.
• Audit current group memberships (id command).
• Consider migrating from Docker to Podman.

References:

• Docker: Manage Docker as a non-root user
• Omarchy Docker documentation