Steve Adams
macrumors 68000
The Linux kernal has the most in one section however. It's all on the user to be safe. But Apple looks like it's "safer" than all of the other major players though.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Linux Discussion
- Thread starter maflynn
- Start date
- Sort by reaction score
Its not normal, but its also one of those issues, where there is a lack of oversight makes it a tempting attack
Similar issues for have been reported here: Gitub: Microsoft removes GitHub projects after malware compromise
Even developer sites are not immune: HWMonitor and CPU-Z developer CPUID breached by unknown attackers
I think the design of macos is inherently stronger and more resistant, but and I think user vigilance could be its weak point
I find that most mac users have a vary casual, attitude towards security. The thinking is that its a mac, it can't get a virus, makes people too complacent. At least with windows, users have a measure of paranoia, at last most do, lol
Linux is one of those platforms, where I think the lack of malware in the past has also caused people to be very lax and complacent.
Overall, though I think macos definitely does has an edge, and its easier to avoid such things on the mac platform then windows and linux.
S.B.G
Moderator emeritus
To add to what @maflynn said, supply chain attacks, especially in Linux package managers have been the latest fad from malicious actors over the past few years. It's despicable and shameful that there are so many bad people out there messing things up for everyone.
Also, macOS is much stronger than Windows and Linux because the kernel is a BSD kernel which BSD is inherently more secure by design.
Also, macOS is much stronger than Windows and Linux because the kernel is a BSD kernel which BSD is inherently more secure by design.
eltoslightfoot
macrumors 68040
I used to use FreeBSD for all my web servers back in the day. Of course for a server, you don't need a GUI so it worked really well, and it was definitely easier to harden.
ClaraStahlbaum
macrumors 6502a
I have tried Ubuntu in the past on UTM. I like the way it is laid out. For me it wouldn't be worth it to buy another computer soley for Linux, but I imagine that Ubuntu on a dedicated computer would run better than on UTM.
Not a fun time in the linux world
Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Affected Packages
github.com
Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Affected Packages
So the Arch User Repository has largely been cleaned up of malware, or at least this identified malware, but I think its safe to scan your system, if you're on an arch based distro. With that said, Lenucksi rolled out a check to see if you're infected. Given the issues with AUR, I would recommend reviewing this yourself before running it
GitHub - lenucksi/aur-malware-check: Detection tools for the June 2026 atomic-lockfile AUR supply-chain attack. Consolidated from community Gists.
Detection tools for the June 2026 atomic-lockfile AUR supply-chain attack. Consolidated from community Gists. - lenucksi/aur-malware-check
github.com
splifingate
Contributor
Not a fun time in the linux world
Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Affected Packages
So the Arch User Repository has largely been cleaned up of malware, or at least this identified malware, but I think its safe to scan your system, if you're on an arch based distro. With that said, Lenucksi rolled out a check to see if you're infected. Given the issues with AUR, I would recommend reviewing this yourself before running it
GitHub - lenucksi/aur-malware-check: Detection tools for the June 2026 atomic-lockfile AUR supply-chain attack. Consolidated from community Gists.
Detection tools for the June 2026 atomic-lockfile AUR supply-chain attack. Consolidated from community Gists. - lenucksi/aur-malware-check
Weren't most of the compromises directly as a result of including/using npm?
I know a lot of folks talk about the enshipification of everything-AI, but slip-streaming to-the-roots-integrated globs of compressed, obfuscated javascript into our every-day experience was (at least for me) where it all started.
*cue Ecosystem Stores*
Yes, that's my understanding, though I'll be the first to admit I don't have a full grasp of what's happening
The article I linked too, lists the packages, I need to cross reference that, with what I was doing this past week. I was installing programs using yay all last week. From my eye balling that list, nothing jumped on, but I need to do a deeper dive.
splifingate
Contributor
Atomic Arch: 900+ AUR Packages Backdoored with eBPF RootkitCopy | The CyberSec Guru
On June 11, 2026, the Atomic Arch supply chain attack backdoored 900+ Arch Linux AUR packages with the 'deps' infostealer and an eBPF rootkit
thecybersecguru.com
"The Payload: Meet DEPS
The binary is stripped and implemented with Rust-style async state machines. It’s not some off-the-shelf malware kit. This was written in Rust, compiled to a stripped 64-bit ELF, around 3 MB in size, and engineered specifically for developer workstations and build environments.
Sample metadata:
- File: deps
- Size: 3,040,376 bytes
- Type: Linux ELF64, x86-64, PIE, dynamically linked
- SHA-256: 6144D433F8A0316869877B5F834C801251BBB936E5F1577C5680878C7443C98B
- MD5: 42B59FDBE1B72895B2951412222EBF40
What it steals
The payload targets SSH keys, GitHub tokens, npm credentials, Docker and Podman auth, HashiCorp Vault tokens, browser session data, Slack, Discord, Microsoft Teams, Telegram, VPN config files, and shell histories. It also enumerates Chromium-family browser profiles – reading SQLite cookie databases and LevelDB local storage and queries Slack, Teams, Discord, GitHub, and OpenAI/ChatGPT APIs directly with any stolen tokens or cookies.
This is a credential vacuum aimed squarely at developers. Your AWS keys in .env, your GitHub PAT in ~/.gitconfig, your SSH private key for that production server – all of it in scope."
I've seen a few "are your packages compromised?" checkers o/l, but these mostly have been the "curl -sL URL://thingy | bash" type links, and *cough* I'm not ready to jump into stuff like that right now 😉
throAU
macrumors G4
Windowmaker is a clone of the NextSTEP UI which was the OS that Jobs was responsible for when he was kicked out of Apple (and which evolved into OS X).
Last edited:
CasualFanboy
macrumors 6502a
The Arch user repository has been notoriously sketchy for years now. It's just the contributions of random users, and probably doesn't have a rigorous standard for contributions, if any standard at all.
S.B.G
Moderator emeritus
I'm pretty sure my Arch machine is safe. The last time I turned it on was June 10th. From what I can find, the exploitation of the AUR began on June 11th. I still haven't turned it on yet, but I'll do an inspection nonetheless. My machines target scope is reduced since I cleaned up a lot of stuff the week before going from over 2100 packages to about 1300 packages installed.
throAU
macrumors G4
Check to see if you have anything installed from AUR for a start.
run pacman -Qm
If you get nothing, you have no AUR packages installed.
S.B.G
Moderator emeritus
I know I have AUR packages installed. I've been running Arch for many years.
The last time I ran the machine was the day before the attack.
This article has further details on what was happening, I found it on reddit, so take the value/validity of this article with a grain of salt.
It looks like its mostly, focusing on chromium and electron based applications. I don't use any chromium, i.e., chrome, edge, nor do I have any electron based apps
Preliminary analysis of AUR malware
Malware Analysis Report: deps Report date: 2026-06-11 VT Link Triage Link Note: The following report was very hastily written by Codex. (I have fact-checked it against the IDA decompilation though 🐉) Scope and Handling This report summarizes static reverse engineering of the Linux ELF...
ioctl.fail
It looks like its mostly, focusing on chromium and electron based applications. I don't use any chromium, i.e., chrome, edge, nor do I have any electron based apps
From what little I know, it seems if an AUR package is abandoned, anyone can claim it.
I would hope the AUR overlords impose stricter governance and guidelines on AUR. Just pasting a boiler plate warning about use at your own risk, is not sufficient in 2026
S.B.G
Moderator emeritus
The disclaimer was always a liability shield, not a security control, so the point that "use at your own risk" doesn't actually stop anything is fair.
Most of what would meaningfully address this specific incident doesn't require turning the AUR into a curated repo with an "overlord" making subjective calls about package quality. A review delay before an ownership/orphan-adoption change goes live, automated diffing that flags when a PKGBUILD suddenly adds new build/runtime dependencies it never had before, rate-limiting how many orphans one account can adopt in a short window, account age or 2FA thresholds before adoption rights kick in is closer to the anomaly-detection bolted onto npm and PyPI after their incidents than to "editorial review."
Also npm and PyPI do have paid security teams, automated scanning, and reputation systems — and they still get hit by attacks regularly. The fix proportionate to this incident is tightening the orphan-adoption pipeline specifically, not a generic call for more oversight that nobody's volunteering to staff.
And at the end of the day, the AUR is exactly that, the Arch User Repository. Emphasis on User. I liken it to Windows or macOS in some ways like when we download and install an app from a random website not fully knowing if the developer is trustworthy or not - but they have a program we really need/want. The AUR just allows those developers to put all those random programs into one repo for the Arch Linux user.
The AUR is however an official Arch Linux infrastructure: it lives at aur.archlinux.org, runs on aurweb (which is itself an Arch Linux project on their GitLab), and Arch Linux Developers and Trusted Users have real administrative authority over it — they can ban accounts, delete packages, and roll back malicious commits. That's what happened with Atomic Arch: Arch devs banned the attacker accounts and purged the malicious commits within hours of the first reports on June 11.
What Arch does not do is vet the content before it's published. There's no pre-publication code review, no required sign-off from a Trusted User, no automated scanning baked into the submission pipeline. Any registered user can submit a new PKGBUILD or adopt an orphaned package, and it goes live immediately with zero gatekeeping — which is precisely the mechanism Atomic Arch exploited.
So the official AUR disclaimer "AUR packages are user produced content, use at your own risk" — is itself an Arch-published statement. Arch owns and administers the platform and will act on reports after the fact, but it explicitly does not endorse, review, or take responsibility for what gets published to it. It's like "Arch runs the building and has keys to every room, but doesn't inspect what tenants move in until someone complains" than "Arch has nothing to do with it."
So to say "Just pasting a boiler plate warning about use at your own risk, is not sufficient in 2026" is a fair statement. However, given the nature of the repo where I think most people who use Arch know and understand the risks. Moreover, to bring the AUR more in line with the official Arch repo's with vetting of packages and so forth would be a monumental task requiring tons more work and expense at this point. I'm not sure anyone is willing to take on an effort of that magnitude.
But there are some things that the Arch folks could do to increase security for the AUR. They could add publishing delays and then have some automated scanning done on the packages before being made public. They certainly could, and should, do something about the orphaned packages being adopted by anyone without some kind of screening done first.
throAU
macrumors G4
The whole supply chain thing is a big problem and not just linux.
npm, pip, powershell, etc. all encourage end users to install software from untrusted sources.
This is exactly why apple and microsoft are trying to direct you to their app stores (amongst other reasons). Its not just for monetization but also to protect you from unvetted software.
its a huge problem with vibe coded apps at the moment too. claude/codex/etc. will pull in random dependencies from wherever to make the app easier to build. and inadvertently pull in malware from untrusted sources.
its the wild west at the moment.
npm, pip, powershell, etc. all encourage end users to install software from untrusted sources.
This is exactly why apple and microsoft are trying to direct you to their app stores (amongst other reasons). Its not just for monetization but also to protect you from unvetted software.
its a huge problem with vibe coded apps at the moment too. claude/codex/etc. will pull in random dependencies from wherever to make the app easier to build. and inadvertently pull in malware from untrusted sources.
its the wild west at the moment.
S.B.G
Moderator emeritus
I’ll argue that the AUR has always been the Wild West, not just at the moment.
throAU
macrumors G4
Yeah i was referring to unsigned software repos in general, not just AUR.
Windows admins trusting random powershell scripts from random repos are the next frontier, mark my words.
SevenTheGamingKitty
macrumors regular
I want to be a linux main so much, but it also has too much issues to ignore. (mostly a lot of distro specific issues, but it appears every distro has issues of their own)
splifingate
Contributor
As ThrowAU said, off-the-reservation repo/supply-chains (including Homebrew on the Mac!) greatly increase a User's attack-vector.
It's not the 'distro' per-se, but how we use it. "linux" just allows us to see (and do) things with a granularity not usually allowed/available with major vendors.
I have faith that my trusty router running a seasoned version of Debian will ensure that no weirdos other than I can use it outside of the scope that I've defined. It also helps, I believe, that access is only allowed with a pre-configured SSH key.
Faith comes in many forms . . . wherein sits the trust when we drive a car at 100km/h down a busy two-way road? 😉