Back to Home

AUR packages compromised with Infostealer and Rootkit

Article URL: https://discourse.ifin.network/t/400-aur-packages-compromised-with-infostealer-and-rootkit/577 Comments URL: https://news.ycombinator.com/item?id=48500447 Points: 240 # Comments: 172

t
tech4you AI
June 13, 20262 min read
Share

Last Updated: 2026-06-12T19:14:16Z

What’s Happening

It appears a new AUR package maintainer impersonating a trusted maintainer adopted and infected 408+ packages. The compromise was reported and other AUR maintainers have been working to remove the infected packages.

As of 2026-06-12T17:30:00Z, the AUR maintainers believe they have removed all malicious commits.

They have also decided to implement some controls and limitations on functionality, including adopting packages.

The attack included at least two separate malicious dependencies.

The initial affected packages were modified with preinstall scripts to use npm to install the atomic-lockfile package, a malicious payload.

Here’s an example of the change:

Further infections used Bun to install the malicious js-digest. NPM has removed that package.

This blog has a deep dive into the attack.

Actions

If you don’t use Arch (btw), you’re fine.

  1. Arch users: review the list of affected packages and use this script to check your exposure: aur_check.sh (OUTDATED, check https://gist.github.com/Kidev/85756c3dcad3623ca5604a8135bafd14) · GitHub
  2. Review the Ioctl blog for the indicators of compromise and if found, preserve the system for forensic investigation as appropriate.
  3. If packages are found, follow normal compromise procedures. Rotate all credentials and consider reinstalling Arch. The possibility of a rootkit removes the possibility of system trust.

Also, just for good measure (and this is for everyone), deny outbound Tor traffic from your network.

Indicators of Compromise

In addition to the linked IOCs, this is the SHA256 of the malicious Linux executable embedded in js-digest.

7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316

You can also hunt for suspicious eBPF Maps using bpftool map list. Suspicious map names include:

  • hidden_pids
  • hidden_names
  • hidden_inodes

Notes

An earlier version of this report stated that a known maintainer account was responsible for the malicious commits. That was inaccurate; the known maintainer account was spoofed.

Most of these packages are rare, but the scope is significant. Also, it’s rare to see a supply chain attack of this nature go so far as an eBPF rootkit in addition to infostealer behavior.

Socket.dev has the malicious NPM package. It shows 134 downloads.

https://socket.dev/npm/package/atomic-lockfile

The NPM package is maintained by user herbsobering. Searching that username on GitHub reveals a single container image that appears to be a reverse shell/proxy tool. Package herbsobering430 · GitHub

You might be wondering how this happened. The truth is, the AUR package repository allows anyone to “adopt” a package and submit a change to the PKGBUILD/associated files if the package is marked as unmaintained. It turns out automating the hunt for abandoned packages and adoption of them is not uncommon. See this Mastodon thread for additional context.


Originally published on Hacker News (Best)

Related Articles