Your browser tab runs as root on Omarchy

In Omarchy, any user process can escalate to root. That is the finding in full. It does not depend on a bespoke exploit chain, a stolen administrator credential, or a narrow race condition. A process running as an ordinary user reaches root authority. Every security assumption that rests on the unprivileged user being unprivileged is void.

The line between a user account and root is the primary security boundary on a Linux system. It separates the code a person runs through the day from the code that owns the machine. Omarchy does not hold that line. This is not a weak or partially effective control. It is the absence of an enforced one. When the boundary that defines the entire trust model does not constrain execution, there is no residual protection to fall back on.

The operating position that follows is simple. Treat every user-level process on the affected system as a root-level process. Any code that reaches user execution reaches root. That includes code the user chose to run and code the user never chose to run. The exposure is bounded only by whatever can execute as the user, which on a normal workstation is a wide surface: browsers, package tooling, editors, scripts, downloaded binaries, and anything delivered through a compromised dependency. Not confirmed: which Omarchy versions or configurations exhibit this condition. Confirmed: where a user process runs, root is reachable.

What is externally observable is direct. Code executing under a standard user account obtains root authority, and the system does not stop the transition. A process that starts unprivileged ends privileged. There is no additional constraint visible between those two states that holds against a user process. The outcome is the fact. The system behaves as if the user and root contexts are the same authority.

The path that grants that authority is not confirmed by the facts provided. Whether escalation is enabled by a setuid binary, a privileged helper, an IPC endpoint, a service running as root, or a configuration default is not stated, and I will not assign a cause without evidence. Naming a specific mechanism here would be invention. What is stated, and what is sufficient to act on, is the result: the user-to-root boundary does not hold for any user process. The mechanism can be identified later. The exposure is already defined.

The phrase that carries the weight is any user process. Any means the escalation is not gated by an effective control. If enforcement existed and worked, escalation would be conditional. It would depend on a specific binary, a specific privilege, a specific missing patch. Universal escalation is the observable signature of an unenforced boundary. State it plainly. The control that is supposed to separate user context from root context is ineffective, because a control that does not stop the behaviour is not a control. It is a label on a boundary that is not there.

On Linux, privilege separation is meant to be enforced by the kernel and by the disciplined configuration of whatever runs with elevated rights. The stated condition is that this separation does not constrain a user process on Omarchy. Identity is supposed to be the boundary. The identity of the running account is supposed to determine what that account can reach. Here it does not. The account is user. The reachable authority is root. The identity no longer limits the execution context, which means identity is no longer functioning as a boundary at all.

From a red team position, this collapses the part of an intrusion that normally costs the most. The standard sequence is initial access as a user, then a hunt for a local privilege escalation, then root. That middle step is where a large share of intrusions stall, because a hardened system forces the attacker to find and burn a specific weakness to cross it. Omarchy removes the step. The foothold is the objective. Any initial access that lands as a user lands as root by extension. Not confirmed: whether a specific trigger or interaction is required to invoke the escalation. The stated fact is unconditional across user processes, so the working assumption is that no such gate exists.

The decisive point is that this condition is a property of the system, not of the attacker. It does not require skill, a zero-day, or a chained exploit. The attacker’s capability set is irrelevant to whether the boundary holds, because the boundary does not hold on its own terms. You are not defending against a technique. You are operating a system that grants root to whatever reaches user execution. If a system allows it, it will happen. The question is not whether a process will take root. The question is which process takes it first. Not confirmed: whether any logging or telemetry records the user-to-root transition. Because no such visibility is stated, detection of the escalation cannot be assumed.

Root on a workstation is not a higher tier of user access. It is total control of the machine. A process that holds root can read and write any file on the host, read the memory of any other process, load kernel modules, and alter the system’s own boot and service configuration. This follows by necessity from the stated condition. If any user process reaches root, then any user process reaches all of it. The escalation is not the payload. It is the key that opens every remaining lock on that host at once.

