SANS Stormcast Monday, June 15th, 2026: Arch Linux Malicious User Packages; Splunk Vuln and Exploit; Exploiting AI Coding Agents

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9972.mp3

previous

Arch Linux Malicious User Packages; Splunk Vuln and Exploit; Exploiting AI Coding Agents

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Monday, June 15, 2026 edition
 of the SANS Internet Storm Center's Stormcast. My name is
 Johannes Ullrich, recording today from Jacksonville,
 Florida. And this episode is brought to you by the SANS.edu
 Graduate Certificate Program in Cyber Defense Operations.
 Well, and sadly, yet again, we have to start the week with a
 supply chain compromise. And this one is a little bit
 different. It actually affects a popular Linux distribution,
 Arch Linux. Now, Arch Linux has this system they're
 calling Arch User Repository or AUR. This is a place where
 users can essentially create their own packages. So these
 are not official packages that are delivered as part of Arch
 Linux. And then of course, with a lot of these open
 source projects, there's always a risk of packages
 being abandoned and then no longer being maintained. So to
 solve this, Arch User Repository has a system where
 a package can be marked as abandoned, no longer
 maintained. And then any developer can step up and
 basically take on ownership of this particular repository.
 Now, many of them, of course, are hardly used. But what
 happened here with Atomic Arch, this campaign that
 Sonatype here wrote about is that attackers picked
 abandoned packages that were somewhat popular. And then
 instead of modifying actually the code in the package, what
 they did is that they added a code to the post-install
 script in the package. And that's sort of then how they
 basically added the malicious code. They just had an npm
 install atomic lock file, then also minimist and chalk that
 they installed. Now the atomic lock file part is what gave
 this particular campaign the name atomic arch. So just by
 altering this package built, they're unable to basically
 install the malicious file. The package itself still works
 as before. So the victim is really not noticing anything
 wrong. Interesting attack. And of course, as an Arch Linux
 user, you should be careful here. I've seen some of these
 malicious packages being removed now. Of course, that
 also then breaks dependencies and such, which is always a
 problem. We have talked about this before about the supply
 chain attacks. But yes, there's something like 400 or
 so packages that are potentially being impacted by
 this. I've also seen numbers of 1500 being affected because
 as always, once you have a couple being affected, that
 maybe dependencies to other packages, well, it quickly
 sort of balloons out of control. And last week, Splunk
 published a critical vulnerability in its log
 management system. Well, we now got a write up from
 Watchtower walking us through all the details, what exactly
 went through here and how to exploit it. So this certainly
 increases the urgency of applying the necessary
 patches. The problem here is that anybody who can access
 your Splunk instance essentially has
 unauthenticated full access to that system. The vulnerability
 is in the Postgresql sidecar. Now, what it really means is
 that there is a Postgresql database that can be installed
 along Splunk and there is an API endpoint in Splunk that
 you can then use to trigger backups and restores in that
 Postgresql instance. The problem is that these requests are not
 authenticated and that due to essentially a directory
 traversal issue, these backups and restores can basically
 access files anywhere on the file system. So with that,
 it's easy to, for example, create new databases or
 override credentials and essentially gain full access
 to the system, including remote code code execution.
 The exploit is relatively straightforward. Again, it
 does require access to Splunk. Now, according to Watchtower
 Postgresql, this Postgresql sidecar is installed by
 default if you're using the AWS version of Splunk. If
 you're installing it on -premise, it's an option. It
 may be installed but is typically not enabled in the
 on-premise version. And yes, Postgresql only listens on
 loopback but because the access then happens via the
 Splunk API, it essentially then proxies the requests to
 Postgresql. And researchers with the tenant Threat Labs have
 published a blog post that outlines a problem that we've
 seen in a number of very similar constellations. So
 this does not affect the particular products that are
 being mentioned in this blog post. But it's really sort of
 a wider problem. And that's when you're having
 automatically generated bug reports or bug reports
 generated by users automatically being picked up
 by coding agents in order to fix these bugs. And no
 surprise, you sort of run into this prompt injection issue
 where you are mixing the data that you received from the
 user with essentially the code governs your AI coding agent.
 Well, that is exactly what the blog post about. They're
 looking at it from perspective of Sentry. Sentry is one of
 those bug pipeline issue tools that helps you basically
 collect the bugs. And then act on them. And yes, it also
 comes with its own AI agent that is then supposed to
 automatically fix the bugs. But well, by creatively
 creating bug reports, you're actually able to create
 arbitrary changes to the code and also to execute arbitrary
 code on the system. So please be careful with this and don't
 necessarily just feed unfiltered bug reports to
 these coding agents. Because I don't think there's a quick
 fix necessarily for this problem at this point. Well,
 and this is it for today. So thanks for listening. Thanks
 for liking. Thanks for subscribing. Talk to you again
 tomorrow. Bye. Bye.