Der Angriff zielte nicht auf eine Schwachstelle in Arch Linux, sondern auf das Vertrauensmodell des AUR. Laut Quelltext wurden aufgegebene Pakete übernommen und ihre Build-Dateien so verändert, dass beim Erstellen der Software ein schädliches npm-Paket nachgeladen wird. Sonatype berichtet, dass die Täter gezielt verwaiste Projekte ins Visier nahmen. Zusätzlich fälschten sie Metadaten von Git-Commits so, dass die Änderungen scheinbar von einem langjährigen Maintainer stammten. Ein Arch Linux Trusted User bestätigte später, dass das betreffende Konto nicht kompromittiert worden war.
Nach der Übernahme eines Pakets ergänzten die Angreifer in PKGBUILD oder .install den Befehl „npm install atomic-lockfile“. So wurde neben einigen legitimen Paketen zur Tarnung das bösartige npm-Paket atomic-lockfile@1.4.2 eingebunden. Dieses enthält einen preinstall-Hook, der eine mitgelieferte Linux-ELF-Datei namens deps ausführt. Bestätigte Beispiele, die an die Arch-Mailingliste gemeldet wurden, sind laut Quelltext die Pakete alvr und premake-git.
Whanos hat den Payload deps untersucht und beschreibt ihn als in Rust geschriebenen Credential-Stealer für Entwickler-Systeme und Build-Umgebungen. Gestohlene Dateien werden per HTTP an temp.sh übertragen. Die Kommando-und-Kontroll-Kommunikation läuft über einen Tor-Onion-Dienst, angesprochen über einen lokalen Loopback-Proxy.
Für Persistenz installiert sich die Malware als systemd-Dienst mit „Restart=always“. Mit Root-Rechten kopiert sie sich nach /var/lib/ und legt eine Unit-Datei unter /etc/systemd/system/ ab. Ohne Root nutzt sie stattdessen das Home-Verzeichnis sowie eine benutzerspezifische Unit unter ~/.config/systemd/user/. Der Quelltext betont, dass die frühe Berichterstattung die Rolle des eBPF-Rootkits überzeichnet habe: Es ist optional und wird nur geladen, wenn der Binärcode bereits Root-Rechte und die nötige Capability besitzt. Es dient nicht zur Rechteausweitung.
Wird das Rootkit aktiviert, versteckt es die Prozesse der Malware, Prozessnamen und Socket-Inodes vor Standardwerkzeugen. Dazu verwendet es angeheftete BPF-Maps mit den Namen hidden_pids, hidden_names und hidden_inodes. Außerdem beendet es Versuche, einen Debugger anzuhängen. Daraus folgt laut Quelltext auch, dass das Entfernen des betroffenen AUR-Pakets allein nicht ausreicht, wenn der Payload bereits ausgeführt wurde: Ein Paketmanager kann nur bekannte Dateien löschen, aber nicht belegen, dass ein System danach wieder sauber ist.
Zusätzlich legt der Binärcode eine zweite Datei mit Bezug zu monero-wallet-gui ab, die in der Analyse als möglicher, bislang nicht untersuchter Kryptominer markiert wird. Sonatypes erste Auswertung sprach zunächst von mehr als 20 gekaperten Paketen. Innerhalb eines Tages erfassten Community-Tracker und der Thread aur-general bereits mehr als 400. Eine per grep aus dem AUR-Git-Mirror erzeugte Hauptliste kam auf rund 408 Pakete; zusammengeführte Listen lagen noch höher.
Eine zweite Welle nutzte statt npm den Befehl „bun install js-digest“. Laut Community-Trackern stammen die beteiligten Konten aus einem separaten Account-Set, das aber mit demselben npm-Publisher wie atomic-lockfile verknüpft wird. Der Payload dieser Welle ist ein anderer Binärcode, nach seinem Hash eine separate ELF-Datei, die von der Community ebenfalls als schädlich eingestuft wurde. Wie weit sich diese zweite Welle verbreitet hat, wird noch ermittelt. Deshalb sollen Nutzer laut Quelltext sowohl nach atomic-lockfile als auch nach js-digest suchen.
Für die Erkennung nennt der Quelltext den SHA-256-Hash des Haupt-Payloads: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b. Weitere Indikatoren, einschließlich des Onion-C2-Hosts, enthält die Analyse von ioctl.fail. Eine CVE-Nummer wurde nicht vergeben. Sonatype führt die Kampagne unter Sonatype-2026-003775 mit einem CVSS-Wert von 8,7.