DEV Community: Amayo Clinton

The AUR Supply Chain Attack: When Trust Becomes the Vulnerability

Amayo Clinton — Thu, 18 Jun 2026 07:02:46 +0000

This Month, the Arch Linux community discovered that more than four hundred packages in the Arch User Repository had been quietly hijacked. The attackers did not exploit a bug in any software. They exploited something harder to patch: the trust that builds up around a package's name and history.

What happened

The Arch User Repository, commonly known as the AUR, is a community driven collection of build scripts maintained separately from Arch's official repositories. Anyone can adopt an abandoned package whose original maintainer has stopped updating it. That openness is exactly what this campaign relied on.

Researchers at Sonatype, who named the operation Atomic Arch, found that attackers were systematically adopting orphaned AUR packages, the ones whose maintainers had simply walked away. Once in control, they edited the PKGBUILD or install scripts to quietly run a command during the build process: npm install atomic-lockfile. That single line pulled in a malicious npm package alongside a couple of legitimate ones included for cover. The npm package carried a preinstall hook that dropped a bundled Linux binary named deps, and simply building the AUR package was enough to trigger it.

To make the changes look legitimate, the attackers also spoofed git commit metadata so it appeared the edits came from a long standing maintainer. An Arch Linux Trusted User later confirmed that maintainer's account had never actually been compromised. The packages kept their familiar names and commit histories. Only the build instructions underneath had changed.

What the malware actually does

Independent researcher Whanos reverse engineered the deps payload and identified it as a Rust based credential stealer built for developer machines and build systems. Once running, it can pull cookies, session tokens, and local storage from Chromium based browsers including Chrome, Edge, and Brave. It also lifts session data from Electron apps such as Slack, Discord, and Microsoft Teams. On top of that it harvests GitHub, npm, and HashiCorp Vault tokens, OpenAI and ChatGPT bearer credentials, SSH keys and known hosts files, shell history, Docker and Podman credentials, and VPN profiles.

The stolen data is exfiltrated over HTTP to the file sharing service temp.sh, while command and control traffic runs through a Tor onion service via a local loopback proxy. For persistence, the malware installs a systemd service set to restart automatically. If it landed with root access, it copies itself into /var/lib/ and installs a system level unit. Without root, it falls back to the user's home directory and a per user systemd unit.

There is also an optional eBPF rootkit component, though early reporting overstated its role. It does not grant any privilege escalation and only activates if the binary already has root and the right capability. When it does load, it uses pinned BPF maps to hide the malware's processes, names, and socket inodes from standard monitoring tools, and it actively blocks debugger attachment. A second, unanalyzed binary tied to a fake monero wallet GUI package was also found staged alongside the stealer, suspected to be a cryptominer.

This combination matters for remediation. A package manager can remove the files it installed, but it cannot prove a machine is clean once a rootkit capable payload has had the chance to run.

Scope and a second wave

Sonatype's initial report counted just over twenty compromised packages. Within a day, community trackers and the Arch mailing list had cataloged more than four hundred, with one list built by scanning the AUR git mirror directly landing around four hundred and eight, and later consolidated counts climbing even higher. Notably, the malicious atomic-lockfile npm package itself had only around one hundred and thirty four weekly downloads before it was pulled from the registry, meaning the AUR build process, not direct npm installation, was the real distribution channel.

A second, separate wave surfaced using the command bun install js-digest, traced to a different set of npm accounts that community researchers link to the same publisher behind atomic-lockfile. Its payload is a distinct binary by hash, also confirmed malicious. The full extent of this second wave is still being measured, since grep based searches of the AUR mirror return different totals depending on how much commit churn is included, but it is not a minor footnote to the first wave. Anyone checking their system should look for both atomic-lockfile and js-digest.

What to do if you use the AUR

Arch maintainers are resetting the malicious commits and banning the implicated accounts, and they are asking the community to keep reporting suspicious packages through the mailing list thread. For anyone who has built or updated an AUR package since June 11, the published list of affected packages should be treated as incomplete rather than authoritative.

Practical steps worth taking include checking recently built or updated AUR packages against community maintained detection lists and scripts, and searching build history and caches for references to npm install atomic-lockfile, bun install js-digest, or the payload path src/hooks/deps. If any flagged package was built on your system, the safest assumption is that the host is credential compromised. That means rotating browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams, and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud access keys.

