Contents
- What actually happened
- Before you start
- Step 1 — Check your Omarchy version
- Step 2 — Check docker group membership and socket access
- Step 3 — Update, or pull yourself out of the group right now
- Where this trips people up
- If you want more than the default fix
- FAQ
Every new Omarchy install used to add the default user straight into the docker group. Omarchy is David Heinemeier Hansson’s Arch Linux and Hyprland desktop distro, and that group is root-equivalent: any process that can reach the Docker socket can spin up a container, mount your entire filesystem into it, and read or write anything as root. No sudo prompt, no password. The fix landed in version 4.0.1 on August 25, 2026; if you’re on anything older, including the 3.8.4 ISO, you’re exposed.
Most of the coverage on this either explains the bug or lists the fix — rarely both in one place you can run top to bottom. That’s what this is.
What we checked ourselves
The figures below were not taken from other articles. We checked them ourselves on 2026-09-14 21:40 KST.
Having checked the omarchy repository’s commit history directly, the period during which the default install granted the docker group (effectively equivalent to root) totalled 433 days (about 14 months and 7 days) — from its initial introduction on 2025-06-01, disabled a day later on 06-02, reintroduced on 2025-06-17, and finally switched to opt-in on 2026-08-24.
Method: We called the GitHub REST API directly via curl to check the change history of the install/docker.sh file in the omacom/omarchy repository (`GET /repos/omacom/omarchy/commits?path=install/docker.sh`) and the actual diff of each commit (`GET /repos/omacom/omarchy/commits/{sha}`). This can be checked via the public API without authentication, and anyone can reproduce it using the commit hashes in the table below: `curl -s https://api.github.com/repos/omacom/omarchy/commits/<sha>`.
| Date (UTC) | Commit | Description | Actual diff summary |
|---|---|---|---|
| 2025-06-01T13:04:28Z | `25799ee9` | install/docker.sh created | Added `sudo usermod -aG docker ${USER}` (initial introduction) |
| 2025-06-02T08:26:04Z | `c5ee230d` | "Stop the logout that happens under arch from this" | Commented out the `usermod` line to disable it (not a security reason — because applying the group caused the session to log out as a side effect) |
| 2025-06-17T07:57:24Z | `fdd2aaf4` | "Try again adding user to docker group" | Uncommented the line to re-enable `usermod -aG docker`, which then became the fixed default |
| 2026-08-24T16:56:00Z | `b5ded31e` (PR #8056) | "Don't put the user in the docker group; make it opt-in" | Removed the default grant, switched to opt-in via `omarchy-setup-security-sudoless-docker` |
| 2026-08-25T11:24:30Z | Release tag `v4.0.1` (author dhh) | Release notes specify this commit | Shipped in this release |
Caveat: this period covers when a 'default fresh install' automatically granted the group. The one-day initial introduction from 2025-06-01 to 06-02 was very brief, so its real-world impact was likely minimal, and the 06-17 to 08-24 window is effectively where the real exposure lies. Also, for existing users who had already been installed and enrolled in the docker group, the automatic migration script is supposed to remove the group upon updating to v4.0.1 (as stated in the commit message), but we did not separately verify whether the migration actually worked correctly across all existing installs.
Actual behaviour as of the current source following v4.0.1: the default install no longer grants the docker group at all, and the exact command a reader can use to check whether their own machine is vulnerable is `id -nG "$USER" | grep -qw docker`.
Method: We viewed the actual source files on the quattro branch directly via GitHub raw content: `install/config/docker.sh` (the current default install script, with no usermod call), `bin/omarchy-sudo-docker` (the official detection logic, which checks group membership via `id -nG "$USER" | grep -qw docker`), and `bin/omarchy-setup-security-sudoless-docker` (to check the original wording of the warning shown on opt-in).
Verified original-text quotes: – Comment in the current default install script (`install/config/docker.sh`): "We therefore do NOT add the install user to the docker group by default, so a single rogue process running as the user cannot silently escalate to root." – Official detection command (`bin/omarchy-sudo-docker`): `id -nG "$USER" 2>/dev/null | grep -qw docker && exit 1` — in other words, if a reader runs `id -nG "$USER" | grep -qw docker && echo "vulnerable (belongs to the docker group, equivalent to root)" || echo "safe"` in their terminal, they can immediately check whether their own device is still in the older, exposed state. – Warning text shown on opt-in (`bin/omarchy-setup-security-sudoless-docker`): "The Docker daemon runs as root, so membership in the docker group is equivalent to passwordless root… docker run -v /:/host alpine # full read/write of the host, as root"
Caveat: this check is based on the current snapshot of the quattro branch, and we did not log into an actual physical or virtual Omarchy machine to run the commands ourselves — we verified this only by directly reading the logic in the source code. If the branch name or file paths change in future, the raw URLs may also change.
What actually happened
The root cause is simple, which is part of why it’s embarrassing. Omarchy added the default user to the docker group by default. Docker’s own documentation says outright that docker group membership is root-equivalent — this isn’t news to anyone who’s run Docker for a while. It’s a known footgun. What was new was Omarchy handing it to every user by default, without asking.
The daemon behind Docker, dockerd, runs as root. Anything that can talk to /var/run/docker.sock can tell that daemon to do root things on its behalf. The proof-of-concept making the rounds is one line:
docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadowRun that as a regular user on a vulnerable box and it prints the contents of /etc/shadow — a file that’s supposed to require root to read. Nothing more exotic than that.
The part that got people’s attention is the blast radius. On a normal desktop session, plenty of things run as your regular user: AI coding agents, browsers, editors, npm scripts, random background tools. Any one of those, if compromised, could pivot straight to full machine takeover through the docker group. You didn’t need a kernel exploit. You needed one already-running process with bad intentions or a bad supply chain.
Before you start
You’ll need terminal access and a few minutes. Nothing here requires a live boot or a backup, but check the basics first:
– A terminal, logged in as the account you normally use day to day – Know roughly which Omarchy version you installed (or don’t — the commands below will tell you) – If you plan to remove yourself from the
dockergroup manually, know that you’ll need to log out and back in (or reboot) for it to take effect
Step 1 — Check your Omarchy version
Omarchy ships a command called omarchy-version for checking what you’re running. Run it and compare the number against 4.0.1:
omarchy-versionAnything below 4.0.1 is vulnerable. That includes 4.0.0, released August 14, 2026 — its release notes mention Docker multi-arch builds being enabled by default but say nothing about group permissions, so the docker-group issue was already present. It also includes the 3.8.4 ISO and everything in the 3.x line.
| Version | Vulnerable? | What to do |
|---|---|---|
| 3.8.4 ISO / 3.x | Yes | Update to 4.0.1 or later |
| 4.0.0 | Yes | Update to 4.0.1 or later |
| 4.0.1 | No | Nothing — already patched |
| 4.0.1+ | No | Keep updating normally |
Step 2 — Check docker group membership and socket access
This is the actual vulnerability check, and it’s two commands.
First, see if your account is in the docker group:
groups $USERor equivalently:
id -nG $USERIf docker shows up anywhere in that output, your account has root-equivalent access to the Docker daemon right now.
Second, confirm the socket itself is set up the way that makes this exploitable:
ls -l /var/run/docker.sockThe socket is group-owned by docker, so group membership alone is enough to reach it — no extra permissions needed.
If you want to actually confirm impact rather than just membership, the proof-of-concept from Step 1 works as a test too. On an unpatched, still-vulnerable system, it succeeds and dumps /etc/shadow. On a fixed system, it should fail with a permission error. I’d only run this as a deliberate test, not as a first move — it’s doing exactly what the bug allows.
Step 3 — Update, or pull yourself out of the group right now
Two paths here, and they’re not mutually exclusive.
The real fix is the update. Version 4.0.1 changes docker group membership from automatic to opt-in — passwordless daemon access has to be turned on deliberately now, instead of arriving by default. Update through the Omarchy menu (Super+Space → Update → Omarchy) or from a terminal with omarchy update. The 4.0.1 ISO, if you’re doing a fresh install instead, is omarchy-4.0.1.iso, and the published SHA256 checksum is 69cbb4e10d98ad831c3c9f245b5757a9d1fedfd0c9592780e977d6f950dea8c3 — worth checking against your download.
If you can’t update immediately, pull your account out of the group directly:
gpasswd --delete <username> dockerVesto’s write-up used gpasswd --delete steve docker as its example — swap in your own username. This is the same fix the update applies, just done by hand and immediately, without waiting on the updater.
Either way, log out and back in (or reboot) — Linux doesn’t apply group membership changes to a session that’s already running, and that’s normal behavior, not specific to this bug. Then verify:
id -nG $USERdocker should no longer appear. If you want extra confidence, re-run the PoC container command from Step 1 — it should now fail with a permission error on the socket instead of succeeding.
Worth knowing: version 4.0.1 wasn’t just this one fix. Basecamp bundled a batch of unrelated security changes into the same release — tighter defaults for the same setup and Codex approval modes, a classifier that reviews agent actions before running them, sandboxing for theme code pulled from git repos, safer notification-click handling, sanitized USB device names, a fixed FIDO2 temp-file path, and stricter git transport helper URLs. If you’re updating for the docker fix, you’re getting all of that in the same pass.
Where this trips people up
A few things worth flagging before you assume you’re done.
If you removed yourself from the docker group by hand but skipped the logout, groups $USER can still show the old membership in that terminal session — the change is real, it just hasn’t taken effect where you’re checking it. Log out fully and recheck.
If you use Docker regularly and rely on running it without sudo, removing yourself from the group breaks that convenience. That’s the tradeoff — root-equivalent access was the convenience in the first place. You’ll need sudo docker ... going forward, or one of the alternatives below.
And updating doesn’t retroactively fix a session that’s already compromised. If something already ran as root on your machine through this hole before you patched, the patch closes the door going forward — it doesn’t undo anything that already happened. Checking whether that already happened to you is a separate, harder question, and outside what this piece covers.
One more gap: nobody’s named as the researcher who found this. It’s described only as responsible disclosure.
If you want more than the default fix
Removing yourself from the docker group and letting the 4.0.1 update handle the rest solves the immediate problem. But the underlying pattern — a root-owned daemon that anything can talk to — is still there for whoever’s in the group deliberately, like people who actually use Docker day to day.
The alternative raised in Omarchy’s own GitHub Discussions (#3085) is switching to genuinely rootless Docker, or moving to Podman instead. Podman is daemonless and uses user namespaces rather than a root-owned background process, so there’s no equivalent socket to escalate through. That thread picked up decent support — eight-plus reactions — but it’s still a community suggestion, not something Omarchy ships as a default. If you want it, you’re setting it up yourself.
My honest take: rootless Docker or Podman is the better long-term answer for anyone who actually needs containers day to day, not just the group-removal patch. The group fix in 4.0.1 closes the accidental exposure. It doesn’t change the fact that Docker’s normal daemon model is root-equivalent by design for whoever opts in.
FAQ
Is there a CVE for this? None turned up in the sources for this piece. That doesn’t rule one out existing or being assigned later, but as of writing, this looks like an unnumbered fix — a distro configuration problem rather than a bug inside Docker itself.
Do I need to reinstall Omarchy to fix this? No. Running the update (omarchy update or through the menu) or manually removing your user from the docker group both work on an existing install. A fresh install with the 4.0.1 ISO is only necessary if you’re setting up a new machine anyway.
Does this affect every Omarchy version? Every version before 4.0.1, including 4.0.0 and the 3.8.4 ISO. Treat “everything pre-4.0.1” as the safe assumption rather than a fully itemized list — earlier versions aren’t confirmed one by one.
Is Docker itself broken? No — this is Omarchy’s default configuration, not a flaw in Docker. Docker’s documentation already states plainly that docker group membership is root-equivalent. The criticism, including from commenters on the Hacker News thread, was about Omarchy shipping that as a default without flagging it, not about Docker behaving unexpectedly.
What’s still open: exactly how long this default was live before anyone flagged it publicly. The write-ups only surfaced around August 30–31, roughly a week after the patch had already shipped on August 25. If you’re on an Omarchy box right now, the two commands in Step 2 tell you in about ten seconds whether any of this applies to you. Worth running them before reading anything else about it.
Image credits
- Photo by Rafael Minguet Delgado on Pexels