- 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.

1 1

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

13 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.

2 2

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

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

13 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 72

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

13 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

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