We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository.
We are actively working to track down existing malicious commits and attempting to prevent additional malicious commits from being pushed. While this is happening, and while we work to create a more permanent solution, users may see issues with the following:
Creating new accounts on the AUR
Pushing package updates
Adopting or creating new packages
We continue to encourage all users of AUR packages to review all PKGBUILD and install script changes when updating, especially during this time. If you notice suspicious commits to a package that you use, please reach out to Arch staff via the aur-general mailing list with more information.
Another script is here that also checks NPM & Bun caches. However, the list hasnât been updated yet to include all ~ 1,500 packages linked above in the HedgeDoc like that gist does.
EDIT: Itâs been updated now and checks 1,619 packages.
Would it be a good idea to extend Manjaroâs âhold backâ approach to the Pamac GUI for AUR packages? For example, add a setting in Pamac: Delay AUR updates by X days. If an AUR commit is < X days old, Pamac simply wouldnât show the update.
To keep power users happy, there could be a toggle in the settings: Show immediate AUR updates (Advanced). This way, regular users get a more stable experience that matches the rest of Manjaro, while advanced users can still live on the edge.
In all seriousness, using the AUR is a userâs responsibility. Pamac just provides a convenient way to use it.
Warning
AUR packages are user-produced content. These PKGBUILD s are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
Thanks very much for this. I did not realize how widespread this was until I came across a post on X. Yochanan and the rest of the dev team cudos to you all!!
Edit-- Curious if any of the clamAV defs have been updated to look for any of this stuff? Thanks.
Teo & Yochanan thanks for the script checker posts. Ran it on one of my installs and came out clean. I use AUR primarily for amateur radio programs.
From a technicality standpoint would it be possible?
The AUR is one of Archâs strongest selling points and coupled with Manjaro being the more, letâs call it, beginner Arch friendly option; it seems like it would be an easy at first glance limited downside option to mitigate issues like this.
It is not an option at all. AUR is officially not supported by manjaro. There is a big fat warning about this and one of the 2 main reasons is exactly the content there is user produced and might be incompatible or malicious. If someone has enabled aur, he should know what he is doing.
No amount of âsafety netsâ solving nonexistent problem replaces common sense. For users wanting a kitchen appliance, there is windows.
p.s. I will illustrate your point: you buy a car. You start modifying it and decide to remove 2 of the 5 bolts on each wheel âto save weightâ. Driving on the motorway, a wheel falls off and you crash. You survive and come screaming to the car manufacturer forum demanding an audible alarm when you decide to mount a wheel with 3 instead of the 5 designated bolts.
It is just ⌠ridiculous.
That is one toxic approach. Manjaro is one of the very few distros where terminal access or usage is not required as excellent custom UIs have been created to eliminate the need. I can only think of one instance in the past year where I was forced to use terminal and that was due to a hiccup with Nvidia being Nvidia. It really shows the immense amount of positive work already put into the experience. It is the most appliance OS adjacent Arch variant.
The pamac GUI already contains support for AUR browsing, installing, and updating Iâm guessing based on community feedback. The stance itâs ânot supportedâ is factually incorrect. itâs the best suited GUI to put some even small level of measure in to prevent this scenario. If my math is correct, identification and corrective measures rolled out upstream in what looks like less than 12-24 hrs. An update delay of two days could and likely would have prevented infection of a Manjaro install and already falls in line with the stability mindset driving Manjaro.
The main fear, I think, is that we worry now not so much about vetting a new installation, but that some quiet backend will be updated.
So the big test will come when running an update, when faced with several PKGBUILDS,
Thereâs a thread over at CachyOS about ClamAV⌠I fail to see how ClamAV can possibly look at this threat, itâs like building a metal detector to find yellow snow amongst the white snow.
We must stop thinking about AUR as being a âselling pointâ and appreciate what it isâŚ
Freedom.
Manjaro remains completely unaffected by AUR attacks.
There are 2 binary files where signature based detection might work but 90% is not. Yara rules might be more effective.
For the ordinary Joe the 2 checking scripts above and a little more closely inspecting the pkbuilds should be enough.
If the scripts tell you you have an affected package in one of the links there are many methods for examination.
You will still be able to build alien packages using command line tools like makepkg, yay, paru, pamac and many other.
AUR is not a selling point - it is unsupported.
Yes Manjaro provides the tools to build from AUR - that does not implicate official support of the resulting package(s).
That is correct - antivirus is wetting yourself on cold winterday - it warms for a few seconds then it gets worse.
final thoughts
Manjaro is about simplicity and freedom - so you have the freedom to build custom packages using scripts from AUR - @Benâs comment is spot on - freedom
For years we have actively worked to educate users about AUR, the use and risks involved.
Have you considered that every distro or product generally have a target audience and maybe those who need tying their hands to not hurt themselves are not in this target group?
In case another metaphor is needed:
In our kingdom we prefer to have citizens that can read the sign on the crossroad âcaution: dragons aheadâ and deliberately and consciously choose to go back to safety OR draw thier swords and choose the dragon path, and then bear responsibility for the outcome.
What you suggest is to block the road altogether - it is just not our concept.
I suggest we go back to the practical side of things - news on the topic, detection tools, etc., instead of turning this into pro and contra for aur.
Otherwise closing the topic for the general public might be needed and only mods will post.
Thank you for the discussion. I will open another thread after researching and upload a patch to pamac to enable time based delays of AUR updates following the spirit of delayed package repository.
I need someone who can understand this to look at my outputâŚ
Context I copied the script from that thread that c4software commented 8 hours ago
The same source, but with logs scanning to see if the package was previously installed
It flagged libuiohook package from January 10, 2026, which is probably safe as the attacks happened this week onlyâŚ
But to be sure, take a look at these and let me know if I should be concerned.
And yes, I installed it myself on my own risk and all
The Script Output
⯠./test.sh
Fetching infected package list from https://md.archlinux.org/s/SxbqukK6IA...
Checking for infected AUR packages (1577 total)...
Campaign window: 2026-01-01 through 2026-06-12
Checking currently installed foreign packages...
Clean: no currently installed known infected package has an install date in the campaign window.
Checking historical pacman logs...
WARNING: 1 historical pacman log event(s) matched:
- libuiohook (installed on 2026-01-10) :: [2026-01-10T16:26:53+0530] [ALPM] installed libuiohook (1.2.2-2)
WARNING: matches were found. Review the package build files/cache and consider incident-response steps.
Pamac Info
⯠pamac info libuiohook
Name : libuiohook
Version : 1.2.2-2
Description : A multi-platform C library to provide global input/ouput hooking from userland.
URL : https://github.com/kwhat/libuiohook
Licences : GPL3
Repository : AUR
Groups : --
Depends On : libxt libxtst libxinerama libxkbcommon-x11
Optional Dependencies : --
Make Dependencies : cmake libxkbfile
Check Dependencies : --
Provides : --
Replaces : --
Conflicts With : --
Maintainer : brunoharasimiuk
First Submitted : Mon 28 Sep 2015 02:22:14 IST
Last Modified : Fri 12 Jun 2026 18:49:06 IST
Votes : 7
Out of Date : --
I have not updated AUR in last 3 days, if I remember correctly, because I was busy with some work, hence didnât visit forum and notice these alert posts eitherâŚ
I think you misunderstood. Pamac is supported, as is the ability for pamac to use the AUR. But AUR packages are not supported and are the users responsibility.
The script tells you what to do. It found no packages within the campaign window (the known timeframe for suspect packages). But it did find one package outside that timeframe and you should inspect the package build files for any trace of this exploit.
