Firefox-patch-bin, librewolf-fix-bin AUR packages contain malware
86 comments
·July 18, 2025jabjq
gpm
It says what the malware does, it's a remote access toolkit... It gives control of your machine to the malware operator.
The malware operator could have done anything with that access... There's no way for the maintainers to know what was done on any given infected machine.
sp0rk
Announcements like this typically contain information that will help users identify if they were compromised, such as the name of files that are dropped or modified when the malware is initialized, startup entry names, etc. Obviously the person with remote access can get in and manually start doing things on individual machines, but that doesn't mean there aren't indicators present from the programmatic actions the malware took before that point or on machines that weren't manually accessed.
akazantsev
Expecting a complete malware analysis from maintainers is a tad too much. Their goal is to notify users as soon as possible, even if no other information about the malware is available.
Also, an attacker may leave no traces by simply dumping the payload to /tmp.
gpm
In addition to the point about "not being expected to do a full malware analysis"...
Assuming the malware doesn't clean up after itself, `pacman -Q firefox-patch-bin librewolf-fix-bin zen-browser-patched-bin` would tell you if they are installed... but if it did clean up after itself... how are the maintainers supposed to know what steps were taken to clean up given that it's a rat that could be running different steps on different computers...
Shellban
This is really scary for those who manage multiple things. I'm considering running a factory reset on everything from my router to my Steam Deck and remote server.
gpm
Uh... did you install these AUR packages? It seems quite unlikely you installed these on either a router or a steam deck...
That said, if you did, yeah being hacked is scary and I feel for you.
rwmj
Did you install one of those packages? If yes, nuke from orbit.
More interesting questions are:
- Who was the uploader? A packager? For how long?
- Do they maintain other packages?
- What steps can be taken to ensure that a similar problem doesn't happen in future?
gpm
Per the Wayback Machine the username used was danikpapas. As far as Google and duckduckgo know these are the only packages theat username ever uploaded. Considering the purpose was crime it's likely that that username was "stolen" and the person using it on other sites wasn't the same as the one doing this...
The AUR is arch's repository of untrusted user maintained read-the-source-before-installing packages. There's really not much that can be done to prevent similar issues in the future... because the whole purpose of the AUR is to allow random people to upload packages.
Arch doesn't ship with any way to install AUR packages other than downloading the tarball and building them locally. Tools for installing the packages usually force you to read the PKGBUILD that controls the build process (including getting sources) before letting you build the packages. I.e. the reasonable steps have already been taken.
Edit: firefox-patch-bin was first submitted to the AUR 2025-07-16 21:33 (UTC), so less than two days before removal.
diggan
They are/were AUR packages it seems, anyone can spend 2 minutes and upload essentially anything there, like npm and similar. It's not necessarily a "maintainer" per se, as like the people who manage the packages in the proper Arch repositories, but entirely separate.
With that comes the same warning as downloading random stuff from the internet and executing it, you need to carefully review everything before running/installing it, as you're basically doing a fancy version of "curl | bash" when using the AUR.
Ancapistani
It's ArchLinux. The user is expected to do their own due diligence.
johnisgood
And these packages are from AUR, they are not officially supported. AUR means Arch User Repository. You cannot even use Arch Linux's official package manager to install AUR packages either, you need an AUR helper ("makepkg" is sufficient though but it has limitations). These AUR helpers are not even official packages either. Not even yay: https://archlinux.org/packages/?sort=&q=yay.
WD-42
As Arch seemingly explodes in popularity I’m afraid we’ll start seeing more of this.
johnisgood
FWIW this is AUR. These packages are not officially supported. AUR = Arch User Repository.
nilamo
Plenty of package managers (such as `yay`) install from AUR by default.
bee_rider
On one hand, the distro developers can’t really prevent people from, say, hitting their computers with a sledgehammer or something. So to some extent, the users have to be trusted.
But, maybe it would be best not to have “yay” available. Using something like AUR without reading the package build files is… pretty bad, right? And it is bad for the community, because if there is a convention of doing that sort of thing, it makes the AUR a good target for attacking.
johnisgood
yay is a package manager that has been made for AUR. yay is not the official package manager for Arch Linux, pacman is, and it does not support AUR. yay is not installed on Arch Linux by default, its official package manager, pacman, is. AUR is for unofficial 3rd party packages, i.e. "use at your own risk". It has always been the case.
heavyset_go
Nearly all distros have this problem when it comes to packaging and distributing 3rd party software.
Even if you're using an immutable distro, your KDE Plasma session can get hijacked if you simply use the built in wizard to install 3rd party desktop widgets, which is a right-click + single-click away on any Plasma destkop.
yuvadam
Is arch exploding in popularity? Because of Omarchy or something else?
eddythompson80
The current iteration of SteamOS (the one shipped on Steam Deck) is Arch based. So a lot of non-linux users got exposed to it as their first linux distro. Especially with all the emulation guides and other random guides for doing "advanced" stuff to your Steam Deck by dropping in the Arch-ish desktop.
Also anyone who wants to try "Gaming on Linux" needs bleeding edge kernel which is Arch's default setup compared to other distros.
ementally
CachyOS (Arch based distro), no.1 on https://distrowatch.com/
LeoPanthera
This is a slight aside, but CachyOS is a great example of the failure of Wikipedia politics.
The "CachyOS" page was deleted[1], and replaced with a redirect to the Arch Linux page. But CachyOS is not mentioned anywhere on that page, nor on the "List of Linux distributions § Arch Linux-based" page.
[1]: https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...
Hackbraten
That’s just a ranking of subpage hits per day. Not only is that easily gamed, it also says very little about how popular an OS really is.
johnisgood
> Blazingly Fast & Customizable Linux distribution
I love Arch Linux, but please...
(Arch Linux is already "fast" (depends on what you install for your DE, if any) and customizable.)
Phelinofist
I think I saw posts on Reddit with XQC saying Arch is the best. I mean it is. And I use Arch btw.
kwk1
An evaluation of what's best really depends on how one weighs different tradeoffs. For example, Debian and Arch are basically polar opposites in terms of two questions:
1) do you want an intermediary between you and the upstream? for example, to patch out telemetry
2) is it important that what you're using continues to work the same way so you can focus on your actual work?
No answer to either is consequence-free, e.g. for 1), see the Debian SSH patch event, or for 2), if the answer is "it doesn't work", then that kinda forces one's hand.
null
ASalazarMX
The only thing I've seen Arch exploding in popularity has been memes. It's a fun distro for hobbyists, but too inconvenient as a daily driver.
bee_rider
It this recent? I thought “I use arch btw” was more of a thing… 5 or so years ago.
I switched away from Arch (to Ubuntu) as a sort of side effect of switching computers a couple years ago (desktop->laptop, though Ubuntu would “bring the batteries along” more conveniently). Ubuntu is fine I guess, but I really miss the stability of rolling release and the user-friendliness of not having too many built in programs.
mariusor
I can't imagine what kind of a problem I would personally have to encounter to make me utter such a sweeping generalization with this much confidence. :)
At least this guy has been using it as a daily driver (at home and at work) for at least fifteen years.
andrelaszlo
I've been using Arch as my daily driver for over fifteen years. I'm not a fanatic, it just works really well.
null
null
urda
If Arch is too "inconvenient" as a daily driver, you might find yourself more at "home" on a Windows install instead.
zaruvi
Can you elaborate why you think this?
Personally I've been running Arch on my work machine for a few years now with very few issues. I'm not even very consistent with updates, and probably run them about once every 3 weeks on average. I have only had to manually intervene on a handful of occasions.
I like it a lot because everything is always up-to-date. I don't face any issues with unsupported versions for tools like I have with Debian in the past. The rolling release model also saves me the pain of doing a "hard" OS upgrade, which often come with issues.
mzajc
Any clue what these packages were 'supposed' to do or why somebody might have installed them? Their PKGBUILD descriptions are copies of the respective browsers', not explaining the -patched part.
Vortigaunt
Looks like someone archived the page of firefox-patch-bin[1] and the only thing that stands out about the package itself is that it's supposedly the "Extended Support Release." Besides that it looks like it's depended on by 183 other packages/metapackages. While that seems more interesting, there isn't an archive of all of those packages.
[1]https://web.archive.org/web/20250718140411/https://aur.archl...
Tharre
These 183 packages depend on "firefox", and the malicious firefox-patch-bin had a provides=( 'firefox' ) clause in it. That's why they all get listed on that page. The provides clause is useful when you have multiple packages for the same thing with different names, for example -bin and -git versions.
mzajc
I saw the ESR part - I assumed the author (mistakenly?) copied firefox-esr's description. As for the dependents, it seems the malware package provided `firefox`, meaning all dependencies on `firefox` can instead be fulfilled by `firefox-patch-bin`. Perhaps the idea was to fool package managers into showing it as one of the alternatives.
null
null
Jorchime
I wondered about the same thing. Not an answer, but my guess would be that it's just a new package and they hoped someone picked it up by accident? In that case, it was patched with malware :)
Hackbraten
They (or someone in cahoots with them) made at least one attempt [0] to lure readers of the Arch Linux subreddit to the malicious PKGBUILD.
IIRC, the post was just a single paragraph, praising how they “found” the zen-browser-patched-bin package on the AUR and how much it helped them.
[0]: https://www.reddit.com/r/archlinux/comments/1m30py8/aur_is_s...
heavyset_go
Anyone have a copy of it that I can poke at in a virtual machine?
techjamie
You might be able to poke at the PKGBUILD on the wayback machine and see if the original sources work.
mzajc
The PKGBUILDs are not archived, but the package page does helpfully list its sources, one of which is https://github.com/danikpapas/zenbrowser-patch.git (same for all three packages). I would assume that's where the malware is, but I couldn't find an archive. Does https://www.gharchive.org/ keep this sort of data?
ETA: According to a Reddit post linked elsewhere in this thread, the payload was a binary file downloaded by a python script in the repository. It has been uploaded to VirusTotal, but downloading requires a premium subscription according to their docs: https://www.virustotal.com/gui/file/d9f0df8da6d66aaae024bdca...
lilly-lizard
it should be noted that these are different from the popular librewolf-bin (513 votes) and zen-browser-bin (176). with this in mind it's cool that these got identified only 2 days after being uploaded. I wonder if the reporter actually intended to install it or just reads the PKGBUILDS of new packages to be a good samaritan...
Shellban
I only just noticed the difference myself. That was a scare!
lorenzohess
Could there be programmatic ways to help users characterize the safety of the AUR packages they install? Perhaps a program that prints all URLs in the PKGBUILD and offers the option for the user to open them in the browser? Or which automatically shows a diff if a PKGBUILD is updated? Highlighting changes would make it easier for the user to determine if he should spend time exploring those changes for malware.
One could go even further and list all new commits, making it super easy for the user to check them. Maybe even integrate an LLM to help? Maybe commits from non long-time contributors could be flagged?
There has to be a way to help users programmatically review updates to their AUR packages. Even if most of them won't spend the time.
WD-42
This is exactly what many of the AUR helpers like yay and paru already do - ask you to review the pkgbuild diffs before installing or updating.
Tharre
PKGBUILDs are just bash scripts following a certain function and variable naming convention. Even if you could somehow parse it safely and extract the URLs of the 'source' array, any attacker can just simply put an obfuscated version of the malware URL into the build() function and download it there.
AUR clients already show you the diff if you update a package, but note that this were completely new packages anyway, uploaded 2 days ago, so that doesn't really apply here.
LLMs are useless for reviewing if something is malicious, their false-positive rates would be way to high. And even ignoring that you'd have to hide the LLMs code from the attacker or he can just check if his package is detected as malicious and modify it until it isn't. Not something open source projects are keen on doing.
diggan
> AUR clients already show you the diff if you update a package, but note that this were completely new packages anyway, uploaded 2 days ago, so that doesn't really apply here.
The program I use for AUR (Rua) still displays exactly what you're about to build (as a git diff), before you build it, even if it's the first time/release. I'd assume all the other "AUR managers" would work the same way?
Tharre
They should all show you the PKGBUILD before building, yes.
kiranet
LLMs are also really easy to trick, as we saw in the GMail white-on-white text PoC just a few days ago...
IceDragon200
As one commentor pointed out, in Arch it's the user's responsibility to review any AUR packages BEFORE installing them (and I say this as an Arch user and AUR package maintainer).
This particular issue is with a binary (i.e. pre-built) package, normally in Arch it's expected from an AUR package that you will build it yourself and most if not all packagers prompt you to review and or edit the PKGBUILD before it does anything.
Basically you could spot something suspicious in a source package, not so much in a binary package.
porridgeraisin
I like that idea of printing the URLs it downloads. Will help screen quickly if it's doing something malicious.
christophilus
Man. I am on Fedora, but I do have a handful of copr packages installed. (Copr is the Fedora an analogue of the AUR.)
This makes me nervous. I guess it’s time to do some audits.
defraudbah
i installed a lot of cra* from aur in the past, wouldn't be surprised if i got a malware somewhere. Strange thing, I don't think open snitch would even help in such situation..
and official repo does not have enough packages to run arch :\ I don't want to go back to ubuntu
Barrin92
There's always been this security theater of people recommending arch because they "don't trust the companies" or Canonical or what have you but frankly I'm surprised this hasn't happened sooner. Well or maybe it has and we don't know.
Running random binaries on your computer uploaded by some anonymous dude has to be the equivalent of buying heart medicine on craigslist. And because Arch is so barebones to begin with the AUR is very popular, you see a lot of arch users using it.
h4ck_th3_pl4n3t
Arch bugfix time is usually within 24 hours.
Not a single enterprise distro even reacts within that timeframe. OVAL advisories are weeks, sometimes months later.
As long as you don't have a virtualization approach similar to QubesOS, any linux distro will not fix this problem. Because that's not how separation of concerns works in the POSIX system. You need to have separate users for each and every program to isolate them, and that is practically unfeasible.
jchoksi
AUR packages are user-produced content i.e. packages built on their own machines.
They have to be installed via "pacman -U package_file"
Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package.
VirusTotal's API is free.
- https://docs.virustotal.com/docs/api-scripts-and-client-libr... - https://docs.virustotal.com/docs/please-give-me-an-api-key - https://docs.virustotal.com/docs/consumption-quotas-handled
Since it is end users who are doing the upload and virus scan check, there won't be a consumption quota issue with VirusToal.
Lastly, "pacman -U" should flag failed VirusTotal scans to Arch Security.
Arch's pacman and Flathub's flatpak package managers should be the last line of defence when installing untrusted packages by end users.
Tharre
First of all, this is incorrect, the checking would have to happen _before_ even building the package since malware is already being executed at that point.
But more importantly this is a terrible idea in regards to privacy/infosec. I do not want packages I build and install myself to be uploaded to a 3rd party website.
And for what benefit? 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR.
jchoksi
> malware is already being executed at that point
To ensure reproducible / clean builds, I thought makepkg would always be run in a sandbox/chroot environment. The damage done would be localised to that sandbox.
> this is a terrible idea in regards to privacy/infosec.
Ok. Devs could setup an option to pacman -U which allows it to bypass VT for privacy sensitive people. This just puts the onus on you to not ensure you aren't installing malware. The default Arch user should still be protected while allowing for your privacy needs.
> 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR
Its too late then. People are already affected.
tojumpship
> Devs could setup an option to pacman -U which allows it to bypass VT
Goes against the very nature of the distro. I very rarely see assumed defaults in Arch, and they are almost always opt-in. Mind you, you need community provided helpers to automate AUR building, its that barebones and I'm sure there are people who manually build / use custom scripts to build every package.
Tharre
> To ensure reproducible / clean builds, I thought makepkg would always be run in a sandbox/chroot environment. The damage done would be localised to that sandbox.
makepkg runs in a fakeroot environment, but this is not a security barrier. There is also support for building inside systemd containers, offering at least limited security, but most AUR helpers don't use that yet.
> Ok. Devs could setup an option to pacman -U which allows it to bypass VT for privacy sensitive people. This just puts the onus on you to not ensure you aren't installing malware. The default Arch user should still be protected while allowing for your privacy needs.
You mistake the target group of Arch Linux. Users are expected to read the documentation and to know what they're doing. Protecting users from themselves at the expense of those who know what they're doing is not what Arch is about.
> Its too late then. People are already affected.
That doesn't make sense, it's too late for people if new malware isn't detected by VirusTotal as well.
akerl_
It seems like you may not be familiar with Arch?
No, makepkg doesn’t run in a sandbox. The system tries to stop you from running it as root, but otherwise all validation of the trustworthiness of the pkgbuild and any sandboxing of the build process are left up to the user. This is part of why pacman, the 1st party package manager, does not fetch from the AUR.
Likewise, it would be generally against the Arch ethos to have the default behavior of the package manager interact with a 3rd party service. If a user wants that action, they’d need to perform it themselves.
akerl_
Is this accurate? My understanding is that the AUR does not host binary packages. It hosts pkgbuild files, which contain config and scripts that a user has to build on their own machine in order to install. The malicious code here is fetched as part of those scripts.
johnisgood
No, it is NOT accurate.
Pacman cannot be used to download, compile, or install AUR packages. You need the PKGBUILD file and use "makepkg -si" at the very least. If you want AUR packages, you'd install a package manager (in this context referred to as AUR helper) like "yay" that supports both official and unofficial (i.e. AUR) packages. FWIW AUR helpers are not even official packages, not even "yay" which is a popular one. You need to go out of your way to install "yay" (although it is one command away before, i.e. very easy).
TL;DR: Pacman does not download, compile, or install packages from the AUR, nor does it resolve their dependencies. "makepkg -si" builds and installs a package based on the PKGBUILD file, or use an AUR helper that overcomes the limitations of "makepkg". AUR helpers make it easy to install AUR (i.e. unofficial) packages.
akerl_
And even with 3rd party package managers like yay, the package manager is pulling the pkgbuild definition locally, running makepkg for you, and then installing that.
diggan
> Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package.
AFAIK, VirusTotal only flags known malware/viruses, any new/"looks-to-be-new" stuff wouldn't be flagged until they've picked it up, and once someone would have picked it up, it should be removed from the AUR anyways. So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless.
jchoksi
> So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless.
This is where your and my intentions differ. I don't want the average Arch user to be infected when it can be prevented because the malware is known about.
diggan
> I don't want the average Arch user to be infected when it can be prevented because the malware is known about.
Me neither, my argument would be that VirusTotal won't stop the initial users from getting infected, so not good enough in my mind.
OsrsNeedsf2P
Between false positives, high QPS, and the fact malware devs would then test against Virus Total, is this useful?
icar
Just create a pacman hook before install that uploads the package there and aborts installation if necessary. Probably skipping repo packages is a good idea otherwise you're gonna spam the API each update.
> We strongly encourage users that may have installed one of these packages […] to take the necessary measures in order to ensure they were not compromised.
How are they supposed to do that when you give them no information as to what the malware does?