SANS Stormcast Monday, September 14th, 2026: Self-Expanding Stolen LLM Gateways; PAN-OS Vuln; OpenAI Hacked Ruby; Passkey Themed Social Engineering

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

previous

Self-Expanding Stolen LLM Gateways; PAN-OS Vuln; OpenAI Hacked Ruby; Passkey Themed Social Engineering

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Something to note on the PAN-OS CVE. The writeup states that the dataplane interface is also at risk, not just management. There's some vagueness in the description, but it can be read that if the firewall is just inspecting traffic. It may be at risk.

Posted by Larry on Mon Sep 14 2026, 14:57

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Monday, September 14, 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
 Penetration Testing and Ethical Hacking. Renato wrote
 a follow-up to a story that he sort of broke a couple weeks
 ago. And the initial story was just about hackers are
 scanning the internet, trying to find OpenLM endpoints. And
 then they're using or reselling those endpoints in
 order to essentially get AI inference capacity for free.
 Or even make money of it by reselling this capacity. Now,
 the latest attack that Renato has seen is not only them
 using these bots to scan for OpenLM endpoints, but once
 they found them, they will aggregate them under a
 combined API. So that, of course, makes the entire
 resale operation a lot simpler. But then they're also
 using that aggregated API to then have their agents find
 more OpenLM endpoints. So essentially, the inference
 capacity that they're accumulating makes their bots
 smarter, makes it faster, makes it easier for them to
 find more exposed endpoints. Really interesting find here
 how you sort of have these, well, I don't want to call
 them quite self-replicating, but definitely sort of self
 -reinforcing agents that are harvesting LM inference
 capacity by finding these OpenEndpoints. From a
 defensive point of view, hey, have you ever heard of
 authentication? It's still a thing, even though everything
 is AI now. You still want to have some credentials to
 connect to your LM endpoints. In particular, of course, if
 you're then forwarding them to some of these fairly expensive
 models. And on Thursday last week, Palo Alto did publish an
 urgent security advisory. Now, how urgent is this depends a
 little bit on the particular version of the Palo Alto
 Networks firewall you're running. But in the worst
 case, this vulnerability in the XML processor can lead to
 remote code execution as root. In some of the models, it's
 only a denial of service condition. So that's
 definitely then less of an issue. But if your firewall is
 in the, well, execute code as root category, you probably
 want to get this fixed quickly. Now, an attacker does
 need to have access to the control plane. You better
 don't expose that. But of course, a compromised
 administrative workstation or such could certainly then be
 used to launch the attack, even if there is no direct
 exposure of the firewall's control plane. And back in
 May, some OpenAI agents apparently published hundreds,
 if not thousands, of malicious packages to RubyGems. This was
 now revealed by Spencer Kitz, Thomas Larsen and Sidney Fun
 Arks. The three of them being researchers who now basically
 created a write-up of what exactly happened. So in this
 particular incident, the malicious packages that were
 uploaded were, first of all, trying to steal API keys by
 exploiting vulnerability in the RubyGems server. They also
 abused RubyDoc.info in using it to essentially acts a
 proxy, kind of like a server -side request forgery, where
 RubyDoc, that's a service that will build documentation. In
 order to do so, it has to reach out to various websites.
 So that's where the server -side request forgery comes
 in. And yes, then also interesting that these agents,
 which apparently weren't directly, at least, controlled
 by a human, were also then labeling some of their files,
 things like hack.rb or evil .rb. So certainly being
 somewhat self-aware, as the post points out, that what
 they're doing is probably not a good thing. Nevertheless,
 they went ahead and did it. Anyway, so if you're using
 Ruby, take a quick look at this post, particularly
 whether or not you downloaded any packages during that time
 frame, maybe were affected and maybe had your API keys
 exfiltrated. Probably best to change them. And Microsoft
 published a blog post about an attack they have seen recently
 that, well, in some ways used passkeys, but it actually
 didn't exploit a vulnerability in passkeys. If anything, it
 exploited a vulnerability of not using passkeys. Microsoft
 calls this a passkey-themed attack. And essentially what
 happened here was that attackers just used passkeys,
 or the word passkey, I should say, as a ruse to get people
 to fall victims to some of the better kinds of phishing
 websites. Remember, any website where the user decides
 what credential to present is susceptible to phishing. So
 multi-factor authentication, like even the app-style
 authentication, isn't necessarily phishing resistant
 if a website gives you a number that you're supposed to
 enter into an application or that you're supposed to
 acknowledge. Now, what happened here is that
 basically the user was tricked into authenticating with the
 phishing website by claiming that, hey, they must get a
 passkey now. No passkey was ever issued actually here. And
 that then tricked the user into actually falling for the
 phishing site. So poor user thought they do something good
 for security, but got tricked again. From a defensive point
 of view, well, use passkeys. Use them legitimately. Use
 them before the attackers tried to use this ruse
 because, well, they are still phishing resistant. So this
 attack, again, did not attack weakness in passkeys. It
 really more was standard phishing. Well, and this is it
 for today. So thanks for listening. Thanks for liking.
 Thanks for recommending this podcast. If you're interested
 in any of my classes, check the show notes for a link or
 just the sans.org website and talk to you again tomorrow.
 Bye.
 Bye. Thank you.