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

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 4

Re: AUR REPORT THREAD
by Jason Marinaro 14 Jun '26

14 Jun '26

Also just found all PKGBUILD's by user : https:// aur.archlinux.org/account/skarbricat[1] Have malicious stuff/code also. -------- [1] https://aur.archlinux.org/account/skarbricat

1 0

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

33 83

Re: [aur-general] AUR malware campaign, June 2026 (atomic-lockfile / lockfile-js / nextfile-js)
by cmhacks 14 Jun '26

14 Jun '26

Hi everyone, Since the obfuscation techniques in this campaign are evolving rapidly (e.g., using shell hex/octal escapes and switching to alternative package managers like "bun add"), relying solely on static package name lists is becoming a cat-and-mouse game. To help with audits, I've put together a lightweight, read-only, behavior-based detection script. Instead of just checking package names, it inspects what actually ran on the system and what is staged to run. Key features: 1. Inspects definitive install hooks in /var/lib/pacman/local/ for any JS package manager calls or obfuscation. 2. Scans paru/yay clone caches safely (using find -print0 / read -d '') to catch payloads before installation. 3. Performs efficient, stream-based file scanning via 'grep -a' to prevent null-byte truncation or memory issues with large/binary files. 4. Fully compatible with strict environments (set -uo pipefail) and handles empty arrays defensively. You can find the script and review the code here: https://gist.github.com/l33tm4st3r/f6895a62167bd3d83f298d27ffd46741 Hopefully, this helps community members audit their systems or analyze the clones safely. Any feedback or additional heuristic patterns are highly appreciated. Best regards, cmhacks

4 8

Possible new find of malware in AUR
by Remco R. 14 Jun '26

14 Jun '26

Hello, This is my first post to the list. I subscribed because I found a number of packages in the AUR that are suspicious. It's a number of commits by the account pingwin840, that have been done in the last few hours. Most of them contain this postinst string (was in russian I think, but google translate gives this result): You're an idiot and you're using a crap Kal distro. Install pip and don't embarrass yourself. Or at least don't use AUR for idiots. Be grateful I didn't add any malware to you yet, but just made a reminder in the console. Happy Pride Month! Use Nocord, RAC, and coproxy by Mr. Sugoma! Download a new Albanian virus from Russia. You were hacked by StopPampers. Tesling deleted. Install PIP. I'm afraid of PIP. For such a face, I'll PIP. You were hacked by rclxit. I'm cool, I use Windows. Examples are peksystray obd-auto-doctor It looks like for most PKGBUILD files the commit diff is only this string in the post install, although I didn't investigate all of them. I could look further into this if that would be appreciated. Remco

1 0

AUR REPORT THREAD
by Nicolas Bérigaud 14 Jun '26

14 Jun '26

Hi New AUR user take over orphans packages https://aur.archlinux.org/packages?SeB=m&K=pingwin840&O=0&SB=l&SO=d

1 0

Some orphaned packages are being spoiled
by Дневник UNIX'оида 14 Jun '26

14 Jun '26

Hello! The user pingwin840 takes over some orphaned packages and adds some russian insulting strings to post_install function that writes them to shell rc files. Not as malicious as the latest infostealer attack, but still something has to be done https://aur.archlinux.org/packages?SeB=m&K=pingwin840&O=0&SB=l&SO=d

1 0

Suspicious AUR account
by Felipe Contreras Salinas 14 Jun '26

14 Jun '26

This account took over an orphaned package I used to maintain: https://aur.archlinux.org/account/charlottedurand You can see it now owns a lot of unrelated packages, so it is probably an AUR attack account.

1 0

Ownership change without consent
by madflow＠frikadelic.net 14 Jun '26

14 Jun '26

Hi, I have maintained https://aur.archlinux.org/packages/omnidb-server for a while, until the upstream project EOLed. I kept it there for historic reasons. Now I came to understand that it has been transferred to another "maintainer" because it was flagged as "orphaned". It was not orphaned - there where no upstream changes anymore. The new owner is a malicous actor with a fake gmail. I have send a deletion request, there seems to be no other way of deleting I understand that there is some sort of adoption process. I cannot find any emails, where my consent has been asked for. I hope that the package in question will be deleted shortly. I would argue that the adoption process as is should be subject to change. Best Flo

1 0

[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 6