Check if any infected package is installed using Arch authoritative list

check_aur_infected.sh

#!/usr/bin/env bash

# Pulls the live package list from the official Arch Linux HedgeDoc note.
LIST_URL="https://md.archlinux.org/s/SxbqukK6IA"

echo "Fetching infected package list..."

raw=$(curl -fsSL "$LIST_URL") || { echo "ERROR: failed to fetch $LIST_URL"; exit 1; }

# Extract lines that look like package names only (lowercase, digits, dots, plus, underscore, hyphen)
# Strips HTML, blank lines, comments, and anything that doesn't match a sane pkgname pattern.
mapfile -t INFECTED_PKGS < <(
    echo "$raw" \
    | sed 's/<[^>]*>//g' \
    | grep -E '^[a-z0-9][a-z0-9_.+\-]*[a-z0-9]$' \
    | sort -u
)

count=${#INFECTED_PKGS[@]}
if [[ $count -eq 0 ]]; then
    echo "ERROR: parsed 0 packages, something went wrong with the fetch/parse."
    exit 1
fi

echo "Checking $count known infected packages..."
echo

mapfile -t found < <(comm -12 <(pacman -Qmq | sort) <(printf "%s\n" "${INFECTED_PKGS[@]}" | sort))

if [[ ${#found[@]} -eq 0 ]]; then
    echo "Clean: none of the known infected packages are installed."
else
    echo "WARNING: ${#found[@]} infected package(s) found:"
    for pkg in "${found[@]}"; do
        echo "  - $pkg"
    done
    echo
    echo "You may be infected"
fi

# printf "%s\n" "${INFECTED_PKGS[@]}"

The script doesn't account for time. I have 1 infected package but looking through /var/log/pacman.log, I only updated/installed it in Feb/12/2026. How can I tell if I'm infected?

I'm in the same boat. I ran the script and saw that gamma-launcher was my infected package, gamma-launcher shows it got updated to 2.6-1 on 2026-03-20 in var/log/pacman.log so I checked the AUR package and saw it was last updated 2026-06-11 13:25 (UTC) or 8:25 (EST) with the same 2.6-1

I did a full system update through yay on 2026-06-11 8:08 (EST) which ended at 8:34 (EST) according to var/log/pacman.log, but gamma-launcher doesn't seem to be one of the packages that was updated as the last time it shows in the log is on 2026-03-20 until today when i removed it after running that script so I'm assuming I got incredibly lucky

@Ondomident That's pure luck.

So far 11.6.26 seems to be the start date (varying hours per package).

This is based on previous scripts here. Used AI to remove any installations (there's one above that adds a service).
Doesn't check date bc we don't know yet when it started (somewhere at 11.6.26 so far). does check for npm and stuff.
You should probably update and run rkhunter too.

https://gist.github.com/tharbad08/69739773b5960f2f0166748a75f29318

Run with:

./aur_check_safe.sh --deep

Thanks for all the work on this. I also dodged getting infected out of pure luck. I have a couple questions, though:

• At what point will it be safe to use the AUR again? When all packages are fixed? When the method of attack is discovered and closed?
  • I assume we'll see another announcement on the Arch Linux mailing list at that point?
• I know that the Arch maintainers have always recommended reviewing every PKGBUILD file before installing an AUR package for precisely this reason; a rogue maintainer can push whatever changes they want to an AUR package that they own. However, in practice, I don't think most people do, and it's honestly a lot of effort, and people may not even know what to look for. Are there solutions for catching malicious code in PKGBUILD files before installing them? I'm thinking:
  • There's the historical approach of anti-malware software that uses heuristics to detect known attacks
  • Or perhaps a newer approach of using AI to evaluate the code
  • Something like this could be used to gate AUR package changes before they go out, or run on the end user machine before installation
  • Is something like this already being investigated by the Arch maintainers? Or does it already exist? Is there a better place to discuss this than this Gist?

@tharbad08 your bash script seems to be the only one that flagged my system as potentially compromised, with it flagging normal system prepossesses?

you have any idea why that is?

@tharbad08 your bash script seems to be the only one that flagged my system as potentially compromised, with it flagging normal system prepossesses?

you have any idea why that is?

Don't know. paste the output

@tharbad08 your bash script seems to be the only one that flagged my system as potentially compromised, with it flagging normal system prepossesses?
you have any idea why that is?

Don't know. paste the output

./aur_check_safe.sh --deep

Safe AUR Compromise Indicator Checker

[INFO] Read-only checks. This script does not install, remove, build, or execute packages.
[INFO] Merged 645 package names from remote lists.
[INFO] Known affected package names loaded: 1932
[01/18] Checking installed foreign/AUR packages against affected list... PASS
[02/18] Checking pacman log for affected packages since 2026-06-11... PASS
[03/18] Checking pacman metadata/install scripts for malicious strings... PASS
[04/18] Checking common AUR helper build/cache dirs for malicious strings... FAIL
[FAIL] Malicious string found in build/cache files: /tmp/tmp.nm4dGkvzAY /tmp/tmp.gU0I1L6xlB /tmp/tmp.qjQHxhlRjq /tmp/tmp.wAtRhnEjq6
[05/18] Checking npm global packages for malicious package names... SKIP
[SKIP] npm not found
[06/18] Checking npm cache/root for malicious package names... SKIP
[SKIP] npm not found
[07/18] Checking eBPF pinned objects and suspicious BPF program names... PASS
[08/18] Checking for processes hidden from ps... PASS
[09/18] Checking running executables from temp/deleted paths... FAIL
[FAIL] Suspicious process executable path(s): 1280:kded6:/usr/bin/kded6 (deleted)
[10/18] Checking /etc/ld.so.preload... PASS
[11/18] Checking systemd persistence for suspicious commands... FAIL
[FAIL] Suspicious systemd unit content: /usr/lib/systemd/system/shadow.service /usr/lib/systemd/system/arptables.service /usr/lib/systemd/system/ebtables.service /usr/lib/systemd/system/halt.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/kexec.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/poweroff.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/reboot.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/xfs_scrub@.service /usr/lib/systemd/system/xfs_scrub_media@.service /usr/lib/systemd/system/grub-btrfs-snapper.service /usr/lib/systemd/system/NetworkManager-config-initrd.service /usr/lib/systemd/system/nfs-server.service
[12/18] Checking user autostart/desktop persistence... PASS
[13/18] Checking cron/anacron persistence... PASS
[14/18] Checking shell startup files for suspicious injection... PASS
[15/18] Checking active suspicious network connections... PASS
[16/18] Checking shells/interpreters with suspicious network connections... PASS
[17/18] Checking SSH authorized_keys... PASS
[18/18] Checking recent pacman hooks... PASS

============================================
Results: 13 passed, 0 warnings, 3 failures, 2 skipped

Indicators of compromise were found.
Treat this as a serious supply-chain compromise. Removing the AUR package is not enough if the payload ran.
Recommended next steps: disconnect the host from sensitive accounts, preserve logs if you need evidence, rebuild from trusted media, and rotate credentials from a clean device.

@rhetz2002
stage 4 - check these files.
11 seems ok. it fails easily there. maybe someone will improve that stage.

@tharbad08 got same result has @rhetz2002

[INFO] Read-only checks. This script does not install, remove, build, or execute packages.
[INFO] Merged 645 package names from remote lists.
[INFO] Known affected package names loaded: 1932
[01/18] Checking installed foreign/AUR packages against affected list... PASS
[02/18] Checking pacman log for affected packages since 2026-06-11... PASS
[03/18] Checking pacman metadata/install scripts for malicious strings... PASS
[04/18] Checking common AUR helper build/cache dirs for malicious strings... FAIL
[FAIL] Malicious string found in build/cache files: /tmp/tmp.bPXJubI0pK
[05/18] Checking npm global packages for malicious package names... SKIP
[SKIP] npm not found
[06/18] Checking npm cache/root for malicious package names... SKIP
[SKIP] npm not found
[07/18] Checking eBPF pinned objects and suspicious BPF program names... PASS
[08/18] Checking for processes hidden from ps... PASS
[09/18] Checking running executables from temp/deleted paths... PASS
[10/18] Checking /etc/ld.so.preload... PASS
[11/18] Checking systemd persistence for suspicious commands... FAIL
[FAIL] Suspicious systemd unit content: /usr/lib/systemd/system/halt.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/kexec.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/poweroff.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/reboot.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/shadow.service /usr/lib/systemd/system/arptables.service /usr/lib/systemd/system/ebtables.service /usr/lib/systemd/system/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/NetworkManager-config-initrd.service /usr/lib/systemd/system/nfs-server.service /usr/lib/systemd/system/xfs_scrub@.service /usr/lib/systemd/system/xfs_scrub_media@.service
[12/18] Checking user autostart/desktop persistence... PASS
[13/18] Checking cron/anacron persistence... PASS
[14/18] Checking shell startup files for suspicious injection... PASS
[15/18] Checking active suspicious network connections... PASS
[16/18] Checking shells/interpreters with suspicious network connections... PASS
[17/18] Checking SSH authorized_keys... PASS
[18/18] Checking recent pacman hooks... PASS

============================================
Results: 14 passed, 0 warnings, 2 failures, 2 skipped

Indicators of compromise were found.
Treat this as a serious supply-chain compromise. Removing the AUR package is not enough if the payload ran.
Recommended next steps: disconnect the host from sensitive accounts, preserve logs if you need evidence, rebuild from trusted media, and rotate credentials from a clean device.

@tharbad08
they all read

atomic-lockfile
lockfile-js
js-digest
npm install atomic-lockfile
npm install lockfile-js
bun add atomic-lockfile
bun add lockfile-js

im thinking they may be a false positive because the files create date matches with me starting to dig into the hack

yeah every time i run the script it creates a new one

Maybe someone will improve these stages then :)

curl -s https://md.archlinux.org/s/SxbqukK6IA | sed -n -e '/```$/,/^```/{/```/d; p}'

Hi @tharbad08, your suspicion is 100% correct.

I ran the script on my personal machine and got hit by the same alert, which led me to investigate further. After checking the file's exact creation time using stat, I noticed it was generated just seconds before.

It is a confirmed false positive caused by Bash's Process Substitution mechanism.

When a command or script pulls the infected list using a syntax like mapfile -t PKGS < <(curl ... | grep ...) (Process Substitution), Bash often creates a physical temporary file in /tmp to stream that data.

Since that file is created on the fly with the malicious package names you just downloaded to analyze, the scanner picks it up in step [04/18] right after it gets generated.

That’s why the creation date matches our investigation timeline and why a new file appears every single time the pipeline runs. It's just Bash handling the string pipelines. So everything is fine, I think :s

Am I safe? I ran the bash script.

thanks, copy and paste into terminal version (double check the code and Arch note url for safety)

bash -c 'LIST_URL="https://md.archlinux.org/s/SxbqukK6IA"; TMP_INFECTED=$(mktemp); TMP_INSTALLED=$(mktemp); trap "rm -f $TMP_INFECTED $TMP_INSTALLED" EXIT; echo "Fetching infected package list..."; raw=$(curl -fsSL --max-time 15 "$LIST_URL") || { echo "ERROR: failed to fetch"; exit 1; }; mapfile -t INFECTED_PKGS < <(echo "$raw" | sed "s/<[^>]*>//g" | grep -E "^[a-z0-9][a-z0-9_.+\-]*[a-z0-9]$" | sort -u); count=${#INFECTED_PKGS[@]}; [[ $count -eq 0 ]] && { echo "ERROR: parsed 0 packages."; exit 1; }; echo "Checking $count known infected packages against ALL installed packages..."; echo; printf "%s\n" "${INFECTED_PKGS[@]}" > "$TMP_INFECTED"; pacman -Qq 2>/dev/null | sort > "$TMP_INSTALLED"; mapfile -t found < <(comm -12 "$TMP_INSTALLED" "$TMP_INFECTED"); if [[ ${#found[@]} -eq 0 ]]; then echo "Clean: none of the known infected packages are installed."; else echo "WARNING: ${#found[@]} infected package(s) found:"; for pkg in "${found[@]}"; do ver=$(pacman -Q "$pkg" 2>/dev/null | awk "{print \$2}"); echo "  - $pkg  (installed version: $ver)"; done; echo; echo "You may be infected."; fi'

or use a file

#!/usr/bin/env bash
LIST_URL="https://md.archlinux.org/s/SxbqukK6IA"
TMP_INFECTED=$(mktemp)
TMP_INSTALLED=$(mktemp)
cleanup() { rm -f "$TMP_INFECTED" "$TMP_INSTALLED"; }
trap cleanup EXIT

echo "Fetching infected package list..."
raw=$(curl -fsSL --max-time 15 "$LIST_URL") || { echo "ERROR: failed to fetch $LIST_URL"; exit 1; }

mapfile -t INFECTED_PKGS < <(echo "$raw" | sed 's/<[^>]*>//g' | grep -E '^[a-z0-9][a-z0-9_.+\-]*[a-z0-9]$' | sort -u)

count=${#INFECTED_PKGS[@]}
if [[ $count -eq 0 ]]; then echo "ERROR: parsed 0 packages."; exit 1; fi

echo "Checking $count known infected packages against installed AUR packages..."
echo

printf "%s\n" "${INFECTED_PKGS[@]}" > "$TMP_INFECTED"

if ! pacman -Qmq 2>/dev/null | sort > "$TMP_INSTALLED"; then
    echo "ERROR: failed to query installed packages (DB locked?)"
    ls /var/lib/pacman/db.lck &>/dev/null && echo "  Stale lockfile may be the cause."
    exit 1
fi

mapfile -t found < <(comm -12 "$TMP_INSTALLED" "$TMP_INFECTED")

if [[ ${#found[@]} -eq 0 ]]; then
    echo "Clean: none of the known infected packages are installed."
else
    echo "WARNING: ${#found[@]} infected package(s) found:"
    for pkg in "${found[@]}"; do echo "  - $pkg"; done
    echo
    echo "You may be infected."
fi
EOF
)

i have a suggestion:

--- check_aur_infectedo.sh	2026-06-13 12:22:37.521227060 -0700
+++ check_aur_infected.sh	2026-06-13 12:22:26.748393454 -0700
@@ -3,6 +3,13 @@
 # Pulls the live package list from the official Arch Linux HedgeDoc note.
 LIST_URL="https://md.archlinux.org/s/SxbqukK6IA"

+has_paclog=false
+if which paclog > /dev/null; then
+    has_paclog=true
+else
+    echo "Install extra/pacutils to show logs of when packages that may contain malware could have been installed or updated."
+fi
+
 echo "Fetching infected package list..."

 raw=$(curl -fsSL "$LIST_URL") || { echo "ERROR: failed to fetch $LIST_URL"; exit 1; }
@@ -33,6 +40,7 @@
     echo "WARNING: ${#found[@]} infected package(s) found:"
     for pkg in "${found[@]}"; do
         echo "  - $pkg"
+        [ "$has_paclog" = true ] && paclog --color --package="$pkg"
     done
     echo
     echo "You may be infected"

this change uses paclog to print out when you last updated the reported packages so that it's easier to know if you were infected, e.g., as a general rule of thumb if it was over 2 months ago you're okay.

============================================
Safe AUR Compromise Indicator Checker

[INFO] Read-only checks. This script does not install, remove, build, or execute packages.
[INFO] Merged 647 package names from remote lists.
[INFO] Known affected package names loaded: 1934
[01/18] Checking installed foreign/AUR packages against affected list... PASS
[02/18] Checking pacman log for affected packages since 2026-06-11... PASS
[03/18] Checking pacman metadata/install scripts for malicious strings... PASS
[04/18] Checking common AUR helper build/cache dirs for malicious strings... FAIL
[FAIL] Malicious string found in build/cache files: /tmp/tmp.LuQl4eTutZ /tmp/tmp.SXIKVmoAgb
[05/18] Checking npm global packages for malicious package names... PASS
[06/18] Checking npm cache/root for malicious package names... PASS
[07/18] Checking eBPF pinned objects and suspicious BPF program names... SKIP
[SKIP] bpftool not found and no pinned BPF objects visible
[08/18] Checking for processes hidden from ps... PASS
[09/18] Checking running executables from temp/deleted paths... PASS
[10/18] Checking /etc/ld.so.preload... PASS
[11/18] Checking systemd persistence for suspicious commands... FAIL
[FAIL] Suspicious systemd unit content: /usr/lib/systemd/system/xfs_scrub_media@.service /usr/lib/systemd/system/shadow.service /usr/lib/systemd/system/wg-quick@.service /usr/lib/systemd/system/halt.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/poweroff.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/daxdev-reconfigure@.service /usr/lib/systemd/system/ebtables.service /usr/lib/systemd/system/arptables.service /usr/lib/systemd/system/xfs_scrub@.service /usr/lib/systemd/system/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/virt-secret-init-encryption.service /usr/lib/systemd/system/kexec.target.wants/mkinitcpio-generate-shutdown-ramfs.service /usr/lib/systemd/system/NetworkManager-config-initrd.service /usr/lib/systemd/system/reboot.target.wants/mkinitcpio-generate-shutdown-ramfs.service
[12/18] Checking user autostart/desktop persistence... PASS
[13/18] Checking cron/anacron persistence... PASS
[14/18] Checking shell startup files for suspicious injection... PASS
[15/18] Checking active suspicious network connections... PASS
[16/18] Checking shells/interpreters with suspicious network connections... PASS
[17/18] Checking SSH authorized_keys... PASS
[18/18] Checking recent pacman hooks... PASS

============================================
Results: 15 passed, 0 warnings, 2 failures, 1 skipped

Indicators of compromise were found.
Treat this as a serious supply-chain compromise. Removing the AUR package is not enough if the payload ran.
Recommended next steps: disconnect the host from sensitive accounts, preserve logs if you need evidence, rebuild from trusted media, and rotate credentials from a clean device.

Is it a good idea to just hold off on updating anything until this is resolved?

Once installed it uses atomic-lockfile lockfile-js js-digest to make weird thing. Simple script to check

for pkg in atomic-lockfile lockfile-js js-digest; do
  echo "=== $pkg ==="
  npm list -g "$pkg" 2>/dev/null | grep -q "$pkg" \
    && echo "npm global: FOUND" || echo "npm global: not found"
  found=$(find "${HOME}/.npm" /usr/lib/node_modules "${HOME}/node_modules" \
    -name "$pkg" -maxdepth 3 2>/dev/null)
  [ -n "$found" ] && echo "filesystem: FOUND → $found" || echo "filesystem: not found"
  pip show "$pkg" 2>/dev/null | grep -q "^Name:" \
    && pip show "$pkg" 2>/dev/null | grep -E "^Name:|^Location:" || echo "pip: not found"
done

This is based on previous scripts here. Used AI to remove any installations (there's one above that adds a service). Doesn't check date bc we don't know yet when it started (somewhere at 11.6.26 so far). does check for npm and stuff. You should probably update and run rkhunter too.

https://gist.github.com/tharbad08/69739773b5960f2f0166748a75f29318

Run with:

./aur_check_safe.sh --deep

Be careful on this script !!!

Please avoid writing malicious strings to disk at all: make_temp calls mktemp which creates a file in /tmp/ by default. The script then writes the malicious strings to it!!!

The strings land in a world-readable /tmp/XXXXXX file. Any process monitoring filesystem writes (e.g. auditd, inotify watchers) would see the malicious strings written to disk by a script claiming to be a security tool. A compromised system could detect the scanner via the presence of those strings in /tmp/

The script put npm install weird_package in this temp file. If the file is executed it can install the weird thing !!!! Only looking at this weird package is sufficient ...

grep_fixed_strings() {
  local dir
  for dir in "$@"; do
    [[ -d "$dir" ]] || continue
    grep -RIlF \
      -e 'atomic-lockfile' \
      -e 'lockfile-js' \
      -e 'js-digest' \
      -- "$dir" 2>/dev/null || true
  done
}

@kikislater I used AI
You can too.

Thanks dude appreciate the shell script

Changelog : Check #2: Now detects ansi-colors and nextfile-js alongside atomic-lockfile in npm/bun global installs and .INSTALL files. Also catches obfuscated hex/octal escapes ($'\xNN' / $'\NNN') and bun add in .INSTALL files.

• Check #10 (persistence): bun add added to the Exec= grep pattern.
• Check #11 (shell config injection): bun add detection added.
• Check #12 (global hook scripts): Now inspects bun's global packages at ~/.bun/install/global/node_modules/*/ alongside npm.
• https://github.com/nightdevil00/AUR-Malware , it might give false-positives results but better safe then sorry.
• The local fallback is updated periodically — as of 2026-06-14 it contains 1,935 known-infected packages (merged from 3 remote sources).

You guys are great !
I found a package in a distrobox of arch which was infected but should be fine

Security through obscurity? Why obfuscate the list instead of publishing it as plain text? Sighs... Anyway.

Here's my one liner: fetch packages, keep only the first column, then grep through the online list, to fetch with curl and deobfuscate plain text.

pacman -Q | sed -re 's/\s+.*$//g' | \
    grep -xf <(curl -fsSL 'https://md.archlinux.org/s/SxbqukK6IA' | sed -rne '/```$/,/^```/{//!p;}')

BTW I got a warning from grep: there seems to be stray NUL bytes in the middle of the file around position 0xef0-0xeff, as this capture from hexdump shows:

00000ed0  63 6f 72 64 69 75 6d 2d  6e 6f 64 65 2d 62 69 6e  |cordium-node-bin|
00000ee0  0a 63 6f 6e 6e 6d 61 6e  2d 6e 63 75 72 73 65 73  |.connman-ncurses|
*
00000f00  2d 67 69 74 0a 63 6f 6e  6e 6d 61 6e 2d 75 69 2d  |-git.connman-ui-|
00000f10  67 69 74 0a 63 6f 6e 74  61 69 6e 65 72 64 2d 67  |git.containerd-g|

@VinzSee, I prefer they were just in a rush, focused on finding the affected packages, and that the md wiki was the easiest way to share the progress in their current workflow. But I agree that this is hard to stand, given that a raw text is so easy to share.

@glaudiston Fine by me. I've seen shortly after that there's an official repository for verifying packages locally, so this is no longer a concern.

@c4software, you gave START_DATE=${START_DATE:-2026-01-01} and END_DATE=${END_DATE:-2026-06-12}. What is that based on?

@tharbad08, you wrote "if you didn't update your system between 11.6 and 13.6 you're probably safe even if you have packages installed" and "so far 11.6.26 seems to be the start date (varying hours per package)." What are these based on?

@zulc22, you proposed a "change [to use] paclog to print out when you last updated the reported packages so that it's easier to know if you were infected, e.g., as a general rule of thumb if it was over 2 months ago you're okay." What is the "2 months" based on? This change is an excellent proposal, but what would be better, if there were data about the specific dates of compromise per package, would be to check each package based on its specific window.

Has anyone compiled information about the specific dates each affected package was compromised?

Personally I upgraded one affected package 2026-01-13, so according to @tharbad08's claim, I am "probably safe", yet this falls within @c4software's window. Does anyone know what specifically to check for to investigate further and be sure?

@doctorcolossus Me looking at the initial mail that started this.
https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/

TBH, since that post I didn't look again, this might've changed.

All these packages where orphaned in the past. So the easy solution is check per package: Did you update after maintainer change?
Only if you got a package with new maintainer not known before, you might have a problem.
In this campaign case, we know how the infection looks like (those js files and packages): If you have them, you have a problem.

6 months is a common safety range.

@tharbad08, thanks for sharing your source. But yeah, it seems we're operating under assumptions... The time of detection could potentially be long after the actual attack, so it would be good to know exactly. Checking when the maintainers changed would be good, but is that information even still available? Like weren't the offending commits reverted (erased) and would the malicious commits no longer even be visible? If so, I guess a red flag would be if your pacman.log showed a version no longer listed in upstream AUR? 🤷‍♂️

In my case it was this package, and the PKGBUILD commit history shows the last commit 2025/12/14, which is indeed the version I installed (at least according to the version number), and it is the first commit from that author, but the package has a long history of changing authors and that particular commit looks quite trivial and innocuous to me...

If somebody has the actual dates/hashes/authors of the malicious AUR commits, that could useful data for the community in addition to just the package names, and could also be used to greatly improve this script by checking conclusively.