Skip to content

Back to the catalog

aurscan
github.comrepo

aurscan

aurscan is a Go-based CLI that hooks into yay/paru to scan a downloaded AUR package's PKGBUILD, .install scriptlets, .SRCINFO and helper scripts before makepkg runs, blocking the build if it looks malicious. It combines offline, quote-aware static rules covering known AUR campaign signatures such as disguised source patch URLs, install-scriptlet worms, masqueraded binary file types, and editor auto-exec triggers with an LLM auditor (Claude Code, Codex, Anthropic API, or a local OpenAI-compatible model) that answers a fixed checklist of yes/no behavioral questions, from which aurscan deterministically derives a verdict, severity and confidence, and fails closed when no backend is available. It documents and defends against real incidents including the July 2025 firefox-patch-bin CHAOS RAT vector, the June 2026 Atomic Arch mass orphan-package takeover pulling a Rust stealer and eBPF rootkit, and the August 2026 xsnow dot-install worm that harvested SSH keys and self-propagated across AUR.

TL;DR A yay or paru build hook that has an LLM or static rules read PKGBUILDs and install scriptlets and blocks the build if the AUR package looks malicious.
Open original ↗
Document

What it is

aurscan is a two-stage AUR install scanner distributed as a signed pacman package (aurscan-bin) from its own repository, not the AUR itself. It intercepts yay/paru downloads and scans PKGBUILD, .install scriptlets, .SRCINFO, and helper scripts before makepkg runs, emitting a verdict with a confidence percentage and per-finding severity.

How it works

Two stages, in order: offline static rules match known campaign signatures at zero cost, then a model (Claude, Codex, or local) receives those rule hits plus the package's AUR reputation and judges the subtle cases. With no model configured, the static rules alone still return a fail-closed verdict — so offline use is covered. The plain-English "what this package does" line printed under the verdict is deliberately outside the verdict derivation: it cannot change the label, confidence, or severity. Token/cost accounting is printed per scan.

What to do

Install via the signed repo. First trust the key — verification rests on the fingerprint 61E73AA7539ACB261ABCF10C188331308EF56D11, the same key that signs SHA256SUMS.asc on every GitHub release, not on the transport:

curl -fsSL https://manticore-projects.github.io/aurscan/aurscan.gpg |
  sudo pacman-key --add -
sudo pacman-key --lsign-key 61E73AA7539ACB261ABCF10C188331308EF56D11

Add the repo to the end of /etc/pacman.conf so official repos keep precedence (idempotent):

grep -q '^\[manticore\]' /etc/pacman.conf ||
  printf '\n[manticore]\nSigLevel = Required DatabaseOptional\nServer = https://manticore-projects.github.io/aurscan/$arch\n' |
  sudo tee -a /etc/pacman.conf

Then install (x86_64 and aarch64 published):

yay -Syu aurscan-bin      # or: paru -Syu aurscan-bin  ·  sudo pacman -Syu aurscan-bin

Prefer the HTTPS key route: keyservers are best-effort, and pre-2021 systems often still point at the defunct pool.sks-keyservers.net (check with grep -i '^keyserver ' /etc/pacman.d/gnupg/gpg.conf). Leave $arch literal — pacman expands it.

Caveats

The page states outright that an LLM scanner is a strong extra layer, not a guarantee: keep building in a clean chroot, prefer official-repo packages, and be wary of freshly-adopted orphans. Adding any third-party pacman repo grants it root-level trust on your system (the page's final line is truncated mid-sentence on this point) — you are extending trust to manticore-projects' signing key for all future upgrades, which is precisely the maintainer-trust surface the xsnow and Atomic Arch campaigns abused.

Technologies named here

Techniques named here

  • Disguised/impersonated source entry
  • Post-install dependency-chain payload
  • Git commit forgery
  • Hidden install scriptlet payload
  • Tor-based payload delivery and SOCKS/.onion C2
  • systemd persistence
  • SSH credential harvesting
  • Self-propagating AUR worm
  • Command/token obfuscation
  • Masqueraded file type / script behind binary extension
  • Editor/directory-open execution trigger
  • Unpinned dependency resolution at build time
  • Prompt injection against LLM auditor
  • Unpinned upstream installer piped to shell
  • Build cache writes outside $srcdir
  • Mutable patch source
  • pkgver/source URL mismatch

Threat actors named here

Related in Supply Chain