CVE-2026-108913 in Omarchy
Summary
by MITRE • 10/11/2026
omarchy-theme-set in Omarchy 4 before 4.0.1 allows code execution via a third-party theme because the files placed into ~/.local/state/omarchy/current/theme may include executable content from an untrusted Git repository.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified within the Omarchy window manager configuration system, specifically affecting versions prior to 4.0.1, stems from an insecure handling of third-party theme assets during installation or activation processes. The core technical flaw lies in the application's failure to sanitize executable content embedded within theme files before they are placed into the ~/.local/state/omarchy/current/theme directory. This directory is typically monitored by the window manager for configuration updates and resource loading, meaning that any file deposited there with execute permissions can be directly invoked by the system or user session without further validation.
When a user selects or installs a theme sourced from an untrusted Git repository, the installation script or mechanism copies these files into the designated state directory. Because the software does not distinguish between static configuration data and executable scripts, it inadvertently grants execution rights to potentially malicious code contained within the theme package. This represents a classic case of insecure default permissions combined with insufficient input validation regarding file types and origins. An attacker who controls or compromises an untrusted third-party theme repository can embed shell scripts, binaries, or other executable payloads disguised as standard theme assets such as images, CSS files, or configuration snippets that are processed by the window manager's parsing logic.
The operational impact of this vulnerability is severe, resulting in arbitrary code execution with the privileges of the user account running the Omarchy session. Since desktop environments and window managers often operate with full access to the user's file system, environment variables, and network interfaces, successful exploitation allows an attacker to establish persistence, exfiltrate sensitive data such as SSH keys or browser cookies, install additional malware, or pivot further into the local network if the compromised host is connected. The risk is amplified by the social engineering aspect inherent in theme selection, where users may trust visually appealing themes without verifying their source integrity, assuming that visual customization tools are inherently safe from code execution risks.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and CWE-732 Incorrect Permission Assignment for Critical Resource, as the system fails to restrict permissions on files placed in a critical state directory. In terms of attack vectors, it maps to ATT&CK technique T1059 Command and Scripting Interpreter, where an adversary uses scripts or commands found within the theme package to execute actions on the target system. The lack of sandboxing for third-party assets means that the window manager effectively becomes a vector for delivering malicious payloads under the guise of aesthetic customization.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Users should immediately upgrade Omarchy to version 4.0.1 or later, where this issue has been addressed through stricter validation mechanisms. Until an update is available, users should avoid installing themes from unverified sources and manually inspect any theme files before activation, ensuring that no executable scripts are present in the ~/.local/state/omarchy/current/theme directory. System administrators can enforce security policies by restricting write permissions to this specific state directory for non-root users or implementing mandatory access control rules such as SELinux or AppArmor profiles that prevent execution of binaries from user-writable directories unless explicitly whitelisted. Future development should prioritize a secure-by-design approach where third-party assets are processed in isolated environments, and only verified static resources are allowed to influence the window manager's runtime configuration.