AUR-Supply-Chain-Attack: Bin ich betroffen? Der 5-Minuten-Check statt Panik

WICHTIG: Nicht „Arch wurde gehackt”, sondern: AUR-Pakete wurden gekapert.

Ich habe das Ding heute selbst auf meinem Arch-System gegengeprüft. Das hier ist kein Panikpost, sondern mein Ablauf und eine erste Einschätzung, was aktuell los ist.

Die offiziellen Repos (core, extra, multilib) sind nicht betroffen.

Der Schadcode steckt nicht im offiziellen Arch-Repo. Er kam über manipulierte AUR-Build-/Install-Skripte, die unter anderem npm install atomic-lockfile oder bun install js-digest ausführen und einen Rust-Infostealer starten.¹

Wer im Zeitfenster ab 11. Juni 2026 kein AUR-Paket gebaut, installiert oder aktualisiert hat, ist mit hoher Wahrscheinlichkeit nicht betroffen. Trotzdem: verifizieren, nicht hoffen.

Unten ist der komplette Check: Schritt für Schritt, kopierbar, mit Fußnoten zu den Fakten.

Was wirklich passiert ist

Am 11./12. Juni 2026 wurde im Arch User Repository (AUR) eine groß angelegte Supply-Chain-Attacke öffentlich. Sicherheitsforscher von Sonatype nennen die Kampagne „Atomic Arch” und tracken sie als Sonatype-2026-003775 mit einem CVSS-Score von 8.7.²

Wichtig ist, was nicht passiert ist: Das AUR ist die community-gepflegte Paketsammlung von Arch und strikt getrennt von den offiziellen Repos. Die offiziellen Repositories wurden nicht kompromittiert. Es gibt keinen Hinweis darauf, dass Archs eigene Paket-Infrastruktur eingebrochen wurde.¹

Wenn dir jemand „Arch wurde gehackt” erzählt: korrigieren. Nicht aus Pedanterie. Die Unterscheidung entscheidet, ob du überhaupt betroffen sein kannst.

Der Angriffsweg: Vertrauen, kein Exploit

Das hier ist kein Zero-Day. Der Angriff zielt auf das Vertrauensmodell des AUR, nicht auf eine Software-Lücke. Der Ablauf:

Die Angreifer übernahmen verwaiste (orphaned) Pakete über den normalen Adoption-Prozess des AUR.²
Sie fälschten Git-Commit-Metadaten, damit die Änderungen aussahen, als kämen sie von einem langjährigen Maintainer. Dessen Account war laut The Hacker News, unter Berufung auf einen Arch Trusted User, nicht kompromittiert.¹
In PKGBUILD- bzw. .install-Dateien wurden Aufrufe wie npm install atomic-lockfile eingebaut, teils getarnt zwischen legitimen Paketen. Das npm-Paket atomic-lockfile@1.4.2 trägt einen preinstall-Hook, der eine gebündelte ELF-Binary namens deps ausführt.³

Genau deshalb sah das Paket beim flüchtigen Blick normal aus: gleicher Name, gleiche Historie, gleiches Vertrauen. Nur die Bau- oder Install-Anweisung war vergiftet.

Wichtig für die Bewertung: Bei .install-Hooks passiert der kritische Teil nicht nur „beim Build”, sondern beim Paket-Install über pacman/AUR-Helper. Und dieser Pfad kann mit Root-Rechten laufen. Also: AUR-Paket bauen, installieren oder aktualisieren = relevant.

Ein zweiter Schwung lief über bun install js-digest. Sonatype nennt außerdem weitere Pakete wie lockfile-js; in der Mailingliste tauchten weitere Namen auf. Deshalb nicht nur auf einen String starren. Prüfen auf atomic-lockfile, js-digest, lockfile-js und src/hooks/deps.²⁴

Als bestätigte Beispiele nennt The Hacker News alvr und premake-git; die offizielle Mailingliste sammelte parallel weitere Meldungen. Die vollständige Liste war beim Schreiben nicht stabil. Frühe Greps über den AUR-Git-Mirror landeten bei rund 408 Paketen, spätere Sonatype-Updates sprechen von potenziell deutlich mehr, bis grob 1.500 über mehrere Wellen.¹²⁴

Was die Malware tut

Der unabhängige Forscher Whanos hat das deps-Payload reverse-engineered. Es ist ein Rust-Credential-Stealer, gebaut für Entwickler-Workstations und Build-Systeme.³

Kurz gesagt: Das Ding sucht nicht nach Urlaubsfotos. Es sucht nach allem, womit man sich als Entwickler irgendwo einloggen kann. Es sammelt unter anderem:

Cookies, Tokens und Local Storage aus Chromium-Browsern wie Chrome, Edge, Brave und vielen mehr
Session-Daten aus Electron-Apps wie Slack, Discord und Microsoft Teams
GitHub-, npm- und HashiCorp-Vault-Tokens, dazu OpenAI/ChatGPT-Bearer-Material
SSH-Keys, known_hosts, Shell-Historien
Docker-/Podman-Credentials und VPN-Profile

Exfiltriert wird per HTTP zu temp.sh; das Command-and-Control läuft über einen Tor-Onion-Service via lokalem Loopback-Proxy. Für Persistenz installiert sich die Malware als systemd-Service mit Restart=always. Mit Root unter /var/lib/ plus Unit in /etc/systemd/system/, als normaler User im Home plus ~/.config/systemd/user/.³

Das eBPF-Rootkit wurde in frühen Berichten überzeichnet: Es ist optional und lädt nur, wenn die Binary bereits Root und die nötige Capability hat. Es eskaliert keine Rechte. Es versteckt Prozesse, Prozessnamen und Socket-Inodes über gepinnte BPF-Maps namens hidden_pids, hidden_names, hidden_inodes und blockt Debugger.³

Die Konsequenz ist unangenehm, aber simpel: Wenn das Payload mit Root lief, reicht das bloße Entfernen des Pakets nicht. Ein Paketmanager räumt nur die Dateien weg, die er kennt. Er kann nicht beweisen, dass die Maschine nach einem rootkit-fähigen Payload sauber ist. Dann gilt: neu aufsetzen von vertrauenswürdigem Medium.¹

Der Check: Bin ich betroffen?

Jetzt der praktische Teil. Das hier ist der Ablauf, den ich auf meinem eigenen System durchgespielt habe. Kopierbar, von harmlos nach gründlich sortiert. Kein Spezial-Tool. Nur das, was auf Arch sowieso da ist.

Schritt 0 - Die Grundfrage: Nutzt du überhaupt AUR?

pacman -Qm

-Qm listet alle „foreign” Pakete, also alles, was nicht aus den offiziellen Repos kommt. Typischerweise AUR. Kommt hier nichts zurück, nutzt dein System aktuell keine Foreign-Pakete. Das senkt das Risiko stark.

Aber: Das ist kein forensischer Beweis. Wenn du im kritischen Zeitraum ein AUR-Paket gebaut, installiert, aktualisiert und danach wieder entfernt hast, sieht pacman -Qm das nicht mehr. Dann ist Schritt 3 dein Zeuge.

Kommt eine Liste, nicht in Panik verfallen. Der Angriff zielte gezielt auf verwaiste, adoptierte Pakete. Große, aktiv gepflegte Pakete passen weniger ins Beuteschema. Aber: Paketnamen-Matching ist kein Beweis. Die echten Checks folgen jetzt.

Schritt 1 - IOC-Scan über die Build-Caches

Die bekannten Marker-Strings plus den Payload-Pfad in deinen yay-/paru-Caches suchen:

grep -rsnE "atomic-lockfile|js-digest|lockfile-js|src/hooks/deps" \
  ~/.cache/yay ~/.cache/paru ~/.config/yay 2>/dev/null

Die Strings stammen aus den Vorfallsanalysen und den laufenden Meldungen: npm install atomic-lockfile, bun install js-digest, weitere Lockfile-Namen und der Payload-Pfad src/hooks/deps.²

Leer = gut. Ein Treffer heißt: direkt zu „Wenn etwas anschlägt” weiter unten.

Haken: Wenn du deinen Cache geleert hast (yay -Sc / paru -Sc), liegen dort keine Build-Dateien mehr. Dann ist Schritt 3, das pacman.log, dein verlässlicher Zeuge.

Schritt 2 - Verdächtige `.install`-Hooks in deinen Paketen

Der eigentliche Trick lief oft über npm-/bun-Aufrufe in einer .install-Datei. Über alle Foreign-Pakete iterieren und genau danach suchen:

for pkg in $(pacman -Qmq); do
  find ~/.cache/yay/$pkg ~/.cache/paru/clone/$pkg -name "*.install" 2>/dev/null \
    -exec grep -lE "npm install|bun install" {} \;
done

Wichtige Nuance: Es gibt legitime Post-Install-Hooks, und manche Pakete brauchen npm oder bun in nachvollziehbaren Kontexten. Ein Treffer ist also nicht automatisch Malware. Aber ein Treffer ist ein Grund, die Datei zu öffnen und zu lesen. Nicht wegklicken. Lesen.⁵

Schritt 3 - Das Zeitfenster im pacman-Log

Der entscheidende Faktor ist Timing: Der Angriff wurde ab 11. Juni 2026 scharf. Prüfe, ob du seitdem überhaupt AUR-Pakete gebaut, installiert oder aktualisiert hast.

