critical

CVE

Not assigned

CWE

CWE-494, CWE-506, CWE-522, CWE-829

Affected Surface

  • Arch Linux systems that built or updated affected AUR packages from 29 July through 2 August 2026
  • At least 89 publicly corroborated AUR package names in the current wave, anchored by `openconnect-sso` and followed by moderator-handled batches of malicious adoptions and commits
  • Developer workstations, research laptops, and CI/build hosts using `makepkg`, `yay`, `paru`, or similar AUR helpers with root or sudo-assisted package build steps
  • Organizations that treat AUR package history or package adoption as a proxy for trust without diffing new `PKGBUILD`, source, and helper-script content

The new Arch AUR malware wave matters because it is not just a replay of June’s Atomic Arch campaign. In the June incident, the trusted AUR package was often the first-stage launcher for malware that pivoted into npm and Bun-delivered payloads. In the current late-July and early-August wave, primary reporting shows something more direct: malicious package takeovers inserted binaries such as validator straight into AUR package build paths, while Arch itself responded by first disabling package adoption and then disabling all pushes while cleanup continued.

That difference matters operationally. The attack path is no longer just “review PKGBUILD for suspicious npm install lines.” It is “assume that package adoption itself is part of the trust boundary, and that new sources, helper binaries, and privileged build steps can become the real payload.”

What is confirmed right now

The most defensible starting point is to separate confirmed primary-source facts from broader rumor:

  1. a malicious openconnect-sso update was publicly reported on 30 July;
  2. the reported commit added a binary named validator and executed it using sudo during packaging;
  3. Arch disabled AUR package adoption while handling an “influx of malicious package adoptions and follow-up commits”;
  4. Arch then disabled pushes altogether while incident handling continued;
  5. moderator-handled mailing-list reports publicly corroborate at least 89 named packages in this wave.

That last number is important because it is more precise than the looser public claims floating around social media and secondary coverage. I found support for:

  • 1 directly reported and analyzed package: openconnect-sso
  • 27 package names from one handled report batch
  • 42 package names from a second handled report batch
  • 19 package names from a third handled report batch

That gives a publicly corroborated floor of 89 named packages without claiming that every broader “hundreds of packages” allegation has been independently verified.

The first confirmed package: openconnect-sso

The openconnect-sso report is useful because it is specific enough to show the real execution boundary. The Arch mailing-list report states that the adopted package added a binary named validator and ran it under sudo while packaging. In other words, the dangerous line was not “someone installed a weird extra dependency.” It was that a previously trusted AUR package gained a privileged binary-execution step inside a normal build flow.

Reduced to the shape defenders should care about, the reported change looks like this:

trusted orphaned AUR package
  -> attacker adopts stewardship
  -> new commit adds binary source file: validator
  -> package build path invokes validator with sudo
  -> build host executes attacker-controlled native payload

That is a brutal trust failure for AUR users because it sits exactly where many people stop reviewing. They may diff:

  • version bumps
  • source=() URLs
  • checksums
  • package metadata

but still miss the more important question:

did this update introduce an executable artifact or privileged build step?

The openconnect-sso case says yes.

Affected package names: what can be said safely

The public evidence supports at least 89 names in this wave. I would not state that “hundreds were confirmed compromised” without a vetted canonical package ledger from Arch, because Arch’s own posts describe a high-volume incident but do not publish that kind of final inventory.

The names below come from public mailing-list reports that Arch staff explicitly acknowledged handling. They should be treated as the minimum named set defenders can scope against today, not as the final universe of affected packages.

Directly confirmed anchor package

openconnect-sso

First publicly handled batch of 27 names

archutil
bigwebapp-manager
boringssl-git
cinnamon-no-nemo
duhh
eden-nightly
garlic-decompiler-gui
gigolo-git
gitarbor-bin
icloudpd
imago-bin
juicebox-plus-git
magic-context-dashboard-bin
option-term
pagerduty-short-circuiter
portless
pylnker-git
python-libipld-git
python-numkong
python-parallax
python-ultraplot-git
ramses-git
src-cli-bin
steamidra-bin
stirling-pdf-desktop-bin
wiki-go
windscribe-cli-v2-bin

Second publicly handled batch of 42 names

astro-box
bili-tools-git
brutefir
cardamum-git
caveman
comodoro-git
deepseek-tui-git
gesso
gsimplecal-git
human-mcp-git
humen-mcp-bin
humen-mcp-git
i3-workspace-switch-git
i915-sriov-dkms
justevery-code
kickthemout-git
kloak-whonix
llama.cpp-ggml
mimosa-git
mingw-w64-vulkan-tools
nimf
node-llama-cpp
noctyra-cli-git
openrc-manager-gui
play-git
python-drastic
python-etcd3
python-twopoint-git
python-vxi11
rsbep-backup-git
rtk-git
rtv-git
scenecut-extractor
stable-diffusion.cpp-ggml
telegram-desktop-futpib-git
tempora-bin
tuigreety-bin
warp-terminal-dev-bin
warp-terminal-git
wayland-app-launcher-git
weather-display
zsh-directory-history-git

Third publicly handled batch of 19 names

accounts-qml-module-bin
arch-update-bin
aur-sync-vote-bin
bridge-utils-bin
byobu-bin
fsearch-bin
grub-customizer-bin
gtk-engine-murrine-bin
gtk2-bin
http-parser-bin
jellium-desktop-git-bin
mangowm-bin
mbedtls2-bin
openssl-1.1-bin
plasma6-applets-panel-colorizer-bin
python-inputs-bin
python-steam-bin
splix-bin
tuxmanager-bin

