TL;DR

• On June 11, 2026, Sonatype researchers uncovered Atomic Arch, a new campaign targeting orphaned packages in the Arch User Repository in which attackers take over legitimate, abandoned AUR projects and modify PKGBUILDS to install a malicious npm package during installation.

• Analysis of atomic-lockfile, the malicious dependency, found a bundled Linux payload with functionality tied to credential harvesting, stealth, anti-debugging, and potential data exfiltration.

• On June 12, 2026, a second wave emerged, using Bun-based installation paths in some affected packages rather than npm alone. Researchers have now identified multiple packages associated with the campaign, including atomic-lockfile, js-digest, and lockfile-js.

• Preliminary analysis suggests the campaign may now affect approximately 1,500 packages across multiple waves of activity.

Update, June 12, 2026: Since Sonatype's initial publication, researchers have observed additional activity believed to be related to Atomic Arch, including new malicious packages, alternate installation mechanisms, and a significant increase in the number of affected AUR packages. Analysis remains ongoing and this post will be updated as new information becomes available.

---

Sonatype researchers have identified a malicious package campaign, dubbed Atomic Arch, that targets orphaned packages in the Arch User Repository (AUR).

Flagged by Sonatype Engineer Eyad Hasan, the campaign is taking control of legitimate AUR projects after maintainers abandon them. Once ownership is obtained, package build instructions are modified to install a malicious npm package called atomic-lockfile, which then deploys an additional payload onto victim systems.

Sonatype Research Labs took a closer look at the malicious atomic-lockfile dependency to understand attacker motives, tracking Atomic Arch as Sonatype-2026-003775 with a CVSS of 8.7. Analysis of the campaign is ongoing and Sonatype will update this blog as more information is available.

Atomic Arch highlights a growing supply chain risk: Attackers no longer need to create trust. Sometimes they can inherit it.

One Malicious Dependency, Massive Downstream Impact

In this case, attackers did not modify the orphaned packages "adopted" from AUR. They modified the packages' PKGBUILD to introduce a post-install script that executes npm install atomic-lockfile minimist chalk during package installation, causing affected systems to retrieve and install the npm package atomic-lockfile.

Reminiscent of the axios compromise, in which hijackers added the malicious plain-crypto-js@4.2.1 dependency, this is an effective way for attackers to get past traditional detection tools because the trusted packages themselves do not contain the malicious code.

The campaign initially appeared to affect a few dozen packages. That assessment changed rapidly.

Within 24 hours of Sonatype's initial discovery, researchers observed additional malicious packages associated with the campaign, including js-digest and lockfile-js. Researchers also identified at least one wave that appears to use Bun rather than npm as part of the installation process.

Early reporting now suggests the campaign may have affected hundreds of additional AUR packages, potentially bringing the total number of impacted packages around 1,500. Sonatype's investigation remains ongoing and package counts may continue to change as maintainers audit affected repositories.

Affected hosts should be treated as compromised. Removing the package alone may not be sufficient if the second-stage payload has already executed.

How Atomic Arch Abuses Developer Trust

The Atomic Arch campaign leverages trusted AUR packages to install additional software during package installation. Sonatype Researcher Adam Reynolds analyzed the npm package atomic-lockfile, which is installed by the modified PKGBUILDs.

The modified packages add a post-install script that invokes npm and installs atomic-lockfile during package installation. Analysis of the atomic-lockfile package identified a bundled native Linux executable that is executed during installation via a preinstall script defined in the package's package.json file. Analysis identified references to an eBPF program (scales.bpf.c) and to libbpf APIs including:

• bpf_object__load

• bpf_program__attach

• bpf_map__pin

eBPF (extended Berkeley Packet Filter) is a Linux technology that allows programs to run inside the kernel with elevated privileges. Static analysis identified functionality associated with process, file, and network hiding. The eBPF-related functionality references hooks for getdents64(), the system call used to enumerate directory entries, and maintains structures named hidden_pids, hidden_names, and hidden_inodes.

The executable also contains functionality associated with Linux socket diagnostics interfaces, including NETLINK_SOCK_DIAG, and logic related to debugger detection through PTRACE_ATTACH and PTRACE_SEIZE, suggesting efforts to reduce visibility and hinder analysis.

The binary contains references to GitHub credentials, SSH artifacts, HashiCorp Vault tokens, browser cookie databases, Slack, Discord, Microsoft Teams, and Telegram data stores. Taken together, these references strongly indicate credential and token harvesting functionality.

The executable also includes archive support, multipart form-data handling, and HTTP upload functionality, including references to POST /upload, indicating potential data collection and exfiltration capabilities.

AUR Stewardship Process Offers Unique Attacker Opportunity

The Arch User Repository allows community members to maintain package definitions for software not included in the official Arch repositories. When a maintainer abandons a package, it becomes orphaned and another user can request ownership.

In the Atomic Arch campaign, attackers appear to be exploiting this process to gain stewardship of trusted packages already used by the community. Attackers adopt orphaned AUR packages. The package keeps its existing name, history, and user trust, but control of its build instructions changes hands.

From the user's perspective, they are simply installing or updating a familiar package from a trusted source.

The Atomic Arch Payload Wasn't in the Package

The most important lesson from Atomic Arch is the trust model.

• Traditional supply chain attacks attempt to convince developers to install something new.

• Typosquatting attacks exploit mistakes.

• Brandjacking attacks exploit familiarity.

• Atomic Arch appears to exploit ownership.

Attackers are not building trust from scratch. They're acquiring projects that have already earned it. That dramatically reduces the warning signs developers normally rely on when evaluating software.

As software ecosystems continue to rely on volunteer maintainers and community stewardship, ownership transitions may become an increasingly attractive target for attackers looking to compromise trusted distribution channels from the inside.