awk '$1 >= "[2026-06-11"' /var/log/pacman.log \
  | grep -E "\[ALPM\] (installed|upgraded)"

Diese Liste zeigt Installationen und Upgrades. Nicht automatisch nur AUR. Verdächtig wird es, wenn dort Pakete auftauchen, die du über AUR/yay/paru installiert hast oder die in betroffenen Paketlisten oder Build-Caches Spuren hinterlassen.

Kommt hier nichts Relevantes oder nur offizielle Pakete: Du hast im kritischen Fenster nichts Verdächtiges installiert. In Kombination mit leeren Schritten 1 + 2 ist der Fall für die allermeisten sauber. Kein Theater. Kein panisches Key-Rotieren.

Schritt 4 - Persistenz & Rootkit-Spuren

Wenn du ganz sichergehen willst oder Schritt 1-3 etwas geliefert haben, suchst du nach den Persistenz-Mechanismen:

# Unbekannte/aktivierte systemd-Units - System- und User-Ebene
systemctl list-unit-files --state=enabled
ls -la ~/.config/systemd/user/ 2>/dev/null

# Verdächtige Dateien unter /var/lib (Root-Variante des Payloads)
sudo find /var/lib -maxdepth 2 -type f -newermt "2026-06-10" 2>/dev/null

# eBPF-Rootkit-Maps - die drei Namen sind hart aus der Analyse
sudo find /sys/fs/bpf -maxdepth 3 2>/dev/null \
  | grep -E "hidden_pids|hidden_names|hidden_inodes"

Die BPF-Map-Namen hidden_pids, hidden_names, hidden_inodes stammen direkt aus der Reverse-Engineering-Analyse.³

Schritt 5 - Hash-Abgleich (optional, für Forensiker)

Die SHA-256 des Haupt-Payloads ist öffentlich:

6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b

Wenn du eine verdächtige Binary gefunden hast, gleich ab:

sha256sum /pfad/zur/verdaechtigen/binary

Der vollständige Indikatorensatz inklusive Onion-C2-Host steht in der ioctl.fail-Analyse.³

Wenn etwas anschlägt

Schlägt einer der Checks an und ein geflaggtes Paket ist tatsächlich gelaufen: Behandle den Host als credential-kompromittiert. Nicht diskutieren. Reihenfolge:¹

Alles rotieren, was der Stealer anfasst: Browser-Sessions, SSH-Keys, GitHub-/npm-Tokens, Slack-/Teams-/Discord-Sessions, Vault-Tokens, Docker-/Podman-Credentials, Cloud-Keys.
Persistenz jagen: unbekannte systemd-Services auf System- und User-Ebene, Dateien unter /var/lib/, BPF-Maps, ausgehende Verbindungen zu Tor und Upload-Diensten.
Lief das Paket als Root: Rootkit annehmen und neu aufsetzen. Ein rootkit-fähiges Payload, das Root hatte, lässt sich nicht zuverlässig „wegputzen”. Vertrauenswürdiges Medium, frische Installation. Punkt.

Die eigentliche Lehre: Hygiene schlägt Panik

Der nüchterne Teil. Zwei Dinge machen diesen Vorfall von einem Drama zu einem lösbaren Problem.

1. PKGBUILD und .install vor dem Build oder Update lesen. Das ist exakt die Empfehlung aus dem offiziellen Arch-Advisory: alle PKGBUILD- und Install-Skript-Änderungen beim Update prüfen, besonders während eines laufenden Vorfalls.⁶ Mit yay erzwingst du die Diffs:

yay --answerdiff All

So fällt ein plötzlich eingebauter npm-/bun-Hook wenigstens auf. Natürlich nur, wenn man nicht blind Enter drückt. Genau das ist der Punkt.

2. AUR gehört nicht auf alles. Auf einer Entwickler-Workstation: okay. Aber nur, wenn du bereit bist, mitzulesen. AUR ist kein App Store. Auf produktiven oder sicherheitskritischen Servern ist AUR genau das Risiko, das dieser Vorfall illustriert. Dort: offizielle Repos. Und wenn etwas aus dem AUR sein muss, dann bewusst, einzeln, gelesen, nicht als Beifang im Update-Marathon.

Der wichtigste Reflex überhaupt: erst verifizieren, dann handeln. Die halbe Internet-Reaktion auf so eine Meldung ist panisches Plattmachen und Key-Rotieren „zur Sicherheit”. Fünf Minuten grep sagen dir, ob das nötig ist. Meistens ist es das nicht.

Das ist die eigentliche Lehre aus dem Vorfall: Nicht weniger Arch. Mehr Lesen.

Dein Frühwarnsystem: `informant`