It is also worth hunting for persistence mechanisms directly, including unrecognized systemd services both at the system level and under a user's own systemd config directory, unexpected files under /var/lib/, and the presence of pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes under /sys/fs/bpf/. Reviewing outbound network connections for Tor traffic or uploads to temp.sh is another useful signal. If a compromised package was built as root, the recommendation is to treat the rootkit as present and reinstall the system from trusted media, since there is no reliable way to confirm a clean state otherwise.

For detection purposes, the primary payload's SHA two fifty six hash is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b, and a fuller set of indicators, including the onion command and control address, has been published in the ioctl.fail writeup.

The bigger lesson

This is not the first time an abandoned package has been weaponized this way. A similar tactic was used against an abandoned PDF viewer package back in 2018. What makes the 2026 version notable is the scale and the layered payload, combining credential theft with an optional kernel level hiding mechanism rather than relying on typosquatting or tricking users into installing the wrong thing entirely.

Sonatype is tracking the campaign as Sonatype 2026 003775 with a CVSS score of 8.7, though no CVE has been assigned since this is fundamentally a trust and process failure rather than a software vulnerability. The real takeaway for anyone using community package repositories is that a name and a commit history are not proof of safety. A package that has recently changed hands, or one that has suddenly become active again after long dormancy, deserves the same scrutiny you would give to software from a complete stranger. Reading the PKGBUILD and any install hooks before building is no longer optional diligence. It is the only line of defense the trust model has left.

When AI Gets It Wrong: The Hidden Security Risk of Hallucinations in Cybersecurity

Amayo Clinton — Sun, 17 May 2026 13:18:42 +0000

AI systems are getting better at detecting threats — but what happens when they confidently give you the wrong answer?

Cover image suggestion: A glitching neural network visualization or a cracked padlock with circuit board texture.

AI is rapidly being embedded into security operations — threat detection, incident response, log analysis, vulnerability triage. The efficiency gains are real. But there's a category of risk that doesn't get nearly enough attention: AI hallucination, and specifically what happens when it occurs inside a security context.

This isn't a hypothetical. It's a pattern already emerging in production environments, and the consequences can range from alert fatigue to catastrophic data loss

What Is AI Hallucination in a Security Context?

AI hallucination refers to when a model generates outputs that are confident, fluent, and factually wrong. Unlike a crash or an obvious error, hallucinations look correct. The model doesn't flag uncertainty — it just answers.

In low-stakes contexts (drafting an email, summarizing a document), a hallucination is annoying. In a security context, it can be catastrophic.

Here's why that matters: security teams are trained to trust their tooling. When a SIEM or AI-assisted SOC platform flags an alert, analysts act on it. When an AI recommends a remediation step, engineers often execute it. The trust relationship that makes AI useful in security operations is the same relationship that makes hallucinations so dangerous there.

Three Ways AI Hallucinations Become Security Incidents

False Positives That Erode Trust

When an AI system repeatedly generates false positive alerts — flagging benign behavior as malicious — teams naturally adapt. They begin treating alerts with suspicion. They start skipping review steps. Over time, the entire alerting pipeline loses credibility.

This is the alert fatigue problem at scale. And the insidious part is that it doesn't require the AI to fail dramatically. It just needs to be wrong often enough that humans stop believing it — at which point a real threat will look exactly like every other false alarm.

False Negatives That Create Blind Spots

The flip side is equally dangerous. AI systems trained on historical threat data can fail to recognize novel attack patterns — zero-days, new malware families, unusual lateral movement techniques. A model that has never seen a particular attack vector may simply not flag it.

The problem is amplified when teams have calibrated their response processes around AI-assisted triage. If the AI doesn't raise an alert, the threat may never receive human attention at all.

Incorrect Remediation Guidance

This is arguably the most dangerous failure mode, because it happens after trust has already been established.

Imagine: an AI correctly identifies a threat. The analyst trusts it. They then ask the AI what to do about it — and the AI confidently recommends deleting sensitive files, modifying critical system configurations, or disabling firewall rules.

