Malicious AUR Yay Typosquats Run Root Scripts: How Arch and WSL Users Should Respond

As reported by BleepingComputer, a threat actor recently uploaded a batch of malicious packages to the Arch User Repository (AUR) designed to impersonate two of the ecosystem's most popular command-line helper tools: yay and paru. Detected on October 13, 2026, the campaign paired legitimate upstream code with booby-trapped installation scripts that silently fetched and executed a remote shell script with full root privileges.

Whether you run Arch on bare metal, manage Linux build environments alongside your enterprise Windows fleet, or keep an Arch instance tucked inside Windows Subsystem for Linux (WSL) for development work, this incident is a masterclass in how modern software supply-chain attacks exploit human muscle memory and automated package workflows.

Anatomy of the October 13 AUR Typosquatting Attack​

To understand why targeting yay and paru is so insidious, it helps to look at how Arch Linux handles third-party software. The AUR is not an official repository of pre-compiled binaries; instead, it is a community-maintained index of package build scripts, known as PKGBUILD files, that allow users to compile and install third-party, proprietary, or beta software that is not offered in the official Arch distribution channels. Because manually cloning git repositories and running makepkg can get tedious, users routinely install "AUR helpers" like yay and paru to automate searching, fetching, compiling, and installing AUR packages.

On the evening of October 13, an account operating under the handle marchos1as began mass-uploading typosquatted packages mimicking these exact helpers. A warning quickly surfaced on the aur-general mailing list in a thread titled "hundreds of aur packages were mass uploaded with malware" after user James Smith flagged the uploader's activity. Within minutes, community maintainers dissected the uploads and confirmed the trap.

According to an analysis posted to the Arch Linux aur-general mailing list by AUR maintainer Andreas Reichel, one flagship example—a package named yyay—presented itself as a straightforward repackaging of the legitimate yay helper (version 13.0.1). It pointed to the real upstream GitHub repository (github.com/Jguer/yay) and validated against the genuine source tarball's SHA-256 checksum. If a user or an automated scanner only checked the PKGBUILD source array or the compiled binary code, everything looked completely normal.

The poison was hidden in the accompanying install scriptlet (yyay.install).

How the .install Scriptlet Fooled Casual Inspection​

In Arch Linux package management (pacman), an .install file defines hook functions—such as post_install and post_upgrade—that execute as root on the live system when the built package is finally installed. Reichel's inspection revealed four critical security findings showing how the attacker weaponized this file:

1. Decoy Hook Functions: The attacker deliberately emptied the post_install and post_upgrade functions, setting their contents simply to true. To a casual reviewer skimming the named functions—or a naive static scanner looking only inside standard lifecycle hooks—the scriptlet appeared harmless.
2. Top-Level Unconditional Execution: Outside of those functions, sitting at the very top level of the yyay.install file, was a command that piped a remote script directly into a shell. Because pacman sources the .install file as root during installation and upgrades, top-level code executes unconditionally with full root privileges.
3. Wayback Machine Evasion and GitFlic Hosting: Rather than pulling the payload directly from an obvious command-and-control server, the scriptlet fetched a remote linux.sh script through an Internet Archive Wayback Machine (web.archive.org) wrapper URL pointing to a personal repository (hellscripter/install-scripts) hosted on the Russian code-hosting platform GitFlic (gitflic.ru).
4. Unpinned Payload Delivery: As Reichel pointed out on the mailing list, the Wayback Machine URL did not pin a specific snapshot timestamp, and the fetched script was not declared in the source=() array or bound by a cryptographic checksum. That meant whatever payload linux.sh served at the moment of installation—whether credential theft, a backdoor, or a rootkit—ran with complete administrative control over the machine.

Rapid Community Detection via TrustSight​

While the structural trickery in the .install script was clever, the campaign was caught remarkably fast. On the aur-general mailing list, maintainer Emiliano Gandini Outeda shared telemetry from his open-source application security monitoring tool, TrustSight.

Just seven minutes after the upload on October 13 (at 9:34 PM), Gandini's watcher container generated 45 alerts across three detection rules (H045, H052, and G003), grouping 15 typosquatted package names into a single campaign cluster:

Every single one of those names is a classic "fat-finger" keyboard slip away from yay on a standard QWERTY layout. Following the community alerts, the AUR team banned the marchos1as account and purged the malicious packages from the repository.

Section Summary: The attacker uploaded at least 15 typosquatted clones of popular AUR helpers that compiled real upstream code while hiding a root-level shell execution command at the top level of the .install scriptlet. Automated community monitoring caught the cluster within seven minutes, and the AUR team removed the packages and banned the uploader.

Connecting the Dots: DirtyBlanket and the wider AUR Threat Landscape​

If the repository name hellscripter/install-scripts and the abuse of the Wayback Machine sound familiar to supply-chain security researchers, there is a good reason. BleepingComputer notes that application security firm SafeDep recently documented an npm malware campaign dubbed "DirtyBlanket".

In the DirtyBlanket operation, nine malicious npm packages published under the dirtyblanket account used installation hooks to pull code through the Wayback Machine and referenced a hellscripter/install-scripts repository hosted on Codeberg. SafeDep's researchers found that the campaign deployed a Linux worm carrying the CHAOS remote-access trojan (disguised as a system font service) that also attempted to inject a malicious loader into local AUR packages. Furthermore, an Open Source Vulnerability (OSV) advisory tracking the DirtyBlanket npm activity documented the exact same Wayback Machine wrapper technique and gitflic.ru domain.

