A malicious install script changes the incident question. The first question is not simply whether the package was removed. It is whether the scriptlet executed, what privileges it had, and which credentials or network paths were reachable from that host. The yyay report says the malicious command ran from a top-level install-scriptlet line and could execute downloaded code as root during installation or upgrade.

That makes a light cleanup risky. If the command ran, deleting the package may remove evidence while leaving a stolen key, a modified service, or a remote-access path in place. The endpoint review should preserve the package record and the surrounding build evidence before the team changes the machine.

Start with package identity and timing

Record the exact package name, version, install time, build user, and source revision. Save the PKGBUILD, install script, local patch files, and any package artifact still on disk. The Arch PKGBUILD(5) manual explains the install-script relationship, while makepkg(8) describes the local build workflow that produces the package. The mail-list scan supplies the specific command pattern that made yyay dangerous.

pacman -Qm lists foreign packages that do not exist in the configured sync repositories. pacman -Qo can identify the package that owns a file, and pacman -Qkk checks installed files against the local package metadata. These commands help build a timeline. None of them proves whether an install-script command reached the network, so pair them with the configured pacman log, shell history, process telemetry, and systemd records.

If the host has a package cache or build workspace, preserve it before cleanup. A local .pkg.tar.zst can contain the install script and show what was actually installed. Build directories can also contain fetched sources and logs. Timestamps should be interpreted in the host's local timezone and converted carefully when compared with the public report.

Inspect package execution as well as package names

The known package name is a useful lead, but the broader search should cover behavior. Look for shell processes that fetched a remote script and piped it into an interpreter. Review outbound proxy and DNS logs for the path described in the maintainer scan, including archive-wrapper traffic that may look more ordinary than a direct download.

Check for new system services, scheduled jobs, shell profiles, package-manager hooks, and changes to SSH configuration. The maintainer scan warned that the remote script was not fixed and could change, so a later copy of the URL may not match what ran during the incident. Preserve the response if the organization has it. If not, record that the payload content is unknown.

The host may also contain new package activity. A root-level script can modify package state, add files, or run commands under multiple users. Compare package lists, install-script files, ownership changes, and recent logins before deciding that the removal step was complete.

Decide whether to clean or rebuild

Cleaning is reasonable when the team can show that the package was downloaded but never installed, or when package records and telemetry establish that the suspicious scriptlet did not execute and no related changes occurred. That conclusion needs evidence, not a filename match.

A host that ran a top-level scriptlet as root should be handled as a potential compromise. Preserve evidence, isolate it from production credentials, and rebuild from a trusted image when the scope is uncertain. Rotate credentials that were readable on the host, including SSH keys, package-service tokens, cloud credentials, and browser or developer sessions. Review AUR and Git push activity under those credentials.

For a fleet, use one incident record per host. Store the package name, version, install time, user, evidence source, execution conclusion, cleanup action, credential rotation, and final owner. Do not merge a package inventory finding with a confirmed execution finding. They have different consequences.

Verify the endpoint inventory

The public report did not establish how many systems installed the lookalike packages. The team therefore cannot use its own package list as a complete count unless the list covers every relevant host and user. Include developer laptops, build runners, jump hosts, and any system where AUR access may have been enabled outside the normal configuration baseline.

Alerting rules should cover future changes as well as this package. Flag any new .install file, network command in a package lifecycle file, untrusted URL in a source entry, new maintainer identity, and package name edit distance from an approved baseline. Route the alert to the host owner with a clear decision: block, review, or approve.

What ZoomEye can and cannot show

ZoomEye can show public assets that mention the AUR, not the package state of an Arch endpoint. A query for http.body="Arch User Repository" returned 268 public assets in an all-scope observation on 7 November 2026. Use that as an ownership and awareness signal. It cannot locate yyay, prove that an install script ran, or count victims.

The strongest workflow combines both views. Use public evidence to find teams, services, and documentation connected to AUR workflows. Use endpoint evidence to decide what actually ran. The second source is the one that supports containment and recovery.

References