If those actions are executed — especially via privileged accounts — the result can be:

Identity-based attack exposure from weakened access controls
Lateral movement enabled by disabled network segmentation
Irreversible data loss from confident-sounding but incorrect deletion commands

The attack surface doesn't just remain open. It widens. And the team may not realize the AI was wrong until the damage is already done.

Why This Keeps Happening

AI hallucinations in security contexts aren't a single-cause problem. They emerge from a combination of factors:

Training data quality. Models learn from historical data. If that data contains outdated threat signatures, biased datasets, or inaccurate records, those flaws surface in the model's outputs. As AI-generated content becomes more prevalent online, there's a growing risk of future models being trained on content produced by earlier hallucinating models — a compounding phenomenon sometimes called model collapse.

Prompt quality. Vague inputs give models more room to fill gaps with assumptions. A security analyst asking "what should I do about this?" gets a very different (and often less reliable) output than one asking "given this specific log output and these network conditions, what are three targeted remediation steps with rollback options?"

Over-trust in model confidence. AI models produce confident-sounding outputs regardless of accuracy. There's no built-in signal for "I'm not sure about this." Teams that don't build human review into their workflows have no circuit breaker.

What Teams Can Actually Do About It

These risks aren't reasons to avoid AI in security operations. They're reasons to deploy it thoughtfully. Here's what effective governance looks like in practice.

Require Human Review Before Privileged Action

AI-generated recommendations should not automatically trigger sensitive operations — infrastructure changes, access modifications, incident response actions — without human verification first. This applies even when the AI seems right. Models produce equally confident outputs whether they're correct or not, so the review step cannot be conditional on "something seems off."

Build this into your runbooks and your tooling, not just your policies.

Treat Training Data as a Security Asset

Your AI is only as reliable as what it learned from. Regularly audit the data used to train or ground your AI systems. Remove outdated threat signatures, biased datasets, and known inaccurate records. As AI-generated content proliferates across the internet, continuous data governance isn't optional — it's a prerequisite for reliable model outputs.

Apply Least-Privilege to AI Systems, Not Just Humans

If an AI system recommends deleting a file, it should not have permission to delete that file. Apply the same least-privilege principles to AI-driven systems that you apply to human accounts: read where reading is enough, no write access where writes aren't required, no delete access anywhere it isn't explicitly necessary.

This way, even if a hallucinated recommendation makes it through review, the blast radius is bounded by access controls.

Invest in Prompt Engineering for Security Teams

Output quality is heavily shaped by input quality. Security teams that interact directly with AI systems need to understand how to write prompts that are specific, verifiable, and actionable — not because prompt engineering is magic, but because vague inputs systematically increase hallucination risk.

Train your analysts not just to use AI tools, but to evaluate AI outputs critically. The mental model to instill: the AI is a fast, confident junior analyst. Always review their work.

Put Identity Security at the Center of AI Governance

Most AI hallucinations become security incidents at the moment of action — when an AI system or a human trusts an incorrect output enough to execute something. This is fundamentally an access problem.

The question to ask in your architecture review: if the AI says the worst possible thing and someone believes it, what's the most damage that can happen? Work backward from that to design your access controls, audit logging, and review requirements.

Security architectures that enforce least-privilege for both human and non-human identities (NHIs), monitor privileged activity, and require verification before sensitive actions are taken give organizations meaningful protection even when AI outputs are wrong.

The Bottom Line

AI in security operations is a force multiplier — for better and for worse. When it works, it catches threats faster than human analysts can. When it hallucinates, it can create the conditions for a breach while appearing to be managing one.

The answer isn't to distrust AI. It's to be precise about where trust is warranted and what safeguards exist when that trust is misplaced.

Human review requirements, least-privilege enforcement, data governance, and prompt engineering discipline aren't obstacles to AI adoption. They're what makes AI adoption survivable.

Have you seen AI hallucinations cause real problems in a security context? Share your experience in the comments — this is a space where practitioner knowledge matters a lot.

[Boost]

Amayo Clinton — Sun, 26 Apr 2026 12:46:42 +0000

Dishon Oketch

Apr 26

Your Guide Into the Development World: A Roadmap for Absolute Beginners

#codenewbie #webdev #programming #beginners

5 min read