# Nächster Angriff auf das AUR

**URL:** https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109
**Category:** News und Downloads
**Created:** [6. August 2026 um 20:41 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109 "2026-08-06T20:41:41Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![gosia](https://manjaro-forum.de/user_avatar/manjaro-forum.de/gosia/32/139_2.png) [@gosia](https://manjaro-forum.de/u/gosia)
#### Post date: [6. August 2026 um 20:41 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109/1 "2026-08-06T20:41:41Z")

</div>

Auf das AUR gibt es ja seit ca. einer Woche einen neuen Angriff, diesmal noch versteckter und gefährlicher als im Juni.  
Wer sich ganz intensiv mit den Hintergründen befassen möchte, dem kann ich diesen FOSS-Artikel empfehlen:  
[https://www.fosslinux.com/159893/arch-linux-aur-malware-security-crisis.htm](https://www.fosslinux.com/159893/arch-linux-aur-malware-security-crisis.htm)  
Für alle die es auf deutsch und einfacher lesen möchten gibt es eine Zusammenfassung von Heise:  
[https://www.heise.de/news/Neue-Malware-Welle-Arch-Linux-blockiert-AUR-Updates-11395880.html](https://www.heise.de/news/Neue-Malware-Welle-Arch-Linux-blockiert-AUR-Updates-11395880.html)

viele Grüsse gosia

---

<div class="post-metadata">

### Author: ![Daemon](https://manjaro-forum.de/user_avatar/manjaro-forum.de/daemon/32/157_2.png) [@Daemon](https://manjaro-forum.de/u/Daemon)
#### Post date: [7. August 2026 um 05:08 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109/2 "2026-08-07T05:08:21Z")

</div>

Tja, ist ja blöd gelaufen wenn man verwaiste Pakete „einfach“ an jemand neues übergibt.

Ich hoffe nur die finden eine Lösung und schalten es nicht komplett ab.

Deshalb sage ich es immer wieder: Das Problem ist nicht das AUR selbst, sondern weil die Leute zu faul sind um sich das PKGBUILD anzusehen. Wenn man es nicht versteht, kann man z.B. hier fragen, oder eine KI seiner Wahl.

---

<div class="post-metadata">

### Author: ![LaGGGer](https://manjaro-forum.de/letter_avatar_proxy/v4/letter/l/f0a364/32.png) [@LaGGGer](https://manjaro-forum.de/u/LaGGGer)
#### Post date: [8. August 2026 um 08:20 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109/3 "2026-08-08T08:20:18Z")

</div>

> [@Daemon](#):
>
> Das Problem ist nicht das AUR selbst, sondern weil die Leute zu faul sind um sich das PKGBUILD anzusehen.

Das ist wohl richtig, aber ich muss zugeben das ich das auch noch nie gemacht habe. Ich wüste auch gar nicht wie ich in der PKGBUILD erkennen könnte wenn damit was nicht stimmt.

Aber ich werde mir die Datei jetzt mal anscheuen wenn ich mal wieder was aus dem AUR installiere.  
Mal sehen ob ich das verstehe.

---

<div class="post-metadata">

### Author: ![gosia](https://manjaro-forum.de/user_avatar/manjaro-forum.de/gosia/32/139_2.png) [@gosia](https://manjaro-forum.de/u/gosia)
#### Post date: [8. August 2026 um 13:23 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109/4 "2026-08-08T13:23:01Z")

</div>

Hallo LaGGGer,

> [@LaGGGer](#):
>
> Mal sehen ob ich das verstehe.

naja, in diesem Artikel  
[https://www.fosslinux.com/159893/arch-linux-aur-malware-security-crisis.htm](https://www.fosslinux.com/159893/arch-linux-aur-malware-security-crisis.htm)  
stehen leider ziemlich am Ende (_„How to Protect Yourself: The AUR Security Checklist“_) ein paar Anweisungen, auf was man mindestens achten sollte:  
_„Spend 30 seconds scanning for curl, wget, eval, exec, base64, or obfuscated strings.“_  
mit ein paar kleinen Kommandos wie  
`git clone ...`  
`grep -n "curl|wget|eval|exec|base64|hidden" ...`  
`git log --oneline -5`  
zur Kontrolle  
s. _„Here is what a clean PKGBUILD review looks like in practice:“_

viele Grüsse gosia

---

<div class="post-metadata">

### Author: ![Daemon](https://manjaro-forum.de/user_avatar/manjaro-forum.de/daemon/32/157_2.png) [@Daemon](https://manjaro-forum.de/u/Daemon)
#### Post date: [8. August 2026 um 13:53 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109/5 "2026-08-08T13:53:34Z")

</div>

> [@LaGGGer](#):
>
> Das ist wohl richtig, aber ich muss zugeben das sich das auch noch nie gemacht habe. Ich wüste auch gar nicht wie ich in der PKGBUILD erkennen könnte wenn damit was nicht stimmt.

Ja, kann ich nochvollziehen.  
Aber, zum einen wie es @gosia bereits gesagt hat, und zum anderen, lasst euch überraschen was mein Paketmanager macht. 😉 Dauert aber noch etwas.

---

<div class="post-metadata">

### Author: ![PepsiRaver](https://manjaro-forum.de/user_avatar/manjaro-forum.de/pepsiraver/32/160_2.png) [@PepsiRaver](https://manjaro-forum.de/u/PepsiRaver)
#### Post date: [8. August 2026 um 16:36 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109/6 "2026-08-08T16:36:41Z")

</div>

> [@LaGGGer](#):
>
> Das ist wohl richtig, aber ich muss zugeben das ich das auch noch nie gemacht habe. Ich wüste auch gar nicht wie ich in der PKGBUILD erkennen könnte wenn damit was nicht stimmt.

Ja sehe ich auch so. Ich habe auch das eine oder andere Programm aus dem Aur. Ich instaliere aber auch nur wenn in den Offizellen Repos nix finde. ICh wüsste auhc nciht wie man die OkBuild liest oder woran man erkennt is das gut oder böse.

Wenn ich die letzen atacken so ansehe is das Aur ja riesen gross und instalieren tute ich ja sogut wie selten was dadraus. Da habe ich noch Glück gehabt anscheinend. Aber wenn man leist das da Tausende Pakete betroffen sind und es es 100000 Pakete da gibt is das schon sehr heftig.

> [@Daemon](#):
>
> Aber, zum einen wie es @gosia bereits gesagt hat, und zum anderen, lasst euch überraschen was mein Paketmanager macht. 😉 Dauert aber noch etwas.

Da bin ich mal gespannt. Baust du eine Whiteliste rein? Aber wenn ja dann muste die am laufen halten da die Packer sich ja auch oft ändern neue dazukommen andre aussterben usw.

Das ist ja eben auch das Problem bei Aur da man am Ende keinen trauen kann und wenn da Pakete einfach so gekapert werden und von Hackern dann umgeschrieben werden das bekommt ja auch keiner so leicht mit.

Also leicht kann ich mir das net vorstellen was du da vorhast aber gutes gelingen.

---

<div class="post-metadata">

### Author: ![Daemon](https://manjaro-forum.de/user_avatar/manjaro-forum.de/daemon/32/157_2.png) [@Daemon](https://manjaro-forum.de/u/Daemon)
#### Post date: [9. August 2026 um 06:37 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109/7 "2026-08-09T06:37:48Z")

</div>

Ne, es geht um das was in der PKGBUILD drin steht usw. 😉

---

<div class="post-metadata">

### Author: ![Clemens](https://manjaro-forum.de/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@Clemens](https://manjaro-forum.de/u/Clemens)
#### Post date: [13. August 2026 um 13:24 UTC](https://manjaro-forum.de/t/naechster-angriff-auf-das-aur/109/8 "2026-08-13T13:24:04Z")

</div>

Auch ich verwende einige AUR Packages und habe sorgfältig die o.g. Links verfolgt und auch die zum ganzen Problem laufende Diskussion im AUR Forum. Zunächst die Links, sodass jeder ebenfalls sich leicht informieren kann:

[- Aur-general - lists.archlinux.org](https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/latest) = Die AUR Diskussionsliste

[WTAKO Network](https://wtako.net/services/aur-audit) = hier der AI-Anbieter, der freundlicher Weise gerade das gesamte AUR Repo mit seiner LLM scannt. Aktuell sind wohl noch 1.800 Packages zu scannen.

Aus der Diskussion im AUR-Forum habe ich den Tipp, zwei einfache Testprogramme im Terminal auszuführen:  
Zunächst pkg-audit herunter laden und isntallieren (stammt aber leider auch aus AUR 🙂 )  
Im Terminal ausführen: `pkg-audit`

Dann erhält man eine Liste sämtlicher (!) auf dem eigenen PC installierter Packages, für die ein hohes Risiko von seiten Arch angegeben ist. Es bezieht sich also nicht nur auf AUR. Maßgebend ist der Eintrag in: [https://security.archlinux.org](https://security.archlinux.org) Zuvor hatte ich noch sorgfältig alle nicht unbedingt nötigen AUR Packages deinstalliert und zwei AUR Packages durch flatpaks ersetzt. Das Erstaunliche am nun von pkg audit gezeigten problematischen Dingen ist für mich, dass allesamt aus den offiziellen Repos stammen und nicht aus AUR

djvulibre-3.5.30.1-1 is vulnerable to arbitrary code execution / no fix  
pam-1.7.2-2 is vulnerable to arbitrary filesystem access / no fix  
libxml2-2.15.3-1 is vulnerable to denial of service / no fix  
grub-2:2.14-1 is vulnerable to multiple issues / no fix  
systemd-261.2-1 is vulnerable to information disclosure / no fix  
coreutils-9.11-2 is vulnerable to information disclosure / no fix  
openjpeg2-2.5.4-1 is vulnerable to arbitrary code execution / No fix  
openssl-3.6.3-1 is vulnerable to arbitrary command execution / No fix  
libtiff-4.7.2-1 is vulnerable to denial of service / / No fix  
perl-5.42.2-1 is vulnerable to signature forgery / no fix  
linux612-6.12.101-1 is vulnerable to multiple issues / No fix  
linux618-6.18.42-1 is vulnerable to multiple issues / No fix  
libheif-1.23.1-1 is vulnerable to information disclosure / No fix  
openvpn-2.7.5-1 is vulnerable to information disclosure / No fix  
linux612-6.12.101-1 is vulnerable to multiple issues / No fix  
linux618-6.18.42-1 is vulnerable to multiple issues / No fix  
podofo-0.10.6-1 is vulnerable to multiple issues / No fix  
perl-5.42.2-1 is vulnerable to directory traversal / No fix  
cpio-2.15-3 is vulnerable to arbitrary command execution / No fix  
wget-1.25.0-6 is vulnerable to information disclosure / No fix  
giflib-6.1.3-2 is vulnerable to information disclosure / No fix  
xdg-utils-1.2.1-2 is vulnerable to information disclosure / No fix  
perl-5.42.2-1 is vulnerable to unknown / No fix  
openssl-3.6.3-1 is vulnerable to certificate verification bypass / No fix  
audacity-1:3.7.8-2 is vulnerable to information disclosure / No fix  
lua51-5.1.5-13 is vulnerable to denial of service / No fix  
linux612-6.12.101-1 is vulnerable to insufficient validation / No fix  
linux618-6.18.42-1 is vulnerable to insufficient validation / No fix  
linux612-6.12.101-1 is vulnerable to privilege escalation / – upgrade to  
linux618-6.18.42-1 is vulnerable to privilege escalation / – upgrade to  
nodejs-lts-jod-22.23.2-1 is vulnerable to denial of service / – upgrade to

Naja, da wird mir schon irgendwie anders, wenn ich sehe, wie viele problematische Komponenten auf meinem PC sind. Allerdings sind vermutlich die meisten Sicherheitslücken nur ausnutzbar, wenn Fremde meinen PC in die Finger bekommen oder wenn ich die Installation auf einem Server betreiben würde.

Den Tipp, mir die PKGBUILD anzuschauen, sehe ich auch als zu komplex an, denn damit kenne ich mich nicht aus. Ich könnte nicht beurteilen, was darin evtl. problematisch sein könnte.

Es gibt auch den Tipp, dass man sich einen chroot-Ordner anlegen sollte, in den man dann ein Package erst mal hinein entpackt und dann… ja was dann? – Ist mir ebenfalls zu komplex.

Die von mir verwendeten AUR Packages sind anscheinend alle OK. Allerdings habe ich in Pamac sicherheitshalber Updates für AUR vorerst deaktiviert.

Aus AUR verwende ich (falls es jemanden interessiert):  
backrest (Sicherung von Anwendungsdaten)  
Balena-etcher und electron 37  
cnjifilter2 (für Canon-Drucker)  
iscan + iscan-plugin-perfection-v330 + libstdc++5 + gtk2 (für meine Scanner)  
krokiet (spürt doppelte Dateien auf zig Festplatten gleichzeitig auf)  
hibiscus + jameica (HBCI-Homebanking)  
opentabletdriver  
simplescreenrecorder  
samsung-unified-driver

Erfreulich finde ich, wie viele Menschen sich gerade im AUR-Forum Gedanken machen, wie man das ganze AUR-Konzept nachhaltig repariert im Sinne von Sicherheit. Die wichtigsten Vorschläge, die mir aufgefallen sind:

Alle Entwickler müssen ihre Packages PGP signieren.  
Entwickler, die bereits seit z.B. 5 Jahren ihre Pakete dort haben und pflegen, erhalten eine Markierung als „schon eher zuverlässig“  
Eine automatische Prüfroutine soll die Package-Build-Dateien analysieren, damit im Build nichts Schräges nachgeladen wird.  
Das ARCH-Team sollte etliche Packages aus dem AUR in das Extra-Repo übernehmen, wo strenger geprüft wird. Manche User brauchen dann kein AUR mehr.  
Langfristig wäre eine eigene OpenSource AI denkbar, die den Code analysiert und frei gibt oder sperrt.

Ach ja: Da ich vor dem letzten großen Update vom 29. Juli noch ein echtes Backup mit RescueZilla gerstellt hatte, könnte ich – selbst, wenn ich jetzt ein faules Paket installiert hätte – schnell wieder auf ein sauberes System zurück gehen.