What is observable is the removal of every on-host isolation boundary that depends on privilege. Separation between local accounts depends on the kernel enforcing uid ownership. Protection of root-owned configuration depends on the same enforcement. When a user process obtains root, those separations no longer describe a boundary, because the process can assume the identity that owns them. The host stops being a system with a privileged core and an unprivileged periphery. It becomes a flat authority where the periphery can act as the core.

Two consequences are logically necessary, and both matter to an attacker more than the escalation itself. First, root authority permits modification of the system’s own startup and service definitions, which places the mechanisms of persistence within reach of any user process. Whether persistence is established is an attacker action and is not confirmed by the condition, but the capability is not constrained. Second, any credential material reachable in a root context on that host is exposed to a user process. SSH keys, cached tokens, agent sockets, and stored secrets that a hardened system keeps behind privilege are no longer behind anything. The specific credentials present on a given host are not confirmed and depend on the host. The rule is not the inventory. The rule is that whatever is there is reachable.

Lateral movement is the direct extension of that second consequence. In a red team operation, a root-controlled endpoint is not the objective. It is the harvesting point. The value is the credential and trust material the endpoint holds toward other systems, and root is the access level that collects it without obstruction. Omarchy does not create the credentials or the trust relationships. It removes the privilege boundary that would otherwise force an attacker to earn root before touching them. The reachability of other systems is not confirmed and is a property of the network the host sits in. What is confirmed is that this host contributes no privilege barrier to slow the collection.

The pattern is not specific to any one file, service, or account. It is the failure of every control built on the assumption that a user process is not a root process. That assumption is load bearing across a Linux system’s design. File permissions express it. Service accounts that run daemons as unprivileged users express it. Sudo policy, which decides which users may deliberately cross into root, is written entirely on top of it. When the assumption is void, each of these inherits the void. A permission model the kernel will not enforce against a user process is descriptive text. A daemon dropped to an unprivileged account for containment is contained by nothing if that account’s processes can reach root.

This is why the finding cannot be handled as a single vulnerability to be patched around with compensating controls at the same layer. Compensating controls on the host mostly assume the same boundary. Restricting what a user may run assumes the user’s context is meaningfully less than root. Auditing user actions separately from root actions assumes the two are distinct authorities. Both assumptions are the one that failed. You cannot compensate for the loss of a boundary using controls that are defined by that boundary.

For an attacker, the pattern rewrites the cost of the operation. The expensive phase of most intrusions is local privilege escalation, because a hardened host forces the attacker to find and spend a specific weakness to cross from user to root. That phase is where noise is generated, where exploits fail against patched systems, and where many campaigns stall. On this system the phase does not exist. Cost collapses to initial access alone. Because the condition is a property of the system rather than a technique, it is uniform across every affected host. Automation that lands a user process lands root at the same scale. The boundary that normally has to be defeated per host, sometimes per attempt, is not defeated. It is absent everywhere the system is deployed. Not confirmed: which versions or configurations are affected. Where the condition is present, it is present identically.

Operate the affected host as a single-authority machine. Every user process is a root process for the purposes of risk. There is no partial trust to assign to user-level code, no tier of access that is safe to grant, no unprivileged sandbox on the host that holds. This is not a posture of caution. It is the accurate description of the system’s behaviour, and planning against a more favourable description is planning against a system you are not running.

Two things must be true for this host to sit in an environment safely. First, the controls you rely on cannot live on the host itself. Network segmentation, credential isolation that keeps reusable secrets off the endpoint, and enforcement points that sit outside the machine are the only controls positioned to matter, because they do not depend on the boundary that failed. Second, initial access has to be treated as the whole game. Since nothing on the host stands between a user process and root, everything that prevents hostile code from reaching user execution carries the entire defensive weight. Browser exposure, package and dependency intake, and anything that executes downloaded content are no longer early stages of a possible compromise. They are the compromise.

The remediation is not a hardening checklist. A boundary the system does not enforce cannot be re-enforced by settings that assume it exists. Until the user-to-root condition is corrected in the system itself, the affected host does not provide privilege separation, and it should not be placed anywhere that privilege separation is part of your control set. That includes multi-user machines, shared workstations, and any host holding credentials that reach other systems. Identity is supposed to be the boundary. On this system it is a label. Do not build on a boundary that is not there.