SANS Stormcast Thursday, October 29th, 2026: ClickFix Campaign Targets macOS and Windows; EDK II UEFI PXE Pre-Boot RCE (CVE-2026-97631); Qwen AI Model Data Exfiltration; LiteLLM Master Key Leak

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/10156.mp3

previous

ClickFix Campaign Targets macOS and Windows; EDK II UEFI PXE Pre-Boot RCE (CVE-2026-97631); Qwen AI Model Data Exfiltration; LiteLLM Master Key Leak

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 Thursday, October 29, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from Denver,
 Colorado. And this episode is brought to you by the SANS.edu
 Graduate Certificate Program in Purple Team Operations. In
 Diaries Today, Brad was able to capture yet another ClickFix
 campaign. This particular ClickFix campaign does again
 use fake Cloudflare verification pages. Now it
 does also target macOS and Windows. While Brad wasn't
 able to retrieve the particular malware being
 distributed by this tool, Brad was able to capture a number
 of different URLs associated with this campaign. So
 definitely something that you can use for threat hunting.
 And yes, you'll find a list of indicators of compromise in
 Brad's diary from today. And the next story, well, I think
 it's one of those odd stories that's very severe
 vulnerability, but then some of the reporting I think has
 it made more severe than it actually is. So I want to talk
 about this just to sort of tell you a little bit how bad
 it really is and who really has to worry about it. And
 that's a pre-boot remote code execution vulnerability in EDK II
 PXE driver. So PXE booting is when you're booting an
 operating system across the network, always a little bit
 of risky thing. Not too many people do it, but it's often
 used in large server farms and such. So certainly an
 important feature and yes, quite widely used. The problem
 here is that affected systems and there are literally
 millions of them out there. If during the boot of the
 operating system, the system does receive an ICMP error
 message, this ICMP error message may trigger remote
 code execution. And that's certainly a very severe
 problem because this also bypasses many other
 protections like for example, secure boot. So all the
 attacker has to do is send ICMP error messages that can
 happen remotely, does not have to be network adjacent to the
 victim machine, but the vulnerability is only
 exploitable while the system boots. And of course, well,
 systems don't boot all the time. In particular servers
 we're talking about here, they're only booting very
 rarely. And that makes the exploit opportunity window
 here very brief. On the other hand, the attacker may be able
 to trigger a reboot using another denial of service
 vulnerability. And then of course, this becomes very
 exploitable for a system that is affected. So what should
 you do? Well, if you never heard about PXE, if you're
 never booting across the network, don't worry. If on
 the other hand, that's sort of how you run your network,
 that's how you run your data center, then be very worried
 and do update quickly. Like even if the attacker can't
 predict a system booting at a certain point in time, they
 could just send ICMP error messages sort of continuously
 to your network. And they don't have to be doing this
 very fast. And at one point, they'll get lucky and hit your
 system in the right moment and be able to trigger the code
 execution. Now, there are also dependencies, of course, the
 attacker has to know a little bit more about your system in
 order to make this exploit reliable. But then again, it's
 definitely a brute forceable. Now, if you're experimenting
 with AI, one of the big concerns, of course, is always
 data exfiltration. If you're sending confidential data to a
 remote AI model, there's a good chance that your data
 will end up in training data or may leak. Otherwise, and
 there have been many examples how bugs or bad intentions on
 the side of the entity operating the AI model have
 led to the leak of confidential data being sent
 to these AI models. One way around this, of course, is to
 run a local AI model. In that case, the data doesn't leave
 your network and you have more control over how your data is
 being used. At least that's the idea of running an open AI
 model. But remember, running an AI model really also means
 executing code on your system that is part of the AI model.
 And researchers from Cohere, an AI security company have
 found that that Qwen, the Chinese AI model, that's
 probably one of the sort of most frequently used local
 models, has had a tendency to occasionally leak data to
 various storage locations in Alibaba's network, the creator
 of Qwen. They're talking a little bit about what triggers
 that particular behavior and how that data exfiltration may
 happen by, for example, including these upload
 locations in URLs that are then being passed to tools
 like curl. But what they're a little bit open about, and I
 think that's good, so is whether or not that's actually
 intentionally or whether that's really just sort of
 careless training of the model. Because after all,
 well, it was trained by Alibaba, so they probably
 ended up with a lot of Alibaba URLs during the training. And
 it may just be sort of a leftover of this training that
 did actually lead to this behavior. They're also talking
 about how they were able to sort of trigger this behavior
 more reliable. There have been sort of over the last month
 multiple reports of this, but no real sort of reliable way
 to actually reproduce this behavior. And sticking with AI
 for the last story, we do have a new vulnerability in LiteLLM
 with a CVSS score of 10. This vulnerability really sort
 of gets to the core of what LiteLLM is trying to do.
 LiteLLM is a proxy, and organizations use it in order
 to control access to various AI models from within
 their organization. So the LiteLLM instance typically
 holds access keys for various AI models, and then makes
 these available via the proxy functionality to different
 users, but does not actually reveal those keys to these
 users. And that's sort of a critical piece here. The
 vulnerability here is an arbitrary file read
 vulnerability. And what that of course leads to is that an
 attacker will be able to read these files that store these
 credentials and with that can read the master key for for
 LiteLLM or any of the keys being used to connect to these
 AI models. So definitely keep LiteLLM updated. And yes, in
 particular, if some of the users that you're proxying
 through LiteLLM may not be necessarily trusted by you.
 Well, and that's it for today. Thanks for listening. Thanks
 for liking. Thanks for recommending this podcast and
 talk to you again tomorrow. Bye.