critical

CVE

Not assigned

CWE

CWE-494, CWE-506, CWE-522, CWE-829

Affected Surface

Approximately 1,500 to 1,619 Arch User Repository packages across the June 11-12 2026 Atomic Arch waves, Malicious npm packages atomic-lockfile 1.4.2 and lockfile-js 1.4.2, Malicious npm package js-digest 4.2.2 executed through Bun-based follow-on install paths, Arch Linux developer workstations and CI/build hosts using AUR packages through makepkg, yay, paru, or similar helpers

Atomic Arch is what a modern Linux package-repository compromise looks like when the attacker understands that most users trust package history more than package content. On 11 June 2026, researchers disclosed that abandoned Arch User Repository packages were being adopted by attacker-controlled accounts and then modified so that normal AUR install/update flows fetched malicious npm packages during build or post-install execution.

The trusted AUR projects were the lure, but the real payloads lived in package registries that AppSec teams already worry about: npm first, then Bun-assisted fetches of additional npm packages on the second day. That cross-ecosystem pivot matters. A Linux package review that checks only PKGBUILD diffs but not the registry artifacts they invoke will miss the actual malware stage.

What was affected

The official Arch notice confirmed a live AUR-wide incident and warned users to review PKGBUILD and install-script changes, but it did not publish a canonical package list. The count moved quickly:

  • Sonatype reported the campaign expanding toward roughly 1,500 AUR packages across multiple waves.
  • IFIN documented an early wave affecting 408+ packages.
  • The best-maintained public package inventory I could verify had reached 1,619 package names at review time.

That means defenders should treat the campaign as a repository-scale compromise, not as a handful of isolated package names.

Directly confirmed package names from the Arch mailing-list incident thread included:

Package familyConfirmed examples
Desktop and system packagesgnome-randr-rust, ledger-udev-bin, minitube, ktea, fastjet, lowfi-bin, gnutls3.8.9, autologin--
Python packagespython-apt, python-cerealizer, python-orange, python-affine, python-axolotl-git, python-django-modelcluster, python-django-rest-knox, python-future, python-tradingeconomics, python-nipype, python-rembg
Nextcloud packagesnextcloud-git, nextcloud-app-integration-google, nextcloud-app-repod, nextcloud-app-facerecognition, nextcloud-app-audioplayer, nextcloud-app-twofactor-gateway, nextcloud-app-gpoddersync
Other examples surfaced during cleanupvim-pythonhelper, flashfocus, efiboots-git, meteo, yy, sshuttlee-bin

The community-maintained tracker later expanded that inventory to more than 1,600 names and added second-wave examples such as guiscrcpy and keepassx2. For incident response, the important point is not whether your package is one of the highly publicized examples. It is whether any AUR package build on your host between 11 and 12 June traversed one of the malicious hook paths.

The execution chain

The first wave modified package install logic to pull a malicious npm dependency from within an otherwise ordinary AUR package flow. Sonatype’s reproduced pattern was:

npm install atomic-lockfile minimist chalk

The Arch incident thread captured a close variant in the gnome-randr-rust takeover:

npm install atomic-lockfile yargs

That is the key architectural trick in Atomic Arch. The AUR project itself does not need to contain the final malware. It only needs to add one registry fetch into .install, .hook, or related package logic. After that, the infection path becomes:

compromised AUR package
  -> makepkg / yay / paru executes modified package hook
  -> npm install atomic-lockfile ...    (wave 1)
     or Bun-assisted install of js-digest / lockfile-js    (wave 2)
  -> package manager reads malicious package.json lifecycle
  -> preinstall executes ./src/hooks/deps
  -> Linux ELF payload starts on the build host
  -> persistence, secret theft, optional eBPF hiding

The recovered atomic-lockfile package was especially deceptive because it still looked like a mostly legitimate TypeScript npm package. Independent reverse engineering described it this way:

{
  "name": "atomic-lockfile",
  "version": "1.4.2",
  "main": "./dist/cjs/index.cjs",
  "module": "./dist/esm/index.js",
  "scripts": {
    "preinstall": "./src/hooks/deps"
  }
}

That single lifecycle entry is enough to turn a Linux package install into native code execution on the consuming host.

The second wave proved the campaign was still evolving

This was not a one-package event. Sonatype updated its report on 12 June to note that the campaign had already added js-digest and lockfile-js, and that some follow-on infections used Bun-based install paths rather than npm alone.

Registry metadata backs up the speed of that churn:

js-digest
  created:    2026-06-12T10:21:34Z
  unpublished: 2026-06-12T11:53:23Z
  bad version: 4.2.2

lockfile-js
  created:    2026-06-12T13:01:03Z
  unpublished: 2026-06-12T16:29:49Z
  bad version: 1.4.2

That cadence is operationally important. It shows the attacker iterating within hours, not days, and it means static blocklists built around a single package name were already obsolete during the incident.

What deps actually did

The most useful reverse-engineering detail is that the real payload was not a JavaScript stealer. It was a Linux ELF binary named deps placed at src/hooks/deps and launched by the malicious package lifecycle. The recovered sample was:

file: deps
size: 3,040,376 bytes
type: ELF64 PIE
sha256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b

Static analysis and independent reporting describe deps as a credential stealer optimized for developer workstations and build hosts. Documented target material included:

  • GitHub credentials and repository access tokens
  • SSH keys and related artifacts
  • npm credentials
  • HashiCorp Vault tokens
  • browser cookie databases
  • Slack, Discord, Microsoft Teams, and Telegram session data
  • Docker and Podman credentials
  • shell histories, VPN material, and other local developer secrets

One reverse-engineering report also observed explicit API handling for OpenAI/ChatGPT account metadata. Even if your organization does not use Arch as a desktop standard, that should get AppSec teams’ attention: the malware was aimed at the same developer endpoints that increasingly hold registry, cloud, and AI-platform secrets.

Why the eBPF angle changes the response

Sonatype’s static analysis and independent malware reversing both found code paths consistent with optional eBPF-assisted hiding when the payload runs with enough privilege. The strings and APIs are not subtle:

scales.bpf.c
bpf_object__load
bpf_program__attach
bpf_map__pin
getdents64
NETLINK_SOCK_DIAG
PTRACE_ATTACH
PTRACE_SEIZE
hidden_pids
hidden_names
hidden_inodes

Those references imply more than generic Linux malware capability. They indicate a design specifically built to reduce analyst visibility:

  • hide selected processes from /proc listings
  • hide names or files from directory enumeration
  • hide socket inodes from /proc/net/* and socket diagnostic views
  • interfere with debugger attachment against hidden processes

That is why “remove the bad package and move on” is not a sufficient response if the payload executed as root or with the privileges needed to load BPF objects. Atomic Arch crossed the line from package compromise into host-compromise territory.

C2 and exfiltration behavior

Reverse engineering of the recovered atomic-lockfile@1.4.2 package found that the malware’s C2 was encoded inside the ELF itself rather than supplied by JavaScript wrapper code. Public analysis described two relevant network paths:

POST /api/agent      -> command/result channel via onion-backed transport
POST /upload         -> file-content upload path via temp.sh

That split matters because it shows a more mature collection pipeline than “zip files and curl them to one URL.” The payload appears to separate file storage from tasking/control metadata, which is a pattern defenders should expect to see in developer-focused Linux malware moving forward.

This attack abused stewardship, not just typos or maintainer creds

Most package-ecosystem guidance is written around three patterns:

  1. typo-squatted names
  2. stolen maintainer credentials
  3. malicious versions published directly to a trusted registry package

Atomic Arch used a fourth pattern that deserves its own controls:

orphaned trusted project
  -> attacker adopts stewardship
  -> package keeps its name, votes, and historical trust
  -> build instructions gain one external fetch
  -> malware arrives from another ecosystem

That is a more uncomfortable trust failure because it exploits a perfectly legitimate community workflow. The compromise path lives in the governance model as much as in the code.

Detection and scoping

Start by assuming any AUR package built or updated on 11-12 June may have been a code-execution event. Then scope from the host inward.

Search build caches and package sources for the known install markers:

rg -n \
  'atomic-lockfile|js-digest|lockfile-js|npm install|bun install|src/hooks/deps' \
  ~/.cache/yay ~/.cache/paru ~/.cache/pikaur /var/cache /tmp 2>/dev/null

Review local package history for AUR packages installed in the exposure window:

grep -E '2026-06-1[12].*(installed|upgraded)' /var/log/pacman.log
pacman -Qmq

If you have a list of locally installed AUR package names, compare it against the public inventory published by the community tracker. Because the known package set grew from 408+ to 1619, a small hand-maintained allow/deny list is likely incomplete.

On suspected hosts, check for persistence and rootkit indicators:

rg -n 'Restart=always|ExecStart=' /etc/systemd/system ~/.config/systemd/user 2>/dev/null
rg -n 'hidden_(pids|names|inodes)' /sys/fs/bpf 2>/dev/null

And look for registry/cache residue that proves the malicious package actually resolved:

rg -n 'atomic-lockfile|js-digest|lockfile-js' ~/.npm ~/.bun 2>/dev/null

Response guidance

Treat any confirmed execution of an affected Atomic Arch package as full host compromise.

  1. Isolate the workstation or build runner before rotating secrets.
  2. Preserve AUR caches, pacman.log, systemd unit files, and package-manager caches for scoping.
  3. Rotate GitHub, SSH, npm, Vault, browser-backed session, chat, cloud, and AI-platform credentials that were reachable from the host.
  4. If the package built with root privileges, assume the eBPF hiding path may have executed and favor reimaging over in-place cleanup.
  5. Audit repositories, artifact pipelines, and package-publishing workflows that used the compromised host after 11 June.

The main AppSec lesson from Atomic Arch is not “AUR can be risky.” It is that open-source supply-chain attacks are now happy to cross ecosystem boundaries mid-execution. In this case, a Linux packaging workflow became an npm malware delivery path, then a Bun-assisted follow-on path, and finally a native ELF persistence and stealth problem on the developer machine itself.

References