The common defensive lesson is that package names here are eclectic on purpose. The wave spans:

  • security and networking tooling
  • desktop and shell utilities
  • Python and Node-adjacent developer packages
  • AI/MCP-themed tools
  • terminal, package, and workspace helpers

That spread makes simple “only watch high-download packages” heuristics much less useful.

Why the trust boundary failed

The AUR incident is not a textbook typosquat story. It is a stewardship and execution-boundary story:

orphaned / newly adopted trusted package
  -> maintainer history still looks familiar
  -> malicious commit lands after adoption
  -> build path adds native payload or helper binary
  -> ordinary AUR install/update executes attacker code

That means many common safety shortcuts are weaker than users assume:

  1. Historical trust does not prove current content safety.
  2. A real package name is not better than a typosquat if stewardship changed.
  3. Reviewing only dependencies misses source-bundle and helper-binary abuse.
  4. Package-manager execution is still code execution, even before the installed app ever runs.

This is why the story belongs beside Atomic Arch, the Joyfill import-time RAT chain, and Anthropic’s likely anthropickit PyPI incident. The common theme is not the ecosystem. It is that the “normal” dependency or packaging path is now the malware runtime.

The payload chain reused prior tradecraft

IFIN’s early analysis is useful because it suggests the wave is not a one-off prank commit. The reporting says the openconnect-sso samples appear to reuse the same malware family seen in the previous AUR campaign, including Tor-backed second-stage delivery.

The published indicators include:

stage 1 sha256:
  e73a35b3e75e94746428d1a207703d6335933deadee7d1d9c9d0328df7b9df77
  2d25d2ea313767fae5808164224cf6ad610ab09546d1e5a6f033eedbfd98a281

stage 2 sha256:
  06c857c8ca798d50c765b4de39e6c4f272ecb57bc8316a8ed4c0fdf02fb59502

onion C2 / stage source:
  p4ayykxcrxfyzrgfbbkazernntjbz43hgclrheguylzd7kijmtce6zqd.onion

That is operationally important for two reasons.

First, it means defenders should not model this as “one bad PKGBUILD diff.” The package update is just stage zero. Second, it suggests that a successful build-time execution can pivot into the same kind of post-build host compromise AUR users were already dealing with in June.

LWN’s summary of the wave is directionally consistent with that reading: the payload appears to operate as a RAT and attempts to upload a wide range of user data.

Why sudo in the build path is the real red flag

The openconnect-sso report calls out that validator was executed with sudo during packaging. That one detail changes the incident from “package ran code as the build user” to “package may have been handed a privileged execution surface.”

That matters because AUR workflows often end up in one of three security postures:

case 1: unprivileged user builds package
case 2: helper uses sudo only for final install
case 3: package logic itself triggers sudo / root-adjacent execution

Case 3 is the dangerous one here. If the malicious update can cross from package logic into privileged execution during build or package handling, then the responder should assume:

  • credential theft from the current user context,
  • persistence installation,
  • and potentially wider host compromise

all became possible before the package was ever installed for normal use.

Detection and scoping

Start by finding whether an affected package was actually built or updated on a host during the current wave:

grep -E '2026-07-(29|30|31)|2026-08-0[12]' /var/log/pacman.log

pacman -Qmq | rg -n \
  'openconnect-sso|boringssl-git|icloudpd|stirling-pdf-desktop-bin|windscribe-cli-v2-bin|astro-box|node-llama-cpp|openssl-1.1-bin'

Then search common AUR helper caches and cloned package directories for the build-stage indicators:

rg -n 'validator|bundler|sudo|curl|wget|systemctl|crontab|onion|tor' \
  ~/.cache/yay ~/.cache/paru ~/.cache/pikaur ~/build /tmp 2>/dev/null

If you preserve package sources, compare commit timestamps and generated sources around the incident window:

find ~/.cache/yay ~/.cache/paru -type f | \
  rg 'PKGBUILD|\.install$|validator|bundler'

Network scoping should include Tor and other late-stage infrastructure, not just AUR access logs:

p4ayykxcrxfyzrgfbbkazernntjbz43hgclrheguylzd7kijmtce6zqd.onion

If a host built one of the affected packages and you also find:

  • unexpected systemd user services,
  • cron persistence,
  • suspicious binaries staged into build caches,
  • or modified developer configuration files,

then treat the case as host compromise rather than as a mere “bad package exposure.”

Response guidance

For any system that built or updated a named affected package during the exposure window:

  1. isolate the host before attempting cleanup;
  2. preserve AUR helper caches, pacman.log, package snapshots, and systemd unit files;
  3. rotate SSH, Git, cloud, registry, VPN, and application secrets reachable from that host;
  4. review whether the build path crossed into privileged execution through sudo or helper behavior;
  5. rebuild the machine from a clean image if you cannot confidently bound what the payload executed.

The June AUR incident already showed how quickly attackers can pivot from packaging abuse into full developer-host theft. The current openconnect-sso-led wave adds a sharper lesson: package adoption itself is now part of the threat model, and once the malicious content lands inside the build path, the trusted package name is mostly camouflage.

What defenders should remember

The most important thing to remember about the current AUR incident is not the exact package count. It is the trust failure that Arch itself had to acknowledge by freezing core repository workflows:

adoption disabled
  -> pushes disabled
  -> cleanup still ongoing

When a package ecosystem has to pause stewardship and publication mechanics to contain a live malware wave, defenders should stop asking whether this is “just” a community-maintained repository issue. It is a software-supply-chain incident that hits the same developer workstations, CI builders, SSH keys, cloud tokens, and local privilege boundaries AppSec teams already depend on every day.

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 Get Demo

References