Executive Summary
On June 11–12, 2026, a large-scale supply chain attack, dubbed the Atomic Arch campaign, was disclosed targeting the Arch User Repository (AUR). Attackers systematically adopted approximately 1,500 orphaned AUR packages, modifying their build instructions to install a malicious npm package, atomic-lockfile, and its variants. This malware, written in Rust, is designed to harvest credentials and exfiltrate sensitive data from developer workstations and continuous integration (CI) environments running Arch Linux or Arch-based distributions. The attack leverages the trust inherent in open-source package ecosystems, bypassing traditional detection by only altering build scripts rather than the package code itself. The campaign demonstrates advanced persistence and stealth techniques, including eBPF-based rootkit functionality on systems where root access is obtained. Directly affected are users and organizations installing or updating AUR packages on Arch-based systems, including self-hosted CI runners and developer environments. There is no evidence of direct impact on non-Arch platforms or on GitHub-hosted runners. All technical claims are corroborated by three independent, primary sources, and no attribution to a specific threat actor has been made as of June 12, 2026.
Technical Information
The Atomic Arch campaign represents a sophisticated supply chain compromise targeting the Arch User Repository (AUR), a community-driven repository for Arch Linux packages. Attackers exploited the AUR's package adoption process, which allows community members to take over maintenance of orphaned packages. By systematically adopting these packages, attackers gained control over trusted software with established user bases.
Once in control, attackers modified the PKGBUILD files or install hooks of the adopted packages. Instead of altering the package code directly, they injected commands to execute npm install atomic-lockfile or similar variants such as js-digest and lockfile-js during the package installation or update process. This approach allowed the malicious payload to be delivered transparently to users who trusted the original package lineage, effectively bypassing traditional malware detection mechanisms that focus on code changes within the package itself (StepSecurity, 2026-06-12; Sonatype, 2026-06-11; Privacy Guides, 2026-06-12).
The malicious npm package, atomic-lockfile, contains a native Linux executable written in Rust. Upon installation, this executable is run via a preinstall script defined in the package's package.json. The payload is designed to harvest a wide range of credentials and sensitive data, including browser cookies and session tokens (for single sign-on, cloud consoles, and SaaS applications), SSH keys and known_hosts files, developer tokens for platforms such as GitHub and npm, session data for communication platforms like Slack, Discord, and Microsoft Teams, as well as Docker/Podman credentials and cloud access keys. The malware also includes anti-debugging and anti-forensics features to hinder analysis and detection (StepSecurity; Sonatype).
On systems where the malware gains root privileges, it attempts to establish persistence and evade detection using eBPF (extended Berkeley Packet Filter)–based rootkit techniques. This allows the malware to hide its processes and file activity, making detection and remediation significantly more challenging. Technical analysis identified references to eBPF program files such as scales.bpf.c and the use of libbpf APIs including bpf_object__load, bpf_program__attach, and bpf_map__pin (Sonatype).
The attack is mapped to several MITRE ATT&CK techniques, including T1078 (Valid Accounts), T1195.002 (Supply Chain Compromise), T1204.002 (User Execution: Malicious File), T1059 (Command and Scripting Interpreter), T1546.008 (Event Triggered Execution: Application Shimming), T1564.006 (Hide Artifacts: Rootkit), T1552 (Unsecured Credentials), T1005 (Data from Local System), and T1041 (Exfiltration Over C2 Channel).
The campaign is opportunistic, targeting any user or organization that installs or updates affected AUR packages. High-value targets include developer environments, CI/CD infrastructure, and systems with access to sensitive credentials or cloud resources. The attack does not directly impact non-Arch platforms or GitHub-hosted runners, but similar risks exist in other open-source package ecosystems with comparable package ownership models.
All technical claims are supported by direct analysis of malware samples, build script modifications, and credential harvesting functionality, as documented by three independent security research teams. No explicit attribution to a specific threat actor has been made, but the sophistication of the campaign suggests a well-resourced adversary.
Affected Versions & Timeline
The attack specifically targets orphaned packages in the Arch User Repository (AUR). The initial wave was detected and disclosed on June 11, 2026, with subsequent analysis revealing that the campaign had affected approximately 1,500 packages across multiple waves. The attackers exploited the AUR's package adoption process, taking over packages that had been abandoned by their original maintainers. Once adopted, the attackers modified the PKGBUILD files to include post-install scripts that executed the malicious npm or Bun install commands.
Affected systems include any Arch Linux or Arch-based distribution (such as EndeavourOS and Manjaro, when AUR is used) where users installed or updated the compromised AUR packages during the attack window. Self-hosted CI runners or build agents running Arch Linux and installing AUR packages as part of their workflows are also directly impacted. Windows developers running Arch under WSL2 and installing AUR packages within that environment are similarly at risk.
The campaign does not directly affect GitHub-hosted runners (which use Ubuntu, Windows, or macOS images), self-hosted runners on RHEL/Rocky, Debian/Ubuntu, or Windows (unless Arch/AUR is used via nested virtualization), or macOS and Windows developer machines. However, the attack highlights structural risks present in other package ecosystems with similar ownership transfer models (StepSecurity).
The timeline of the attack is as follows: - June 11, 2026: Initial disclosure and analysis by Sonatype and the Arch Linux community. - June 12, 2026: Second wave identified, with expanded use of Bun-based installation paths and additional malicious packages. - June 12, 2026: Community analysis confirms the scale of the attack, with approximately 1,500 packages compromised.
Threat Activity
The Atomic Arch campaign is characterized by its exploitation of the AUR's package adoption process, allowing attackers to gain control over trusted packages without raising immediate suspicion. By modifying only the build instructions (PKGBUILD files) and not the package code itself, the attackers bypassed traditional malware detection mechanisms and leveraged the existing trust in the open-source ecosystem.
The malicious npm package, atomic-lockfile, and its variants are designed to execute credential-stealing payloads upon installation. The payload targets a broad range of sensitive data, including browser cookies, SSH keys, developer tokens, and session data for various communication and cloud platforms. On systems where root access is obtained, the malware deploys eBPF-based rootkit functionality to hide its presence and maintain persistence.
The attack is opportunistic, affecting any user or organization that installs or updates the compromised AUR packages. High-value targets include developer workstations, CI/CD infrastructure, and systems with access to sensitive credentials or cloud resources. The campaign demonstrates advanced techniques, including anti-debugging, anti-forensics, and stealth mechanisms, making detection and remediation challenging.
No explicit attribution to a specific threat actor has been made. The sophistication of the campaign, including the use of Rust for the payload and eBPF for persistence, suggests a well-resourced adversary. However, there is no direct technical evidence linking the campaign to any known advanced persistent threat (APT) or cybercrime group as of June 12, 2026.
Mitigation & Workarounds
The following mitigation and remediation actions are prioritized by severity:
Critical: Organizations using Arch Linux or Arch-based distributions for developer workstations, CI runners, or build agents must immediately identify all systems that have installed or updated AUR packages since June 11, 2026. Any system found to have installed a compromised package should be treated as fully compromised, with the assumption that all credentials and secrets present on the system have been exfiltrated. Immediate incident response actions should include revoking and rotating all potentially exposed credentials, tokens, and keys, and rebuilding affected systems from trusted sources.
High: Implement behavioral monitoring and endpoint detection on all developer and CI systems running Arch Linux to detect anomalous activity, such as unauthorized network connections, credential access, or eBPF-based persistence mechanisms. Review and restrict the use of orphaned or community-maintained packages, and establish internal policies for package adoption and review.
Medium: Audit all package installation and update logs for evidence of npm or Bun install commands referencing atomic-lockfile, js-digest, or lockfile-js. Remove any affected packages and replace them with trusted, verified versions. Educate developers and DevOps teams about the risks associated with orphaned package adoption and the importance of verifying package maintainers.
Low: Monitor upstream advisories from the Arch Linux community and security research organizations for updates on affected packages and remediation guidance. Consider implementing allowlists for approved packages and maintainers in your software supply chain.
References
StepSecurity, June 12, 2026: https://www.stepsecurity.io/blog/400-aur-packages-hijacked-atomic-arch-campaign Sonatype, June 11–12, 2026: https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency Privacy Guides, June 12, 2026: https://www.privacyguides.org/news/2026/06/12/around-1-500-aur-packages-compromised-with-rootkit-like-malware/
About Rescana
Rescana provides a third-party risk management (TPRM) platform designed to help organizations identify, assess, and monitor supply chain risks across open-source and proprietary software ecosystems. Our platform enables continuous monitoring of package repositories, automated detection of anomalous package adoption or modification events, and integration with incident response workflows. For questions or further guidance, contact us at ops@rescana.com.
