Malware in openconnect-sso hit from 29th July 2026

[lenucksi]

There's apparently been an attack on the openconnect-sso package. This time putting a dropper in the aur-repo and the build() phase.
It appears that the matching offending commit has been reverted in AUR.

Unfortunately there are no real stable indicators to scan for. The matching offending binary however still seems to be available in AUR as deeplink.

Reports:

• https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/PR77K3SB6RFSTYP3KYOJOOX56SMXGBWO/
• https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/PMATLG676MPBWUJPZZ75WJ4H3BKE7TVL/

Affected package:

• https://aur.archlinux.org/packages/openconnect-sso
• Brief analysis attempt with Claude by an AUR user: https://claude.ai/share/d8111b00-156c-405b-9faf-85631176092b
• Offending commit: https://aur.archlinux.org/cgit/aur.git/commit/?h=openconnect-sso&id=9d107786fa851c6305dadb3573aab5330a041524

Since there's not much of real reliable value to be done here, I'll just leave this up for reference and warning.

[dreirund]

meshcore-open-git seems have gotten a similar attack.

[lenucksi]

There's a good sum other other reports on the mailing list. Looks like this is a new campaign, this time against the build-step.

• https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/REPZMFIQW5OKPJY35DGBLH2QATHBDKFK/
• https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/ODRWS5QRNVVYDAIWHDYJPQPPRRWIOALD/
• https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/Y6HKUGIEL4C6Z3E33IFILTGQ2VQAPNKG/

Someone made a tool that checks packages by scanning the AUR online apparently.

• https://wtako.net/services/aur-audit (via: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/BU6RECTA5DTJBL7Q4NQI5T3AKIN2FWSF/
• Be careful, keep your eyes open. I checked a few results and what it reports did not look wrong. Do check for yourself though. Just because it is/is not in there does not mean it/is not safe.

[lenucksi]

Fun thing: There's various names beyond validator for the malware. Always included as a separate file in the sources, sudo in build step, see here for example, 'assembler'. @dreirund had it as 'optimizer'. Structure otherwise similar.

• https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=autoadb-git

[Saren-Arterius]

There's a good sum other other reports on the mailing list. Looks like this is a new campaign, this time against the build-step.

* https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/REPZMFIQW5OKPJY35DGBLH2QATHBDKFK/

* https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/ODRWS5QRNVVYDAIWHDYJPQPPRRWIOALD/

* https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/Y6HKUGIEL4C6Z3E33IFILTGQ2VQAPNKG/

Someone made a tool that checks packages by scanning the AUR online apparently.

* https://wtako.net/services/aur-audit (via: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/BU6RECTA5DTJBL7Q4NQI5T3AKIN2FWSF/

* Be careful, keep your eyes open. I checked a few results and what it reports did not look wrong. Do check for yourself though. Just because it is/is not in there does not mean it/is not safe.

I own the aur-audit tool, and sorry it's being very overwhelmed right now and it cannot give out a comprehensive list at this moment. Also, it's LLM based so there will be false negatives and positives. A definitive way for this wave is to pull all recently updated packages and scan for <100kb elf in the repo.

[lenucksi]

I own the aur-audit tool, and sorry it's being very overwhelmed right now and it cannot give out a comprehensive list at this moment. Also, it's LLM based so there will be false negatives and positives. A definitive way for this wave is to pull all recently updated packages and scan for <100kb elf in the repo.

Hey @Saren-Arterius , thanks for the quick reachout. I figured that your tool would be LLM based. Do you happen to have a SHA256s of all the attack binaries or could generate one in a way that is risk-free enough for you? Or could throw an API (JSON preferred) onto your tool that would allow this one here to query it?

Also, possibly interesting, if you could distill if there's more than just this 'add the dropper to the sources and a line to the build step' approach there. And possibly a timeframe of when the first commit appeared with that pattern. - that might allow to create a regex'd deterministic variation of the scan more easy.
If you do a complete run, incremental scans could turn out to be cheaper.

And just out of curiosity: What model do you run this on? Sounds like somthing that might even run on-prem or with the cheapest mode of DeepSeek V4 Flash or something similar.

[Saren-Arterius]

I own the aur-audit tool, and sorry it's being very overwhelmed right now and it cannot give out a comprehensive list at this moment. Also, it's LLM based so there will be false negatives and positives. A definitive way for this wave is to pull all recently updated packages and scan for <100kb elf in the repo.

Hey @Saren-Arterius , thanks for the quick reachout. I figured that your tool would be LLM based. Do you happen to have a SHA256s of all the attack binaries or could generate one in a way that is risk-free enough for you? Or could throw an API (JSON preferred) onto your tool that would allow this one here to query it?

Also, possibly interesting, if you could distill if there's more than just this 'add the dropper to the sources and a line to the build step' approach there. And possibly a timeframe of when the first commit appeared with that pattern. - that might allow to create a regex'd deterministic variation of the scan more easy. If you do a complete run, incremental scans could turn out to be cheaper.

And just out of curiosity: What model do you run this on? Sounds like somthing that might even run on-prem or with the cheapest mode of DeepSeek V4 Flash or something similar.

Hi there. Unfortunately I am getting 429'd by AUR while trying to download recent 1000 packages to check which contained the malicious binary, the 429 also affected my scanner server.

According to a security researcher https://gist.github.com/ysf the SHA256 of every dropper in this wave is 2d25d2ea313767fae5808164224cf6ad610ab09546d1e5a6f033eedbfd98a281. Currently one live sample is on https://aur.archlinux.org/cgit/aur.git/commit/?h=windscribe-cli-v2-bin but I found the dropper sha256 has changed to e73a35b3e75e94746428d1a207703d6335933deadee7d1d9c9d0328df7b9df77

Yes the model is on my on-perm GB10 device, running qwen 3.5 122b int4fp8. It's not 100% accurate and it made me found out in 30 minutes right after first attack. Check API JSON docs here, but I recommend use it as a reference and not to rely on: https://wtako.net/services/aur-audit/docs

[lenucksi]

Coverage by iFin here: https://discourse.ifin.network/t/new-aur-attack-prompts-adoption-lock/698

Different SHAs seem to still use the same Tor endpoints

[lenucksi]

The campaign seems to have yet again quite the extent and seems sophisticated. The AUR people have disabled up and download of packages as it appears, even for existing package maintainers.

What would be useful is the following:

• A list of confirmed infected packages, based on the mailling threads
• A list of suspicious AUR accounts.
• Of course PRs for checks based on ysfs analysis are also welcome

I might work building such things too when time allows for it.

[dreirund]

At least any `sudo` execution in `PKGBUILD` could be checked automatically.

[lenucksi]

The check of the PKGBUILDs online was something that @Saren-Arterius provided with the llm. There could be a regex-based check, sure. And it would probably be a good thing to enforce certain check rules on AUR directly for newly uploaded PKGBUILDs. However, once they're known, they'll be circumvented.

Since the tool here does not have access to the PKGBUILDs, that led to package installation we have to go by lists and IoCs.

There's https://github.com/manticore-projects/aurscan who tries to do a a-priori check of PKGBUILDs with LLMs.

[mrbigmouth502]

This could be a starting point for building a list. https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/P4WIRHTFNH2YZWQHGBAKQWX5YOAFIDLY/