Arch Linux-gebruikerspackages zijn tijdelijk afgesloten vanwege malwareaanval

De ontwikkelaars achter Arch Linux hebben de Arch Linux User Repository tijdelijk offline gehaald vanwege een grootschalige malwareaanval. Het is de tweede aanval in korte tijd. De ontwikkelaars geven op dit moment nog weinig informatie over de aanval.

Arch-ontwikkelaar Robin 'Antiz' Candau schrijft in een korte mailinglijst dat package adoption in de AUR tijdelijk is uitgeschakeld. Dat doet het team vanwege 'een toestroom aan malafide package adoptions en daaropvolgende commits via de AUR'.

Wat is de AUR?

Arch Linux heeft een eigen zogenaamde User Repository, de AUR. Daarin staan packages die bijvoorbeeld niet meer actief worden onderhouden of die maintainers zelf hebben vrijgegeven aan de community. Ontwikkelaars kunnen het beheer van zo'n package overnemen. Dat proces heet 'package adoption'.

De nieuwe maintainer moet onder andere bouwen vanaf de pkgbuild. Dat is een Bash-script waarin instructies staan voor het installeren van Arch-packages. In Arch bevat een pkgbuild vaak niet de package zelf, maar een downloadlink naar een externe server waarvandaan de package wordt gedownload.

Dat maakt een aanval op de AUR aantrekkelijk voor hackers. Eindgebruikers moeten namelijk in principe de pkgbuild controleren voordat ze het script uitvoeren, maar in de praktijk doen veel gebruikers dat niet. Als een aanvaller een package in de AUR heeft 'geadopteerd' en er kwaad mee wil doen, kan die pkgbuilds aanpassen en ervoor zorgen dat gebruikers iets binnenhalen van een geïnfecteerde server. Dat lijkt nu te gebeuren, al zeggen de Arch-ontwikkelaars niet wat er precies aan de hand is.

Tweede aanval in korte tijd

Het is de tweede keer in korte tijd dat Arch wordt aangevallen, btw. Dat gebeurde in juni ook al. Toen sloten de ontwikkelaars de registratie van nieuwe AUR-accounts tijdelijk vanwege een malwarecampagne via geïnfecteerde packages. Aanvallers wisten toen zeker 1500 packages te infecteren.

Reacties (11)

[ray0755]

Er wordt altijd aangeraden om de PKGBUILD te controleren, je ziet waar de sourcecode vandaan wordt gehaald, maar of die code veilig is kan je niet zien.

[The Zep Man]

Soms zijn er gezonde indicaties. Bijvoorbeeld: je ziet in een PKGBUILD diff dat alleen het versienummer is opgehoogd en dat de bronbestanden van een officiële locatie gehaald worden. Dat is vaak een goed teken. Als de originele bron gecompromitteerd is, dan heeft het niet enkel effect op AUR.

Dan nog blijft AUR een risico voor het ongetrainde oog en voor degenen die AUR helpers gebruiken met een "--noconfirm"-achtige parameter.

Het onderliggende probleem is dat iedereen (onder een pseudoniem) AUR packages die niet meer onderhouden worden eerst kan oormerken als orphaned wanneer de ontwikkelaar niet reageert. Daarna wordt een aanvraag om de ontwikkelaar van het package te worden automatisch goedgekeurd. Je krijgt dus ook problemen als een package wel onderhouden wordt maar de enige ontwikkelaar even een tijdje niet beschikbaar is (bijvoorbeeld op een lange vakantie).

[Reactie gewijzigd door The Zep Man op 31 juli 2026 21:27]

[_JGC_]

Dat "automatisch" is niet geheel waar. Als iemand 2 weken na het flaggen niet reageert kan je een verzoek naar de mailinglist sturen en kan een package maintainer het pakket in orphan status zetten.

pas als een pakket voor 180 dagen flagged is gaat een orphan request volledig automatisch.

Ik vind het een dom systeem overigens. Toen ik nog package maintainer was had ik >600 pakketjes in beheer. Onder andere GNOME en X.org en alles wat daarbij hoort. Hoe vaak ik wel niet flags kreeg voor development versies van GNOME... en dan kon je unflag doen maar de volgende dag stond ie er weer. Op een gegeven moment heb je wel wat beters te doen dan flags uitzetten.

Ik heb overigens ook wel zooi uit de repos verwijderd wat vervolgens in AUR gezet werd voor die ene gebruiker die nog zin had om libgnomeprintui te gebruiken bijvoorbeeld. Dan werd zo'n pakket door iemand overgenomen en compleet verbouwd zonder dat het iets toevoegde aan het eindresultaat. Puur voor de status "kijk mij eens hoeveel pakketjes ik heb".

[Bierkameel]

Ik draai al een hele tijd CachyOS en heb de AUR meteen disabled, ik doe niks geks op mn laptop dus met standaard packages en Flatpaks red ik me prima

[kuurtjes]

Het is de derde aanval.

Na de eerste aanval was er een paar dagen later een tweede.

(Dat heb ik toen trouwens getipt naar Tweakers maar dat was genegeerd.)

[fedaykin]

