Haptics Havoc: An Omarchy LPE

By piratemoo • Sep 25, 2026 • 6 min read

  Distribution:   Omarchy 4.04
  Package:        dell-xps-touchpad-haptics
  Version:        1.0.0-3
  Severity:       High 
  Vulnerability:  Arbitrary file ownership change via symlink
  Weaknesses:     CWE-59, CWE-367

This post is extremely personal because of the circumstances revolving this particular vulnerability discovery. There are plenty of bug hunters, but security fields are like the brain's cortical folds, where rich mechanical forces are always at play, so it's not uncommon for people to pick a lane of focus to avoid exhaustion. When I want to process strong emotions however, traversing different regions is always comforting.

This will divert from regular content, because it's the first time I pushed myself into the discovery and reporting phases of my own local privilege escalation (LPE), which was accomplished for a very special person (my mother) who is no longer here to see it.

Parents and Promises

Before my father passed away from COVID a few years back, he made a request that I win one of the Capture the Flag (CTF) competitions I loved so much. He wanted to see me work on things I was passionate about because he believed in me. In the past and as a young girl, my hobbies were often viewed in a negative light, because they were considered unusual. His request stuck with me however, and I threw myself into the spirit of competition, eventually captaining my own team and engaging in anything else that challenged me.

Before all of of this, I was homeless for a time and that very same drive helped me obtain my first networking degree to do better for my family. I hoped it would eventually lead to a rewarding career and I was right.

People always see success, but they don't always see the countless hours grinding, learning, struggling and failures before it.

Eventually, I obtained the degree, worked myself out of homelessness, started placing well in CTF's and rooted machines on Hack the Box instead of crying over the fact that I couldn't. I started becoming the person my father believed in so much and while he didn't get to see all results, he became an inspiration I carry with me daily.

If you are embarking in that process, I want to tell you to keep going and to trust in your decisions and dreams. To push for what you want in life and to not give up on your goals, even if life keeps them from happening temporarily.

On September 12, 2026, my mother also passed away. Dealing with another parental loss brought me back to this place I never wanted to be again, but I wanted to honor my mother in a similar fashion by accomplishing something new.

In this case, it meant taking what I learned and applying it differently. The difference? This would be something I found, understood and disclosed, perhaps orchestrated by standing beneath the shoulders of many giants before me. With that said: Let's get to it.

Touchpad to root

Omarchy is a relatively new Arch-based Linux distribution created by David Heinemeier Hansson (DHH), who was also the creator or Ruby on Rails. It had been making headlines across social media with a lot of negative attention stemming from DHH's controversial views. The actual distribution however, turned out to be a great learning space because there is a ton to explore, which eventually led to asking:

What happens when a privileged process trusts something an unprivileged user controls?

When examining package installations, I found an issue in the dell-xps-touchpad-haptics installation script, unrelated to Dell's hardware or haptic functionality, but Omarchy's script handling of the configuration paths executing as root.

A Little About ALPM

As an Arch derivative, Omarchy uses the Arch Linux Package Management (ALPM) framework, which handles software installation/upgrades and removal through tools like pacman. It allows support for additional tasks like configuration file creation, file ownership/permissions adjustments and service handling.

In this case, there was a hook that executed as root during installation/upgrades and as a part of the configuration, it accessed a file in the user's home directory adjusting ownership. The script identifies the user, locates their home and ensures haptic configuration exists in ~/.config/omarchy/dell-haptic.conf

That looks reasonable at first, but the script used root to manipulate files in the directory of a basic user in an untrusted location (home). That means the user can create/remove/replace files and introduce symbolic links.

A symbolic link (symlink) is a file that points to another file/directory. Instead of having the actual contents, it stores the pathname and the OS locates it. For example, a command like ln -s /etc/passwd ~/moo.conf would create a symlink for moo.conf pointing to /etc/passwd and when a program accesses moo.conf the symlink is followed and handles the operation on /etc/passwd instead. This behavior becomes especially important when a script executes with elevated privileges.

The Attack

The script used OMARCHY_HAPTIC_USER to id which user config to manage, so I set that to researcher. The _ensure_user_config() function used home to locate the haptic config.

# Receives selected user/home directory and builds path to haptic config file 

local user=$1
local home=$2
local config_dir="$home/.config/omarchy"
local config_path="$config_dir/dell-haptic.conf"

# If config file doesn't exist, try to make it
# If config file does exist change ownership of directories

if [[ ! -f $config_path ]] && ! env HOME="$home" USER="$user" LOGNAME="$user" \
  /usr/bin/dell-xps-touchpad-haptics set "$_default_level"; then
  echo ":: Failed to create ${config_path} for user '$user'." >&2
  return 1
fi

if [[ -f $config_path ]]; then
  chown "$user:$user" "$home/.config" 2>/dev/null || true
  chown "$user:$user" "$config_dir" 2>/dev/null || true

# chown follows symlinks, allows file ownership change while running as root

  chown "$user:$user" "$config_path" 2>/dev/null || true
fi

What if the file was actually a symlink pointing to /etc/passwd?

Since chown follows symlinks the script treated /etc/passwd as the config file and changed ownership making it go from root:root to researcher:researcher. This allowed researcher to introduce a uid 0 account and grab root.

I privately reported the finding to Omarchy and wanted to give credit where due. I've certainly had my disagreements with things DHH has expressed and I haven't been shy about expressing that.

However, they responded within four hours, acknowledged the finding and linked attribution in the GitHub, although this never made the credits page. The maintainers took a better look and identified other issues as a result. The poc is available below:

In closing, you don't really need a super complex exploit to find something impactful. In this case, it was an assumption that a path in a user's home was safe for a privileged process.

With that said, this week connected two different chapters in my life. My father's spirit of competition combined with my mother's love of artistry and discovery. They were things my parents wanted to encourage and I'm finding that is still happening, even if they can't be here to see that.