Is the marchos1as AUR campaign the work of the exact same threat actor behind DirtyBlanket? While the shared repository naming convention (hellscripter/install-scripts), the Wayback Machine proxy trick, and the GitFlic hosting infrastructure point to a strong technical overlap, neither SafeDep nor Arch Linux maintainers have confirmed a definitive link between the two operations. In the world of threat intelligence, attackers occasionally reuse public scripts or mimic another group's infrastructure, so attribution remains unconfirmed.

What is undeniable, however, is that the Arch User Repository has endured a relentless barrage of supply-chain attacks throughout 2026:

• June 2026 (400+ Packages Compromised): Threat actors compromised more than 400 AUR packages—including samples pushing a malicious atomic-lockfile payload with an ELF binary named deps. Independent researcher Whanos reported that the malware acted as a credential stealer with optional root-only eBPF (extended Berkeley Packet Filter) rootkit capabilities. It specifically hunted for developer workstation secrets across browsers, Electron apps, Microsoft Teams, Slack, Discord, GitHub, npm, Vault, Docker/Podman, SSH keys, and VPN configurations, while establishing persistence via systemd services.
• July 2026 (Package Adoption Freeze): Another wave of malicious activity in July forced the Arch Linux team to temporarily disable package adoption and restrict account actions while staff tracked down rogue commits.
• October 2026 (Helper Typosquatting): Rather than hijacking existing orphaned packages, marchos1as went straight for the bootstrap workflow—catching users who are setting up a fresh Arch installation and accidentally mistype the name of the very tool they use to manage the AUR.

Section Summary: While technical indicators like the hellscripter/install-scripts path and Wayback Machine URLs mirror the recent "DirtyBlanket" npm worm, an official link remains unconfirmed. The October attack marks at least the third major wave of AUR abuse since June 2026.

Why This Matters for Windows Power Users and Hybrid IT Admins​

You might be reading this on a Windows 11 workstation and thinking, "That's rough for the Linux crowd, glad it's not my problem." Not so fast.

In modern enterprise IT and software development, the boundary between Windows and Linux has practically dissolved. With Microsoft continuously expanding Windows Subsystem for Linux (WSL) and rolling out native Linux container support, countless developers, DevOps engineers, and sysadmins run Arch Linux distributions inside WSL2 alongside their primary Windows environment.

As we saw in the June 2026 AUR campaign, Linux supply-chain malware is explicitly engineered to raid hybrid developer workstations—targeting cross-platform assets like Microsoft Teams tokens, GitHub credentials, npm tokens, SSH keys, and cloud vault secrets. If an attacker compromises a root environment inside a developer's Linux instance or build container, they aren't looking to admire your custom terminal prompt; they want the keys to your corporate source code, cloud tenants, and enterprise communication channels.

Actionable Guidance: How to Audit and Protect Your Systems​

Because the AUR team removed the malicious packages quickly, the window of exposure on October 13 was narrow. However, removing a package from the online AUR index does nothing to clean a machine that already downloaded and ran the .install script.

If you or your team manage Arch Linux systems, follow this step-by-step verification and hardening guide:

1. Check Your Package Manager History​

Do not rely on memory to know whether someone mistyped a package name during a late-night setup session. Check your pacman log and currently installed foreign packages for any of the 15 known typosquatted names (ay, ayy, hay, tay, uay, ya, yaay, yat, yau, yayy, yqy, ysy, yya, yyay, yzy) or any unfamiliar paru variants:

• Inspect /var/log/pacman.log for any installation or upgrade events occurring on or after October 13, 2026.
• Run pacman -Qm to list all installed foreign (non-official repository) packages and verify every single entry against known-good package names.

2. Treat Any Exposed Host as Fully Compromised​

Wait—if you find yyay on a machine, can you just run pacman -Rns yyay and call it a day? Absolutely not.

Because the malicious .install script executed arbitrary, unpinned remote code (linux.sh) with full root privileges during installation, the operating system can no longer be trusted. An attacker with root access can modify system binaries, plant systemd services, or load kernel-level eBPF rootkits that hide processes from standard inspection tools.

• Isolate the machine from your network immediately.
• Rebuild the system from scratch using verified, known-good installation media (or wipe and recreate the WSL distribution from a clean official image).
• Rotate all credentials that were stored on or accessible from that machine—including SSH keys, GitHub/npm tokens, cloud access keys, VPN certificates, and web session tokens—using a separate, clean device.

3. Inspect Both PKGBUILD and .install Files Every Time​

Arch Linux's official security guidance during AUR incidents emphasizes reviewing all build and install script changes before compiling or updating. When your AUR helper prompts you to view diffs or inspect build files, do not blindly hit "Yes" to skip the review:

• Check the PKGBUILD to ensure the url and source=() arrays point to the legitimate upstream project and include valid cryptographic checksums (sha256sums or b2sums).
• Read the entire .install scriptlet from top to bottom. Look out for code placed outside of standard hook functions, commands that invoke curl or wget, URLs masked behind archive services like web.archive.org, or anything piped into sh or bash.

Open-source community repositories are one of the greatest strengths of modern computing, offering unmatched speed and software availability. But convenience is never a substitute for verification—especially when root privileges are on the line. Have you spotted suspicious packages in your own build pipelines recently, or do you enforce strict package allowlists on developer machines? Share your thoughts and security strategies with the WindowsForum community below.