Genau bei diesem Vorfall hat sich ein kleines Tool bewährt, das die wenigsten installiert haben: informant, ein Arch-News-Reader, der gleichzeitig als pacman-Hook arbeitet.⁷

Die Idee ist simpel und richtig: informant hängt sich als PreTransaction-Hook mit AbortOnFail in pacman ein und ruft bei jedem Install/Upgrade informant check auf. Der Befehl beendet sich mit einem Return-Code gleich der Anzahl ungelesener News-Items und unterbricht damit deine pacman-Transaktion, solange ungelesene News offen sind.⁷

Heißt im Klartext: Du kommst nicht an dein nächstes Update, ohne das offizielle Advisory gesehen zu haben.

Setup

informant liegt selbst im AUR und installiert seinen Hook automatisch nach /usr/share/libalpm/hooks/:

Nicht blind während eines laufenden AUR-Incidents installieren. Erst PKGBUILD und .install lesen, dann bewusst entscheiden. informant ist Frühwarnung, kein Schutzschild.

yay -S informant

Bedienung mit drei Subcommands:

informant check   # prüft auf ungelesene News (der Hook nutzt genau das)
informant list    # listet alle News-Items
informant read    # geht ungelesene Items durch und markiert sie als gelesen

Beim ersten Lauf nimmt informant an, dass du noch nichts gelesen hast. Einmal informant read durchklicken, dann ist Ruhe.⁷

Die ehrliche Einschränkung

Und jetzt der Teil, den die meisten Tutorials weglassen: informant ist Frühwarnung, kein Schutz.

Das Tool warnt vor offiziellen Arch-Linux-News. In diesem Fall hat das funktioniert, weil das AUR-Advisory als offizielle News veröffentlicht wurde. informant hätte dich also gezwungen, es zu lesen, bevor du blind weiteraktualisierst. Aber:

Es schützt dich nicht vor einem einzelnen kompromittierten AUR-Paket, das still ein Update bekommt. Ein vergifteter PKGBUILD löst keinen News-Eintrag aus.
Es ersetzt nicht das Lesen der Diffs (yay --answerdiff All). Beides ergänzt sich: das eine warnt vor der Lage, das andere vor dem konkreten Paket.
Kleine Ironie: informant ist selbst ein AUR-Paket. Es ist seit Jahren etabliert und aktiv gepflegt, aber das Vertrauensmodell, über das wir hier reden, gilt grundsätzlich auch für dieses Tool.

Kurz: informant ist ein sinnvoller Layer in einer Verteidigung aus mehreren Schichten. Nicht die Lösung an sich.

Kontext: Das ist nicht neu

Dieselbe Adoption-Taktik traf 2018 schon ein verwaistes PDF-Viewer-Paket (acroread). Die 2026er-Version hat es nur skaliert. Teil eines breiteren Trends: Angreifer kapern verwaiste Projekte, um geerbtes Vertrauen auszunutzen, statt per Typosquatting neue Opfer zu suchen.⁸

Das Vertrauensmodell ist das Ziel. Ein kürzlich adoptiertes Paket oder eines, das nach langer Stille plötzlich neue Install-Hooks bekommt, verdient ab jetzt dieselbe Skepsis wie ein Paket von einem Fremden.

Euer Mehmet

Hinweis: Self-Hosting-/Security-Themen veralten schnell. Die Liste betroffener Pakete war zum Redaktionszeitpunkt unvollständig und wuchs noch. Im Zweifel die offizielle Arch-News und die aur-general-Mailingliste als Primärquellen prüfen.

The Hacker News — Over 400 Arch Linux AUR Packages Hijacked to Deploy Infostealer and eBPF Rootkit. https://thehackernews.com/2026/06/over-400-arch-linux-aur-packages.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Sonatype — Atomic Arch: Attackers Hijack Trusted AUR Packages to Deliver Rootkit-Like Malware. https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency ↩ ↩² ↩³ ↩⁴ ↩⁵
Whanos/ioctl.fail — Preliminary analysis of AUR malware. https://ioctl.fail/preliminary-analysis-of-aur-malware/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Arch Linux aur-general — AUR REPORT THREAD. https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/ ↩ ↩²
GamingOnLinux — The Arch Linux AUR had over 400 packages compromised with malware. https://www.gamingonlinux.com/2026/06/the-arch-linux-aur-had-over-400-packages-compromised-with-malware/ ↩
Arch Linux — Active AUR malicious packages incident. https://archlinux.org/news/active-aur-malicious-packages-incident/ ↩
bradford-smith94 — informant: An Arch Linux News reader and pacman hook. https://github.com/bradford-smith94/informant ↩ ↩² ↩³
The Hacker News — Malware Found in Arch Linux AUR Package Repository. https://thehackernews.com/2018/07/arch-linux-aur-malware.html ↩