Ik raad aan om eerst in de Flatpak/Flathub packages te kijken voordat je naar de AUR uitwijkt. De AUR is geniaal maar ze moeten dit echt even uit vinden, anders is het niet echt veilig te gebruiken voor dingen serieuzer dan wat gamen.

Mochten flatpaks nieuw voor je zijn, denk er om dat er wel wat bij komt kijken met deze sandboxed applicaties - je merkt het bijvoorbeeld bij het selecteren van bestanden van het filesysteem of drag & drop.

Dat kan je beheren met de flathub applicatie "Flatseal" - alhoewel de beschrijvingen nogal technisch zijn af en toe. Gelukkig hebben we AI vriendjes die alles voor ons uitleggen tegenwoordig.

[ghangster]

Is er een manier om te controleren of je hierdoor geraakt bent? Ik heb eergisteren nog packages vanaf de AUR geïnstalleerd, maar ik heb de PKGBUILD files zelf al weer verwijderd.

[psalden]

Volgens mij gaat "package adoption" erom dat oude pakketten die niet meer onderhouden worden, overgenomen kunnen worden door een nieuwe "maintainer". Dat was ook het mechanisme dat hier misbruikt werd. Het klinkt mij dan ook niet alsof ze de hele AUR offline hebben gehaald.

edit:
@The Zep Man haalt het ook al aan, zie ik

[Reactie gewijzigd door psalden op 31 juli 2026 21:49]

[HollowGamer]

Je kunt een 'package adopten' als die geen maintainer meer heeft. Vroeger was dat geniaal, want dan stond er wel iemand anders op en er was een meer algemene community. Het was ook allemaal wat kleiner, door CachyOS en andere, is de AUR ontzettend gegroeid in aantal.

Er zijn best veel vaste ontwikkelaars weg bij Arch Linux, en als je ouder wordt - ga je misschien toch kijken naar een Fedora of zelfs een Debian. Ik zit bijvoorbeeld nu op Fedora Atomic varianten, want ik wil geen gezeur meer met verschillende packages en ga je gewoon één of meerdere images terug bij issues.

Dus ik denk dat het een combinatie is van beide. Het is ook heel eenvoudig, bij de meeste distros moet je als ontwikkelaar door allemaal build systems.

[Reactie gewijzigd door HollowGamer op 31 juli 2026 22:07]

[Cambionn]

@TijsZonderH als ik dit lees dan klopt de titel

Arch Linux-gebruikerspackages zijn tijdelijk afgesloten vanwege malwareaanval

en de zin

De ontwikkelaars achter Arch Linux hebben de Arch Linux User Repository tijdelijk offline gehaald

niet. De AUR is helemaal niet offline, enkel de optie tot package adoption is uitgeschakkelt. De AUR offline halen zou wel echt véél ingrijpender zijn. Naast dat men dan geen nieuwe packages via de AUR zelf binnen kan halen, zouden veel mensen ook updates missen (gezien veel die laten checken via de AUR en men over het algemeen niet handmatig de software zelf checkt voor updates). Schrok dan ook toen ik de titel las, maar daar is gelukkig geen sprake van.

aur.archlinux.org lijkt vooralsnog online, en de PKGBUILDs die daarop staan beschikbaar.

[Reactie gewijzigd door Cambionn op 31 juli 2026 21:49]

[HollowGamer]

Ik wil toch even aangeven dat een Flatpak. appimage of Snap - ook vatbaar zijn voor precies dezelfde aanvallen. Dat zijn zeker betere alternatieven t.o.v. de AUR, maar 'heilig' ook niet.

Voor Flatpaks weet ik uit ervaring (als je package eenmaal is geaccepteerd), daarna vrijwel geen controles meer plaatsvinden. Het is beter geregeld (er is een algemene builder) en je moet toch wat hoepels heen, maar je kan echt wel doen wat je wilt. Ik weet dat, omdat ik ooit 3x iets had gepushed dat helemaal niet werkte, maar wel al werd verspreid aan gebruikers omdat het succesvol bouwt (had geen slechte bedoelingen, maar toch).

Snaps hebben hier ook last van gehad, en daar is nog een minder streng systeem dan Flatpak en misschien zelfs AUR. Appimages worden gemaakt door de vendor (dacht ik - corrigeer mij a.u.b.), maar ook die kunnen malware bevatten - en zijn mogelijk nog meer vatbaar, aangezien er geen centraal beheer systeem is (er bestaan oplossing voor).

Daarnaast heb je nog een heel ander probleem: deze bouwen allemaal vanaf de source. Als de bron is besmet, dan heb je precies hetzelfde probleem en wellicht nog groter. Bij de AUR iets dat specifiek iets dat een eindgebruiker moet inschakelen en installeren, een Flatpak werkt als een centrale appstore zoals Android/Apple Store.

Wat is dan de oplossing? Ik vrees een antimalware module, iets dat macOS bijvoorbeeld ook heeft. Misschien gaat er zelfs een AI-agent draaien die je moet gaan beschermen tegen malware die vecht tegen een AI-bot.. we gaan het zien.

[Reactie gewijzigd door HollowGamer op 31 juli 2026 21:58]