According to reporting by BleepingComputer, the packages combined legitimate upstream code with malicious installation scripts that downloaded and executed a remote shell script with root privileges.

The packages were uploaded by an account named marchos1as. The AUR team subsequently banned the account and removed the malicious packages.

The incident highlights how attackers can exploit trust in community-maintained software repositories to execute malicious code during software installation.

What Happened?

The Arch User Repository is a community-maintained repository containing package build instructions, known as PKGBUILDs, for software used on Arch Linux and derivative distributions.

Unlike packages maintained through Arch Linux's official repositories, AUR packages rely on community contributions. Users must therefore assess the package source and build instructions before installation.

In this campaign, attackers uploaded packages with names designed to resemble the legitimate yay and paru helpers. One identified example was yyay, a typosquatted impersonation of yay.

The malicious package reportedly used the same upstream URL and source archive as the legitimate project, making the package appear familiar. However, its installation script contained additional malicious behaviour.

How the Attack Worked

The reported infection chain can be summarised as follows:

1. Package impersonation: The attacker uploads packages using names similar to trusted AUR helpers.

2. User installation: A user installs or builds the malicious package, believing it to be legitimate.

3. Malicious installation script: The package executes an additional script during installation.

4. Remote payload retrieval: The script fetches another shell script from attacker-controlled infrastructure.

5. Root-level execution: The remote script runs with elevated privileges in the reported installation scenario.

6. Potential system compromise: The downloaded payload can perform malicious actions permitted by its execution context.

The report identifies a Wayback Machine URL pointing to an installation-script repository named hellscripter/install-scripts, hosted on GitFlic, as part of the delivery mechanism.

The complete payload behaviour is not established by the supplied report, so further claims about persistence, credential theft or specific backdoor capabilities should be supported by additional malware analysis.

Why Root Privileges Make This Dangerous

Root is the highest-privilege account on a typical Linux system. Code running as root can potentially modify system files, change security configurations, create privileged accounts and access sensitive information.

When a malicious installation script executes with root privileges, the impact can extend beyond the package itself.

Potential consequences include:

• Unauthorised modification of system files and configurations.

• Installation of additional malicious software.

• Creation of persistence mechanisms.

• Access to sensitive credentials or configuration files.

• Disabling or weakening security controls.

• Compromise of developer workstations, build servers or other systems accessible from the infected host.

These are potential consequences of root-level malware execution, not a confirmation that every action occurred in this particular campaign.

Possible Connection to the DirtyBlanket npm Campaign

BleepingComputer reported similarities between the AUR incident and an npm supply-chain campaign known as DirtyBlanket, documented by application security company SafeDep.

The npm campaign reportedly retrieved code from a repository named hellscripter/install-scripts hosted on Codeberg. Researchers identified a Linux worm that deployed the CHAOS remote-access trojan disguised as a font service and also injected a loader into AUR packages.

The overlap in repository naming and package-loader behaviour raises the possibility of a connection between the campaigns. However, shared infrastructure or similar techniques alone do not conclusively establish that the same operator was responsible.

Security teams should treat the relationship as an investigation lead until supported by stronger technical evidence.

SOC Investigation: How to Detect and Respond

1. Identify affected systems

Search Linux developer machines, build servers and Arch-based endpoints for the reported package names, including yyay, and review installation activity around 13 October 2026.

Check shell history, package build logs, system logs and available endpoint telemetry. Package names alone are not sufficient to determine whether a host is compromised.

2. Inspect package build scripts

Review the relevant PKGBUILD files and installation scripts for unexpected commands that download or execute remote content.

Look for:

• Remote shell-script retrieval.

• Piped execution of downloaded content.

• Unexpected privileged commands.

• Obfuscated commands or encoded payloads.

• Changes that are absent from the legitimate upstream project.

Compare suspicious package contents with a verified upstream version.

3. Review process and network telemetry

Investigate unusual shell processes launched during package installation and outbound connections to unfamiliar hosts.

Correlate process execution, parent-child relationships, DNS queries, proxy records and file creation events where available.

The reported repository path and delivery mechanism can guide research, but analysts should verify the exact URLs and associated infrastructure before creating block rules.

4. Examine potential persistence

If a host executed the malicious script as root, review for unexpected:

• Systemd services and timers.

• Cron jobs.

• SSH keys or authorised access changes.

• New users or modified sudo permissions.

• Startup scripts and modified system binaries.

• Additional downloaded executables.

These checks are standard incident-response steps for suspected root-level compromise, not confirmed indicators from the report.

5. Contain and recover

If malicious code executed with root privileges, isolate the affected system where appropriate and preserve relevant evidence.

Remove the malicious package, block verified malicious infrastructure, rotate exposed credentials from a trusted device and investigate possible lateral movement. Because root-level compromise can undermine system integrity, rebuilding from a trusted image may be safer than attempting to clean the system in place.

MITRE ATT&CK Mapping

Potential mappings depend on the observed execution chain and should be validated during investigation.

The first three are possible mappings to investigate. Do not assign techniques solely because they are plausible; use evidence from the package, execution logs and recovered payload.

Prevention and Security Recommendations

For Linux users and developers

• Verify package names and maintainers before installing AUR software.

• Review PKGBUILD files and installation scripts before execution.

• Avoid running untrusted installation scripts with elevated privileges.

• Prefer official repositories or trusted, independently verified sources where possible.

• Keep package-management tools and operating systems updated.

For security teams

• Monitor developer endpoints and build servers for unexpected download-and-execute chains.

• Scan package build scripts for suspicious shell commands and remote payload references.

• Apply least privilege to build environments.

• Use disposable or isolated build environments for untrusted community packages.

• Monitor changes to privileged files, system services and authentication configurations.

Conclusion

The malicious AUR package campaign demonstrates how software supply-chain attacks can exploit familiar package names and trusted community workflows. By combining legitimate upstream code with a malicious installation script, attackers can make a trojanised package appear credible while delivering code with elevated privileges.

For defenders, the key lesson is simple: trust in a package name or upstream source does not guarantee the integrity of its installation scripts. Inspect package build instructions, monitor privileged execution and treat unexpected remote script execution as a potential security incident.