
The Low Down· Staffel 1· Folge 18
Black October Recap, OpenCode’s Stolen API Keys, AI Distillation & the LiteLLM Supply-Chain Attack
Dienstag, 3. November 2026 · 1 h 24
Kapitelklicken springt direkt hin
Shownotes
Welcome to The Low Down, the best show on the internet for hackers
Black October has real bugs, stolen keys, and a lot of very loud headlines.
Ed and Matt sort through PHP2Shell, AI security claims, and the difference between a scary vulnerability and one attackers can actually use. Harry Wetherald, co-founder and CEO of Maze, joins us to talk about finding the bugs that matter.
——————————
Today we're talking about:
PHP2Shell and the Black October panic
We get into working exploits, questionable proof-of-concepts, patching, and the reporting around attacks. Ed breaks down why configuration and exploit reliability matter, while Matt revisits a report he shared that was later corrected.
• Original research: calif.io/php2shell
• Exploit validation: vulncheck.com/blog/php2shell-vulnerabilities
• Unit 42 report and updates: unit42.paloaltonetworks.com/cve-2026-109618-cv…
• unit42.paloaltonetworks.com/cve-2026-109618-cv…
• DREAM intrusion research: dreamgroup.com/blog/chained-php2shell-exploit-…
AI security with Harry from Maze
Harry joins us to talk about what AI can do for security teams, how to decide whether a vulnerability is exploitable in your environment, and why producing more findings isn't enough.
• Maze: mazehq.com
Brotli, Node.js, and GoAhead
A decompression bug puts Brotli in the headlines, then GoAhead gives us a lesson in broken TLS. We talk through the technical details and the conditions that turn these bugs into real problems.
• Node.js security release: nodejs.org/en/blog/vulnerability/october-2026-…
• GoAhead research: foxio.io/blog/choose-your-backend-three-tls-bu…
OpenCode, stolen keys, and distillation
OpenCode's Console incident leads to a discussion about stolen API keys and model distillation. Matt revisits his initial response and the distinction between stealing keys and what attackers intended to do with them afterward.
• OpenCode announcement: x.com/opencode/status/2111519637049319818
• Matt's clarification: x.com/mattjay/status/2111554937452990593
LiteLLM, Railway, and the update problem
More supply-chain trouble raises an uncomfortable question: how quickly should you update when new releases can carry the attack? We get into credential exposure, dependency hygiene, and the tradeoffs of waiting.
• LiteLLM attack-chain report: docs.litellm.ai/blog/security-incident-oct-21-…
• Railway incident report: blog.railway.com/p/preliminary-report-october-…
WPS, pre-boot bugs, and AI bank access
We cover Broadcom WPS research, an EDK II PXE vulnerability, and AI agents accessing bank accounts. The banking discussion turns on whose permission was given: the customer's or the bank's.
• WPSplinter research: qkaiser.github.io/broadcom-wps
• EDK II advisory: github.com/tianocore/edk2/security/advisories/…
• AI banking report: axios.com/2026/10/22/ai-agents-banks-unauthori…
We finish with the noise around security news, incident-response fatigue, and what happens when every week is treated like the end of the internet.
Recorded October 28, 2026.
Linked reports may include later updates.
Listen on Spotify!
hgo.lowdownpod.com/spotify
The Low Down is presented by Maze.
LinkedIn: linkedin.com/company/mazehq
X: twitter.com/Maze_Security
Follow Us!
instagram.com/lowdown.pod
——————————
Ed / Low Level
Instagram: instagram.com/lowleveltv/
LinkedIn: linkedin.com/in/lowleveltv
YouTube: youtube.com/@LowLevelTV
Matt Johansen / Vulnerable U
Instagram: instagram.com/mattjayy
LinkedIn: linkedin.com/in/matthewjohansen
YouTube: youtube.com/@VulnerableU
Transkriptvom Podcast bereitgestellt · Zeitmarken springen hin
I just heard gunshots outside. Is this PHP? Open code got hacked. Is that why these sirens are outside? Cybersecurity experts are calling in Black October. I think the branding of Black October is a little dramatic. All of these things ended up being not as big a deal as they kind of were advertised to be.
E. Mudra, Certificate of Authority, during their key generation ceremony, I wish I had some candles and crystals and then we could meditate a little bit. Generate the key, make it bigger than the number four. Now... We have a completely unrelated story, not even a week later, where another private key having to do with PLS is the number four again.
Four has become the six seven of cybersecurity, which is so funny. What the hell happened? Good morning, hackers. Welcome back to the best podcast on the internet for hackers, The Lowdown, presented by Mays. We are unfortunately no longer in Las Vegas. You're back to my basement and Matt's office, but we had a great time in Vegas.
Matt, how was your OneCon experience, man? How'd it go? The only unfortunate part about not being in Las Vegas anymore for me personally is those sick cameras. We got footage of the episode that came out. Yes, Sentinel-1 had like a $10,000 podcast set up. That's not what I have. I was so mad at this guy.
I was like, this guy's going to cost me $20,000. And I was like, no, Matt, the video footage is not why your YouTube channel isn't popping off. You know, like it's you, it's a skill issue. It's not that it's not an 8k anyway. Yeah, no, we had a good time, man. Really impressed. Never been to a conference at the ARIA conference center.
Yep. Nice conference center. Sentinel one put on a tight show, man. Like they had really, we popped down to their like university breakout sessions. On the lower level that first day, I looked at all of the titles of all the different talks and not even like computer low level, like basement. So, but pop down all of the titles of all the tracks that were going on were like exactly what should have been happening this week, which is usually hard to do when you pull off a conference to like have timely...
like sessions, you know, because you're planning it so far in advance. Right. Like no, no, they did really good to like break it out into like AI offense, AI defense, like securing AI, like, you know, all that kind of stuff was really, really good. And it seemed like we popped our head into a bunch of them and it seemed like they were really doing hands on lab type stuff.
So that was awesome. We wanted to go check it out, but like every room we went into was very quiet. Everyone was like deep in the weeds. It's like, all right, I don't want to interrupt people likely in their flow state. Right. So no, no, thanks. But it looked like they were having a good time. So it was cool.
And then the the eSport thing was just I blew my expectations out of the water. You know, I'm thinking like live hacking competition, generally not very fun to watch. They nailed it. They nailed it. Go watch last week's episode if you have not. We interviewed the winner of that competition and you can kind of see some footage from the con in there.
And we should probably put out some, like we took some B-roll and stuff. Like we should probably just put out some more onto social, like onto our social channels, just so people get the vibe of the conference overall. Good job. Yeah, it was a great time. Yeah, it takes a big personality to make competitive hacking actually interesting.
I've been in like those competitions and they are not fun to watch. Yeah, but you know what happened like while we were in Vegas? Cybersecurity Awareness Month. Listen up, everybody. We heard that you were trying to not be cybersecurity aware and this is what happens. This is what happens when you don't listen.
When you try to not be cybersecurity aware, this is what we have to do. We have to rebrand it to Black October. Yeah. So, guys, if you weren't aware, right, like, basically the day we landed in Las Vegas, there were, like, three or four, like, major industry-disrupting disclosures regarding, like, PHP, Node.js, OpenCode got hacked, a certificate authority had the private key four on some other intermediates, like...
Not great. That being said, I think the branding of Black October is a little dramatic, and we'll go into why all of these things ended up being not as big a deal as they kind of were advertised to be. Still not good, obviously, but this isn't like, you know, the Black Tuesday for cyber. Like, we're kind of pinning it up to be.
You know what it's giving? You know what it's giving? What's that? Mythos It's giving mythos It's giving mythos It does play a role We will go into that But like It ain't that big kid It ain't that big chief Dude it has a Wikipedia page It must be big It must be real It must be really bad The vulnerability has a website Therefore it must be legit guys That's how this works To date myself really quick, I've been writing blogs and recording content about breaches weekly going back to 2009.
Weekly. Wow. 2009. I don't want to know where you are again. I don't want to know. Freshman in high school. Okay. Okay. Okay. But yeah, I like wrote for this blog, LiquidMationSecurityDigest. I actually, I did a daily news roundup on that blog of like links because we didn't have, you know, Daily is bonkers in 09.
That's fucking crazy. Yeah, dude. I did like on a blog because that's how we all got our news was RSS feeders and blogs. And I would like do like a roundup of all the different security news of the day. breaches were part of it. Then we started a podcast for Liquid Matrix. I couldn't even tell you what year.
It was before podcasts were cool. It was when the name podcast still made sense because you were listening to it on an iPad, iPod. And we did over a hundred episodes of that. And we had a section in our show notes called breaches. And so every week when we did record that podcast, we talked about breaches.
This is not new. This is not new. A bunch of vulnerabilities came out. A bunch of really crazy vulnerabilities came out this week. They got patches. Yeah. End of news cycle. Like, I mean, there's stuff to talk about. Like, the industry is changing. AI is changing the speed of things. Like, got it. But...
Like, to say that, you know, the floor is falling out from this stuff. The Japanese prime minister declared a state of national emergency and told people to stockpile cans of food and water because of PHP vulnerabilities. I got DMs of people screenshotting their emergency alerts going off on their phone because, like, police activity down the block or whatever, like, stay inside.
I got DMs saying, is this why I'm getting this alert? Yeah. Is there police activity around the corner because of PHP? Because of PHP. That's crazy, dude. We have missed it. We have jumped the shark. We have missed the plot. I just heard gunshots outside. Is this PHP? Like, what the fuck? Open code got hacked.
Is that why these sirens are outside? Dude, it's absolutely bananas. We have lost it. We've completely lost the plot. So I do want to talk about some PHP stuff. Bring it back. You did your PHP video live from your hotel room. Baller. Respect. I didn't bring my YouTube set up to Vegas. I did mine yesterday to kind of do the zoom out like aftermath type video.
We talked about PHP stuff as we knew it live in Vegas on the podcast that's already out from last week. I think it's really valuable to look at this as a case study in what the hell is going on in this industry and the reaction and all of this kind of stuff and exploitation. Did you see this live tracker that Census put out?
No, I don't think so. All right. Live tracker of what? Okay, so this is the PHP 2-Shell live global dashboard. Basically their version of a PewPew map. If you guys don't know Sensus, they're like a Shodan competitor, I guess. There's a few of these companies out there that scan the whole internet and kind of like make everything that they find available via their API and dashboard and whatever they find.
And it's almost like a search engine for just devices on the internet, right? And so, of course, census can then fingerprint vulnerable versions of PHP that are exposed on the internet. So they've got this great dashboard, php2shell.census.com. So super easy dashboard you can pull up. Fairly live tracking.
I think they said they could be like a few hours behind. Fairly live tracking of vulnerable versus patched PHP servers live on the internet. At its peak, like when the bug came out October 21st, or I guess when the patch came out, because I think the bug leaked the 20th, right? Mm-hmm. when the patch came out the 21st, there was 43 million, 200 something thousand vulnerable PHP servers on the thing.
It's a big effing number when we're talking about these things. Usually headline making vulns, if you guys don't track vulns for a living like we do, headline making ones could be in the tens of thousands of like things and people would still be freaking out. So 43 million is a very, very big number.
That's a couple. That's a few. Yeah. The first two days after I saw this tracker go live, the internet at large was patching 4.3 million servers a day. So the first two days, 4.3 million, 4.3 million. I was like, okay, if this is telling us anything about the pace of patching, we should be pretty good.
Obviously there'll be like a long tail or whatever. That third day, boom, 300,000 or something like that. What was it? 600,000, then 300,000, then 200,000 and 300,000. So we've like gone from 4.3 million to a few hundred thousand patches per day, which is still, like I said, 10,000 vulnerable servers would have been a headline making news story.
We're patching hundreds of thousands a day. Cool. We still have 32 million servers to get through as a collective internet to like worry about with this volume out there. Yeah, that's still a lot. Yeah. Yeah. So I thought that that 4 million pace was going to be pretty cool. It's not, right? The saving grace here is, and I kind of want to pick your brain about this too, because you know a little bit about the exploit and you've kind of looked into it.
Why aren't we seeing as much active exploitation about this? I kind of want to talk a little bit before I pass it over to you. Yeah. We... we saw a lot of like POC type stuff come out with the vuln announcement, right? So I was like, this is going to be bad because we're seeing POCs, the patch isn't out yet.
It turns out a lot of those POCs were AI generated slop, hallucinations. The models thought they had an exploit. So the researcher thought they had an exploit and the researcher or the model weren't good enough or smart enough to realize that they did not have like a working POC is really what a lot of those videos were.
That being said, the original researcher. And then now I'm seeing a number of other researchers. I think some of the first two I saw was like Volncheck and Trail of Bits came out and said that they have production grade, like working exploits on a bunch of different versions of stuff. So it is possible, right?
It is possible. Even with ASLR, even with all sorts of protections, the exploitation is possible even at scale, it seems to like write, if they're calling it a production grade POC. Um, we haven't, we were not seeing any confirmed active, active exploitation for a few days. Then the first word I saw of it, and I need to apologize, uh, you know, say sorry, basically to everyone on this.
I amplified it. Unit 42 from Palo Alto networks, who I think is one of the better threat intelligence teams on the planet, uh, put out that they saw active exploitation of this, right? Uh, a few days ago. on the 24th. Okay. So this is still just like three days after patch comes out. Unit 42 says active exploitation.
The article was worded a little bit weird and you can even see my tweets go like some people were responding to me. So like I reposted unit 42 researchers saying active exploitation. I was like, there we go guys, active exploitation. I trust these people. And people were responding like, that article seems a little weird.
Seems like it doesn't say that. And I responded, I was like, you're right. It is worded weird, but I'm just kind of trusting that unit 42 is unit 42. They have since walked this back. They were wrong. So I got to talk to some people, try to figure it out. Seems like, like a team there saw a PHP server be exploited.
And then they were going through a bunch of post exploitation stuff in that blog. And they just kind of jumped to say, oh, well this must've been PHP to shell. Right. And whatever. And they, and they've walked it back. So we've had like a lot of misinformation about active exploitation. Now we, we, we have some that seems pretty legit, right?
That like exploit is happening now we're recording this on the 28th. So like, seems like in the last few days it's starting to happen, but I I'm surprised we're not seeing more. What's, what's your thoughts on this whole thing? Yeah, I guess. So to set the stage, the trend we're going to kind of highlight in today's podcast is like over since like over, um, central centralization over over sensationalism, I guess is the word.
It's kind of a trend that's happening right now because security is like so in the zeitgeist. AI is making security the hot topic. So when a thing comes out like an exploit in PHP that affects 70 percent of the globe, it's going to catch a lot of wind. The problem with this vulnerability is that it is an extremely complex memory exploit, right?
So I'm not going to cover it too deep in detail because we talked about it in the previous episode, and I want to repeat myself, but the PHP to shell exploit, is a use after free vulnerability because of PHP's use of the long jump function, which basically is a way in C of if you encounter an error state, you can use long jump to return to a saved context, a saved state that you were previously in.
So it's like, okay, we set the state here. We go into a function that is fallible, right? If it fails, we call long jump return over here. That returns the program's instruction pointer, stack pointer, and registers all back to where it was previously. The problem is the RAM and the other global variables of the function or of the running program are the way that they were after the failure, right?
So if you don't properly account for all of the ways a program can fail, you can have some logical issues that happen here. The PHP to shell bug was basically when you are initializing a session during a file upload, if that file upload fails and causes a PHP allocator to go out of memory, the session is still partially initialized, but it's freed.
But then a further on request uses that freed session. So you can use that vulnerability to do an arbitrary read, arbitrary write, bypass ASLR, and do your code execution. The problem with that, though, is that a use after free, most of the time, depends on a very precise grooming of the heap so that when your next allocation comes in to fill that freed slot, you know what structure it is and you know that you control that structure and at what offsets you control that structure.
The issue is PHP is such a low-level, name of the channel, by the way, thing in the stack of the web frameworks, right? WordPress, Drupal, Joomla, whatever, um, And every unique implementation of PHP, or not implementation, rather, every unique usage of PHP, and all of them can be behind an Apache 2 reverse proxy, an NGINX reverse proxy that are all going to mangle the requests in different ways.
Those change automatically. the memory shape, the heap shape of the exploit. On top of that, you have different versions of PHP. You have different versions of the frameworks that all can depend on different versions of PHP. You have this graph explosion of basically the different kinds of memory states that your program can be in.
And it's important to remember too that hackers aren't clairvoyant. Like, you know, sometimes we like to think we are, right? But we don't know. Like maybe we can fingerprint your WordPress and your WordPress is WordPress. I'm making up a number, 7-Eleven. I have no idea if that's real or not. But that WordPress 7.11 can be riding on PHP 8.2 and making it more numbers, which also was reverse proxied by Nginx 4.3.
Again, more fake numbers. So that combination of version numbers causes a unique heap shape that is not just universally fingerprintable. I'm sorry, Matt, you were talking? What? No. Hey, man, those are all real numbers. Okay. Three and four and three and four. Okay. To make sure I'm not saying numbers that aren't real.
Okay. So ultimately, the bug is real. The bug is bad. But A, it takes a lot of information that may not be publicly disclosable to reliably exploit it. And two, the bug is hard. So even if you have all of those pieces of information, it's not necessarily just a free... Command injection, right? Even in the Kalief leak that we saw the video of him, the person that found the bug running the exploit, it said attempt number one of eight, because it's not just like a get in, get out.
You have to sometimes crash the daemon and hope the heap is in the right shape before you can get in. And that's assuming there's no other traffic, right? Because, again, I'm not sure about the worker to heap layout. But it may be the case that you are sharing a worker with another person on the Internet talking to that server, and they're also manipulating the heap.
So it's like if you don't lock that worker to just you, that also influences things. So real bug, real scary, but not real easy to exploit. Yeah, and there's a lot of debates going on right now of if, since it's so hard to exploit, is this as serious as we were all making it seem? And I think the consensus is like, well, yes, right?
Like, yeah, because 32 million vulnerable things, right? And because now we're starting to see some of this actual weaponization of this bug to be used as the initial access vector for complex intrusions, right? We have an example. I didn't want to share this because I got a little gun shy on the unit 42 thing.
Right. I was like, oh, I shared something from someone I trusted and I got burnt. And this is from a group that I do not know. Right. It seems like this is for some research team over at dream dream group. Looks like they do like sovereign AI for governments. Got it. So didn't know, not familiar with the team, but I do have some, again, some other people I trust that said this is legit.
So like willing to talk about it now, but it seems like we do have some evidence of chained vulnerabilities in the first in the chain being PHP to shell exploit, rooting 25 servers, including US government servers is the title of the article. We read through this research. Wait, wait, wait. Ed, you said that you're not clairvoyant, but just last week, in the example when we were talking about how pointing the electron super vuln-finding microscope at PHP found more vulns, the example you used was something called dirty frag, where that happened.
You were like, yeah, it was kind of like dirty frag, where it came out and we found a whole bunch of other things like it. I thought you weren't clairvoyant. That is the volume that was used in one of those variances. It was used to chain in this exploit that we're seeing against an unnamed firewall vendor.
We have seen some headlines of some firewall vendors that are running PHP, maybe with or without ASLR sometimes, too. A lot of stuff. Don't know if that has anything to do with what we're talking about here. Citrix? Citrix or Palo, unfortunately, right? So in different versions of some stuff. Obviously, as we keep talking about, we might as well have a section on the podcast called Edge Device Breach of the Week, right?
These are highly targeted things. They're deployed. The code is... you know, written in C. I mean, there's just tons of stuff, right? Reasons why they're highly targeted. So this one, because of all that memory stuff that you just outlined, it seems like this exploit has some techniques here to do some memory exhaustion to force a predictable memory layout.
But you said that that may or may not be accurate. on this research, but at least they are acknowledging that that is part of the trickiness of exploiting, but it seems like this weaponization had an answer to that and this chain. Can you go into this research a little bit? Yes, I was reading this, and so they said predictable memory layout, right?
That could mean one of two things. When you say predictable memory layout, you're trying to effectively bypass two issues in the way that allocators work that tend to get in the way of exploitation, right? The first one is, you know, address space layout randomization. So basically, if an attacker gets control of a pointer or the return address...
The question is, where do they point it to, right? If you want to do an arbitrary read or arbitrary write, you have to put a known good value in that location to do the hacking. What ASLR does is it puts the base address of a page, a new allocation by the kernel, at a random location so that you don't know what memory address to fill in that location.
What they could be asserting here is that they're allocating a ton of stuff to reduce the overall entropy of ASLR, right? ASLR only has an entropy of... Oh, God, what is it? It's like you're missing the bottom 16 bits, and you're missing the top 16 bits. You get total addressable entropy of, like, I think it's 32 bits.
So in 64-bit land, 32 bits. In 32-bit land, it's, like, much less. You get, like, maybe four or five bits of entropy. It could be them trying to bypass ASLR by reducing the available page address range. I think what's actually going on here is this is them doing the heap grooming I was talking about, right?
So when you're doing a heap grooming, You are trying to throw enough data at the program where you are hitting allocations that you know are going to occur to cause the heap shape to be a certain way. What you're doing is creating what is called a hole in the heap so that you know when your next allocation occurs, it's going to land in this exact location.
Um, this is done so that you know what structure you will control in the use after free case where you have the pointer that points to the freed thing. You need to put data there that you control in a certain shape. And so this is them, in my opinion, um, using large amounts of data to heap the groom to maintain that control.
I don't see a world where they're attacking a device where these pieces of data would enable them to bypass ASLR. It just doesn't make sense to me. Either that, or like we talked about before, they're landing on a firewall. This could be a firewall that just doesn't have ASLR enabled, right? A lot of embedded devices, even in the year of our Lord, 2026, um...
just don't have it on. I think we've seen Citrix doesn't have it on. The Palo Alto VMs don't have it on, but the hardware devices do. A lot of devices that run MIPS just like, oops, don't enable ASLR. I don't know why. So in my opinion, the chances of this being an ASLR bypass are low, but very likely heat grooming.
Or it could just be them hiding their exploit in chaff, right? They could be trying to obfuscate where their shit lies in the actual exploit itself. So there's a You know, a couple different things that could be going on here. There's different TTPs, but who's to know? So super interesting. It does seem like this research may or may not have gotten on the attackers kind of like operational boxes, right?
Because they're seeming to have some information about the actual campaign that you wouldn't get from just the compromised boxes. So super interesting. The other thing that I thought was kind of crazy, because you don't see this a whole lot, and especially crazy because it's PHP to shell, is... is the initial access vector to the firewall is p2shell plus the Fragnesia thing, that dirty frag variant, right?
Then from the firewall to continue the exploit into the network, they use p2shell again. onto the next box. So they literally use it twice. They use it once with the frag thing. Then they use it again to get onto a management server and root that. So even not your internet exposed PHP things, we now have proof.
Like your internal PHP type stuff is now that's being used to get onto that box. And then they pivoted all the way to domain controllers via some LDAP bug. I want to highlight, though, I tend to dunk on embedded companies because their software tends to be not very good. But what I will notice that I didn't think about until just now, they had to use Fragnesia, which means that the web server is not running as Root.
We did it. We did proper operating system enforced user control. Holy shit. It only took 26 years. So that's kind of cool, right? It's ironically that the firewall got rooted by an actual LPE, but the server landed as root. Completely backwards. Yeah, yeah. So they got on the server and apparently they had a stored LDAP credential and they decrypted the LDAP credential, which gave them the ability to land as the system on the DC, which is not great.
Yeah. So I think that it's time. I think it's time to fly in an expert into this episode of the lowdown and talk about Black October and what we're seeing and how this is all changing in AI exploitation land. What do you think? You think it's time? Let's do it, man. Bring it in. Harry, welcome to the podcast.
Appreciate you coming on, man. You know, pretty boring news week, as I'm sure you've heard. Not like really a lot going on in the cybersecurity space. Before we get into all these bugs and what AI is doing to the industry, can you kind of kick us off with an introduction? What do you do? Who are you?
And what's your shtick? Yeah, of course. Yeah, good to be here, guys. Yeah, I'm Harry. I'm co-founder and CEO of Maze. For those who don't know, we're a new application security company, pretty much. So, as you can imagine, using AI to figure out in code, where are the vulnerabilities, either understanding a CVE, right, like of the thousands that you might have, which of them actually matter to you and how do you fix them?
And then we're also using the same... technology to go and find vulnerabilities where we didn't know about. So like what kind of people are trying to do with Mythos, but a lot cheaper and a lot more efficient effectively. So we do a wide range of things, a bit like Sneak or that kind of space in the past, but a modern take on the same idea.
Nice. Awesome. That's a great space to be in right now because as I'm sure you're aware, there are a couple bugs, one or two, not a ton. I spent the last two weeks on Twitter Seeing people go, like people outside of security usually, but they're like, man, someone should really build an AI product to solve this problem.
And I'm just there scrolling like, yeah, I'm here. Hey, don't mind me. Yeah. So one of my favorite questions to kind of kick off these kinds of conversations, I've talked to some other founders in your space, right? There's a few. If you go to the black hat floor, the booths are getting crowded. And a few years ago, there was like some mumblings of AI, then everyone kind of had to have a story and now everyone's an AI company, right?
You guys were an early mover in the space. What are you kind of seeing? Like, why is AI getting so good at finding bugs? And how are you differentiating from like security company that is doing this for a living versus like what the frontier models can do out of the box? Yeah, yeah, yeah. It's true. Like, if you go around Black Hat or anything similar now, all the big companies have chosen one of two lanes.
Either they're pretending to be an AI company since they were founded, you know, 20 years ago. Or if they can't figure out a way to sell that story, they just say, we were built to secure AI. Like, that's, everyone is one of those two lanes. I like that. So it's, like, tricky for us, I guess, sometimes to stand out.
But, yeah. Yeah, I guess, so I was working on machine learning products before LLMs came out. So kind of come from that old, older world. And I guess as a company, what we've tried to do is say AI agents are ridiculously powerful. Even very early versions of them back in like 23, 24 were clearly going to completely change our security work.
Because you could finally have this thing that could go and crawl through all the contexts that you might care about. Every security tool until then basically was limited by not understanding the full context around a situation, right? It was screaming at you, let's say, about a PHP vulnerability that you had in your environment and tell you that it's the most urgent thing in the world, not knowing that there was a bunch of context around it that meant it wasn't exploitable or similar.
But the, I guess, premise of what we're trying to do is to say those agents are also really hard to get right at scale. So if I want to run one once on my own machine, I might get an interesting result once. Yeah. But if I want to scan every line of code, every piece of cloud infrastructure, I want to do it every single day for the rest of time.
And I want to make sure that my results are almost 100% accurate. And I want them to be affordable in some moderate sense for an enterprise. That is a really hard challenge. And so we just lean in headfirst into that challenge and say, there's actually a ton of software you need to build around the models to make the most of that challenge.
And so that's what we specialize in. Nice. So it's not, hey, Mythos, find me a zero day, make no mistakes. It's actually a lot of tooling that goes into this. Yeah, exactly. Well, loads, yeah, and they can find impressive things doing that. But when you compare, like, basically what we find is like every month that you put into building...
software and ways of handling the data crucially around the models, you basically get like step changes in both accuracy and cost efficiency, the more the more kind of built around them, which is why always makes me laugh when people just like hook up a latest front end model and say, great, we do security now because yeah, you do and you'll find interesting stuff, but it'll be like riddled with false positives, it'll be different results day after day, and it'll be astronomically expensive most of the time.
Was it Tom or Steve, Matt, that was telling us that their board directed them to use a frontier model? They heard investors basically telling companies, make sure we're using frontier models. And it's like, okay, and? Like, what else? What would you like me to do with this? It's such a buzzword right now.
It wasn't their board. It was their customers. So they were running into it, but their customers' boards were mandating frontier model usage. And the quote that he said that's just been rattling around in my head is that they've never seen a board mandate MFA, but now they're seeing the board's mandate model usage to stay on top of cybersecurity type things.
And I was like, yeah, that's a really good point. And the headlines are really driving a lot of the narrative here. There's a lot of conversation right now about where this goes as the limit approaches infinity, right? As time goes on, where does software go? There's kind of the one attacker mindset, which is like we just find all the bugs and it's the Wild West for the rest of eternity.
But then the logical counter to that is like, well, we also find all the bugs and the bugs go away and software is secure and we live in utopia. Yeah. Where do you think this runs, right? Do we live in a more secure software environment, or do we just go back to the 90s for the rest of eternity, right?
How does this land? Yeah, it's interesting. I'm sure you guys saw, there was a bit of chatter online recently about this, this idea of like volume zero, which is this idea that we're just going to eventually eradicate all the bugs. You know, we'll just use LLMs to go back and improve all of, all of like history software.
And then going forward, we're just not going to write any new ones. And there's, there's like a, there's a little bit of truth in that, right? Because coding agents are clearly getting so much better. Certain classes of vulnerabilities, I think we probably can almost eradicate. But at the same time, like what problem in security have we ever solved like fully?
Usually zero of them because there's always like you're always fighting this kind of like actor on the other side that basically is just using the same technology you are. And so it's a bit like, I guess, like turning up to. Yeah. you know, the first person to invent the gun and they turn up to like a sword fight and they're like, right, well, I've won all fights forever, ever more now.
Sure. And not realizing that like the next wave of people are going to come back at them with guns and the next way we're going to come back with FFV, F15s and whatever it might be. So I think we're going to find ourselves in a similar spot where, uh, basically the types of vulnerabilities that we all have languishing our backlogs today, some of those might go away.
But logically then what you would see happening is the models are just going to be just as good on the attacking side. The models are good enough to write perfectly secure code and secure all our code perfectly. Then they need to be incredibly good at distributing and generating attacks. Those attacks are then orders of magnitude more complex than the ones we understand today.
And the thing that my co-founder Santiago always says is like, there is no such thing as perfectly secure code. There's like perfectly secure, like snippets of code, right? Like an individual piece of code can be in theory perfectly support secure, but put it in a sufficiently complex system and you can never perfectly secure it because you don't know what all the interactions in that system are going to look like.
And so the idea that we're just going to spit out loads of perfectly secure code kind of fails to acknowledge the fact that actually the really hard to find vulnerabilities are these really subtle things that pop up in big complex systems. And there's just no way that we're gonna be able to, you know, completely eradicate them.
So sadly, probably we're gonna solve some of the problem. We're gonna get a new problem pop up somewhere else. And you know, everything's gonna probably feel the same as depressing as that is. I think this transitions really nicely into what's turning into one of our favorite questions to ask people around like the AI attacker versus defender asymmetry, right?
And I know like I've always really hated the mantra of like defenders have to be right all the time. Attackers only have to be right once because like it's not really true when you pull the thread. Yeah, they only need to be right once to get in, but then they can get caught immediately. Like, you know, there's zero days are not invisibility cloaks, all that kind of stuff, right?
But when it comes to this conversation that we're having, right, it seems like right now we are in an AI attacker is beating AI defender, power defender, finger on the scale of the asymmetry, right? there's definitely first mover advantage to the AI attacker, right? And less bureaucracy in their organizations to be able to use these new things to get better at finding whatever it is that they're finding.
You, as someone who's on the, like trying to help the AI-powered defender side, how do you see kind of this asymmetry playing out like long-term? Is this like forever in the attacker's advantage or how does this go? Good question. Yeah, I agree with you on the fact that the whole asymmetry thing doesn't quite stack up.
Because the other thing is the defenders have all the data as well. Attackers are trying to get in blind. Right, right, right. All the information on their own environment. So there's a massive asymmetry there. So last week, on Tuesday, Wednesday, I was writing a blog post. And the blog post was all about where are all the AI attacks?
Yeah. And it was all about how there's not actually been that many of them. Where are they? What's going on? And then obviously all the news here. And I was like, I think this is maybe not the time to post this. But in that research that I did, there's been like very few cases of like documented AI-based attacks.
So someone clearly using an LM or a series of agents. There's been a few more in the last few weeks, as you guys have probably seen. But I compared it to Felony Bench. The thing that shows how many felonies OpenAI and Anthropic and everyone has committed. Yeah, so good. I did my best job of trying to find all the cases of real AI-based attacks in the world, and I counted them, and then I counted all the items on FelonyBench across OpenAI, Anthropic, Google, etc.
There's 23 felonies by the actual AI labs, and there's 23 confirmed cases of actual AI-based attacks So like the accidents and the real stuff is head to head, apparently. Obviously, that always hides stuff. There's always way more, you know, looking at the surface that we don't know about. But it is kind of weird.
We actually haven't seen that many yet. The only thing I can rely on here is that maybe attackers actually, in most cases, are not as numerous or as sophisticated as some of us like to think. You know, some of us like to think that maybe, like, you give them enough power and we're just going to have, like, endless attacks around the world at all times.
But there's still a lot of work required. Like initial access, you can automate exploiting a phone, let's say you can automate maybe even doing a bit of a bit of moving around a certain environment. There's still a load more work left to do on top of that. Like, let's say you want to extort someone, you still need to contact that entity.
You need to figure out how to extort them out of some money. You need to take the criminal risk of going through that process and not getting found, you need to communicate within your own network. Like there's still... Just because AI makes the attack a bit easier doesn't make the whole situation just effortless is maybe one argument for why we haven't seen a bit more of it.
But yeah, I think that asymmetry, the more negative case on the asymmetry is it actually just takes them a while to build the tools. Like in my past life before Mays, I used to work on phishing. So trying to stop, you know, like really advanced phishing attacks, basically. And what you saw there was that the tech to do pretty advanced phishing at scale was available way earlier than you saw it at scale.
And there was this kind of like wave that happened where effectively people went and they realized that you could spear phish through phishing. like email gateways pretty easily. And they'd realized a way of doing that pretty easily. And they realized a way you could get money from that pretty easily.
And then you saw like a very, very low level of it. And then you saw phishing as a service kits kind of start to come out and you saw like, you know, $2, you know, uh, just put it in a domain and we'll just cover it for you. And then you saw this massive spike of that kind of activity. And I kind of feel we might be in that phase at the moment where basically it takes a while for you to kind of package the tech up and easy to use things that like anyone on.
the dark web can kind of go and use. And we might be about to see that asymmetry start to kind of actually play through a bit more. But it's really hard to know. And it's obviously hard to see because we don't see a lot of the data. It's a really good point. We just saw this week a hacker get caught.
And I guess, yeah, they were only active for a few weeks and only made $210. But they had stolen like a bunch of records and then just like no OPSEC, no actual follow through on the payment or anything like that. They're like VC-backed companies with no revenue. They're like, yeah, we're growing really fast.
You still got monetized what you're doing. So the AI-powered hacker got in, stole some records, but then was pretty bad at being a criminal. You're right. We're starting to see evidence of that for sure. It's funny. Yeah, that's really cool. You know, the more people that we ask that, the more different answers we get.
It's like why it's turning into one of our favorite questions. Because I think a lot of people just at large, if you were to just poll the audience, right, in the industry, I think a lot of people would lean the AI attacker advantage, just long term, that would be their answer, right? But then, yeah, we've talked to a few people who are like in the weeds with customers actually like going up against this.
And they're like, no, I think the defender long term is going to have the advantage here. Yeah, the defender has a massive advantage. The asymmetry used to come from the fact that defenders found it very hard to understand their own environment, right? It was like we had very rudimentary ways of understanding our own environments.
Therefore, the attacker from the outside had the asymmetry of you just need to be right once, as you say. And the defender had some access to their internal data that gave them a bit of advantage in response. And then you kind of, you know, you have to find it out. We now have increasingly almost perfect understanding of our internal environments.
Right. Uh, we have things that can read every line of code in our company for us and understand everything about it, how it all fits together, where the risks might be. We can run like red teaming exercises. Like, uh. essentially ongoing all the time trying to find out what could go wrong. We can inventory what we've got in our environments where all the problems that used to hold us back internally have got a lot easier.
Attackers still don't have all that data. They have to find ways to hack us from the outside using essentially the same techniques, but sped up and made a little bit more sophisticated. So I think it's still going to be Difficult for defenders, but theoretically, AI gives defenders more of an advantage than attackers.
We were talking earlier, kind of dunking on this whole Black Friday label, right? Or Black October, whatever it is, right? Everyone's kind of looking at the last couple of weeks in cybersecurity and being like, we've never seen anything like this. And it's like, we kind of have. And we've kind of seen a whole lot worse, right?
Like, you know, WannaCry, Log4J, people got hacked, right? Like, nothing has really kind of come of this. Do you have any just thoughts looking at the last week about the industry, PHP, the reaction to everything that we're seeing? What does it look like from your point of view? We're kind of starting to look a bit ridiculous, aren't we?
It looks like the fire alarm went off and we all ran out of the building screaming and now we're all stood outside looking at the building still not on fire and like, ah, this is kind of embarrassing us. But yeah, you're right. I think the interesting thing about last week was... It's coming at a time of a lot of just AI doomerism in general.
So it's just like plugging straight into that. And also the nature of the vulnerabilities, they were almost, if you were writing a script and you were trying to write a series of vulnerabilities that would scare the hell out of everyone relative to their actual impact, You would probably go after PHP, which is one of the most widely used things that could have a vulnerability, but its ratio of how widely used it is relative to how at risk it might be for key things around the world is pretty low.
You would maybe go after TLS, just because it scares everyone like the internet is vulnerable. And you would probably set up the vulnerabilities in such a way that a bunch of very visible online websites took their websites down for a while to scare, you know, to, to scare everyone. Right. So it was kind of like, I think, it was almost the perfect storm of what would be the scariest potential set of things happening relative to their actual risk.
And then now still, like I think I was looking up yesterday, I think the two known breaches of PHP, like the major ones that came out from, I think Palo Alto or someone else, they've both been rescinded. And it was like, yeah, it actually wasn't anything to do with it. And I saw something, I think it was Grey Noise today had some honey pots up for the last like week.
And they've just about managed to find one of them get exploited. Yeah. Yeah, by the same threat actor, right? So the number of threat actors actually being skilled enough to wield it is pretty low. Yeah, exactly. Exactly. So, yeah, I don't know what that means for us, because the other side of the equation I fear a little bit is when, like, Mythos happened, and Anthropic obviously just...
like ramped up the scare factor to a thousand. And then when this happens, and again, like people involved, just ramp up the scare factor ridiculously and everyone just, it becomes this big echo chamber and everyone outside of security is, I don't know about you guys, but I just got friends, you know, messaging me be like, Hey, are we all screwed?
Um, And so now that that's happened a few times, the next time, let's say something that is a bit more like Log4j or maybe worse than that happens, and everyone starts going crazy, a lot of people are going to be like, oh, it's just the next scare. And they're not going to actually respond to it. They're maybe not going to put the actions in place so they can respond quickly the next time.
So we're in this quite dangerous loop where actually the overreaction is creating a lot of, I think, for naturally skeptical security people, as many are, it's kind of creating this loop where everyone's kind of turning off to the actual problem. And that might come back to buy us, unfortunately. That's a really good point.
The boy who cried four. Harry, what's your go-to, what's your stack right now, man? What's your, you got a local model running at home, or you went in an anthropic homie, what's your stack right now? Me, personally, I mean, I'm the founder of the CEO, so I have bored, my like day-to-day work is ridiculously boring, right?
It's like Slack and Claude and Granola and a few other things. Internally though at Maze, we use a little bit of everything. We are like the model company's worst nightmares, I guess, because we have endless amounts of infrastructure to monitor very quickly how good the models are, both accuracy and cost efficiency.
So at the moment something tips over, we're just like, cool, we'll just switch over to something else. So we have a great big blend of everything. I think we're a customer of just about all the labs at the moment, which is good fun. Fun and a nightmare at the same time, I'm sure. I'm sure that's got to be complicated to maintain.
That's awesome. All right, man, this was awesome. Thanks so much for coming on. Crazy week. It's, like, good to talk to someone who's, like, literally on the front lines of AI security and code and everything that's, like, literally on fire right now. So... Yeah, it's fine. We'll chat again when we have another crazy week.
For sure. When someone pulls the fire alarm again, we'll call you back. Exactly. All right, good time with you. We'll see you next time. See ya. Hey, hackers, before we keep going, I want to take a quick break and say a quick thank you to our sponsors. Today's Lowdown episode is sponsored by our friends over at Maze.
Maze has spent the last couple of years using AI to find and remediate vulnerabilities in the cloud. And now they've released Maze Code, AI agents that find and deeply investigate vulnerabilities in your code. Now we all know the deal. Software composition analysis tools and SaaS toolings are all historically really bad at just making more noise.
They find issues that may not actually be real and just create a lot of problems for your engineers to deal with that don't solve real security vulnerabilities. I get it. We've been there. Maze code is a really cool tool because Maze code actually knows how your code works. MazeCode investigates every finding with the context of how your code is actually deployed.
Sure, you're using a version of libxml2 that's vulnerable, but the actual code path to hit that vulnerability is not exposed in your Docker image. MazeCode can find that and won't show you that that vulnerability is a big deal. Every vulnerability that Maze code reports comes with evidence that it's real and a way to fix it.
Check out Maze at go.thelowdownpod.com slash Maze. That's go.thelowdownpod.com slash Maze. Thanks again, Maze. Let's keep going. Are we done with Black October? No, we're not done with Black October. There's all these other volumes that we didn't get to while we were in Vegas that is why we're calling it Black October.
That was cool. Thanks, Harry. You're a legend. This was awesome. But Node to Shell. Okay, first of all, can we declare to Shell dead? Can we just stop? Can we just say the Node bug, please? Like, come on. They're all to Shell. It's RCE. Fuck you guys. Like, come on. I gave all sorts of detailed analysis of my feelings of everything going on this week across multiple social media channels, and my most viewed thing was your mom to shell.
That's so funny. Yeah, so to shell. I blame Dirty Cow, bro. Dirty Cow set the precedent that only cool kids with their cool exploits get websites, and then ever since then it's been a shit show. What? Was it that? I mean, Heartbleed and Poodle and Shellshock were all before the... Yeah, you're right.
Heartbleed was one of the first big branding campaigns for sure. When your vuln has a marketing team. Really? So, Node to Shell. And it's funny, the first headline I saw about this one was about Python. And I was like, bro, your Python's got JavaScript problems. What's going on? I heard you like JavaScript, so I put JavaScript in your Python so you could JavaScript while you Python...
Yeah. So it seems like there's a package called, not broccoli, Brotley. Brotley. I've seen broccoli to shell, which is so funny. Yeah. And it seems to be one of those packages that's just squirreled everywhere and is in a whole lot of things. And as opposed to a lot of the other stuff that we're going to talk about this week, this one does have absolutely known exploitation going on right now.
It's in the Sysikev. I'm seeing people I trust be like, I'm finding this on client sites. We got to fix this. What is this one? Yeah. So this is another issue of like a, again, I'm not going to use Log4j. in the way that people want me to use log for a day, but it's similar in the sense that, like, it is a supply chain issue in that you don't know if you have it in your code base potentially, right?
The reason why it's Node to Shell, Python to Shell, Microsoft to Shell is Broccoli, not Broccoli, is a compression algorithm that is created by Google, right? There's a library. You can go look it up. It's open source on GitHub. And Node supports it, right? Python supports it. A lot of these web frameworks that are written on top of these frameworks support Brotley.
And I'm going to say Brotley in accident. You're going to have to deal with it. Compression. The vulnerability is in the decompression, right? So if you are able to send a Brotley compressed malicious stream to a server that is vulnerable to this, the decompression will cause an out-of-bounds write and can cause RCE.
The issue, I think, back to the PHP to shell is the end of the earth branding issue is similarly, this is not a bug that affects everything, right? Like I run a lot of applications that I maintain that are written either with node frontends or are written in Python. I'm a big Django guy. Fuck you guys if you hate that.
Django's a shit. But Node out of the box does not support Brotley, right? But it's called Node to Shell. I was kind of having a panic attack when I was in Las Vegas trying to figure out if I was going to get exploited by this. I didn't. Yeah. So, again, it's real. The vulnerable cases for Node to Shell are if you overtly use the Brotley package in Node.js and consume a Brotley stream with this vulnerable version.
That is bad. Or if you have a piece of code in Node. Say that four times fast. that will go out and run the fetch operation, right? The fetch operation will go out, and, sorry, a fetch operation where the URL is controlled by a user, right, by an attacker, because then the attacker can specify the fetch operation to go out and retrieve a stream that it will then ingest and exploit.
So a couple of preconditions there. Same thing applies to Python, right? It's not out of the box completely. Um... But ultimately, it's another case of, like, name implies worse than actually is. And then even when it's exploitable, it's still a remote memory corruption, which is hard to fingerprint and exploit.
So not good, not that bad. Another kind of interesting part of this one is it was found by OpenAI, like internal during like a red team exercise. They were the ones who found it. They published the initial disclosure on their patchtheplanet.org website about this, right? Oh, nice. So, which is kind of weird because now Sam Altman is coming out and saying, like, I don't think it's going to be possible to patch all the bugs.
It's like, well, you have like a whole initiative about patching all the bugs, right? So, internally. It's kind of concerning that you're saying this right now. Yeah. Well, what's going on over there behind door number three? Yeah. So, yeah. Yeah. again, just like further evidence of there's some like gnarly vuln research going on at Frontier Model land when they're finding stuff like this that's like buried so deep into a lot of different things.
But anyway, hopefully 2Shell dies. It won't. It won't. We're going to read so many more 2Shell things over the next couple of weeks. Code 2Shell. Yeah, just everything. Web 2Shell. Yeah, everything 2Shell. So... We talked about this one in Vegas where E-Mudra, Certificate Authority, during their ceremony, key generation ceremony, I wish I had some candles and crystals and then we could like meditate a little bit.
Generate the key, make it bigger than the number four. Well, now we have a completely unrelated story, not even a week later, where another private key having to do with TLS... is the number four again. Yeah. So not even the same root cause, not even the same, like, oh yeah, they, they, it turns out now that we know about people can stub their toe this way, we found another way that someone subbed their toe.
What the hell happened? I made a tweet where I was like, send me your wacky hacker name, first name, IP address, middle name, username, and last name, private key pen format, please. And every response I got was local host route for just fucking, Four has become the six seven of cybersecurity, which is so funny.
Yeah, this is an interesting disclosure from Fox IO. I've been seeing a lot of their stuff come out about, like, just bugs and everything. So they're talking about this thing called Embed This Go Ahead. It's like a lightweight HTTP server a la BOA or Lighty. Now, the issue in the code base has to do with TLS, right, transport layer security, just like kind of the Emudra thing.
So when I saw something, something, another provider, the number four, I was like, oh, truly this means, surely this means that this device just uses the Emudra CA. That's all it is. It's not a big deal. And, like, no, it is literally a different vulnerability entirely. So what's going on here is if you communicate to a go-ahead web server over TLS and establish a Diffie-Hellman key exchange over RSA, There is a, yes.
Excuse me, low level. Yes. Question from the class. Yes. What's a go ahead web server? Yes. I just said, a go ahead web server is a, uh, in, it's a web server for embedded applications. Powers, powers. What is this? Um, millions of IOT firewall, OT and military devices, um, from Palo Alto, Comcast, D-Link, HP, Canon, Honeywell, GE, Oracle, Siemens, uh, Rockwell, DG, Lockheed Martin, Boeing, and more.
So just those, just those, just a few. Um, so the issue is kind of hilarious. Um, When you create a TLS context, in this case, you're using embed TLS. It is a TLS library for embedded applications. It's much smaller, much more optimized for size than speed. When you establish a context doing Diffie-Hellman, you have to establish the prime, right, the agreed-upon prime that you're going to use to do the key exchange, and the G, the generator, right, to do the number generation so you can have your, you know, your private key and your public key to do the key exchange.
When you use their API, when you establish this configuration, you have to say not only the variable, like the prime number, the pointer to that thing, it's specify the size of that thing. So you say this is a pointer to the prime. This is the size of the prime. This is a pointer to the G value. This is the size of the G value.
The G value is only one byte. The generator, or sorry, the G value is only one byte. The prime number is 256 bytes. It gives you times eight, right? What is that? It's like 2048 bits of entropy. That's great. issue there is that when they put the size of for the Diffie Hellman prime, which should be two, five, six, they accidentally put in the size of the Diffie Hellman G, which is one, which gave the effective length of the prime of the prime number to be one byte, which means that the prime number was only ever the number four the entire time, which means you can take any connection, you know the prime so you can then extract the key information from the session, decrypt the session, and man in the middle all the traffic.
Not great. Not very good. Famous prime number four. Yes, the famous prime number. Exactly. Exactly. So it's not only a bad Diffie Hellman prime, it's Not a prime. So not exactly the strongest Tiffy Hellman. So this is not in a certificate of authority like last week where like, oh, browsers had to rush to pass all of a sudden the wifi pineapple attack gets more interesting.
All of a sudden, like you said, like BGP type interception gets more interesting. What's the actual attack scenario for this one? Obviously we listed a bunch of scary company names that, that this kind of stuff could be found in IOT devices. So this is just, if you have man in the middle on any network, uh, and then traffic is getting negotiated to one of these devices?
Is that the attack? You're just wire-sharking any network? You can decrypt any traffic that goes to these things specifically? Yeah, because of the broken Diffie-Hellman parameter, it's in the article, but basically the established shared secret over Diffie-Hellman when you have a prime of four, which isn't a prime, it reduces the shared secrets down to these numbers, 1, 2, 4, 8, 10, 20, 40, 80 in hex.
So you have a potential eight different key values that can be used over this Diffie Hellman, which is not good. So, yeah, anyone sitting in the middle that can capture encrypted, quote-unquote, traffic between a client and a go-ahead router can be decrypted. And then, yeah, man in the middle, too. Like, you can arbitrarily insert yourself as a trusted authority, right, over an exchange and do whatever malicious stuff you want to do.
Bad, bad, bad, bad, bad, bad, bad. I just literally couldn't believe that it was for again. Yeah. The fact that it's four, again, I thought it was related to Imudra. Like, oh, that means that they're still trusting that CA. No, it is literally a different bug. Do you listen to that? You ever watch Bo Burnham?
Yes. Okay, so when I saw a friend of the show, Ice Solstice, you know, Ice Solstice on Twitter, he was like, what the fuck? It's four again. I pictured that Bo Burnham song about country music. Dirt road. Yeah. Yeah. And when he goes, Oh, that's a scarecrow. And then later in the song, he goes, Oh, it's a scarecrow again.
Again. I, it's one of the hardest I've ever laughed at any comedy special ever again. Right. And, and I've been trying to think of like how to make the meme, like it's the scarecrow again. And it'd be the number four. And I haven't quite figured it out yet, but you know what? I know a funny, a personal fun fact about me.
You know the Netflix special where he shows that song? Yeah. I'm in that special. No. Yeah, dude. When he filmed it in Port Chester, New York, I was there. Jelly. Yeah, dude. It was so good. That is the hardest that I've laughed in my entire life up to that point. So good. Oh, my God. So good. His special Inside during COVID was on repeat in my house.
To just give you a little glimpse into my mental state at that point. It was great, but it was rough. It was so rough. If you haven't watched it, go watch it. And then be like, Matt, watch this on repeat for weeks. Yes, I did. Yes, on repeat for weeks. Okay. So can't believe we're just using the famous prime number four multiple times with the ability to decrypt traffic.
It's a fucking scarecrow again. It's a fucking scarecrow again. One of my favorite jokes. Oh, shit. Okay, so we have some other news from this week, but I did want and we did promise our loyal listeners who obviously were taking notes during our Vegas episode and they would otherwise burn us at the stake if we didn't go cover some of the stuff that we just did not have time to during the famous Black October week.
It would go burn us. They would Bo Burnham, Bo Burnham, Burnham. So there were two other breaches that happened like right around PHP time that I think are even on the Wikipedia page for Black October. Maybe? Yeah, LightLM. Oh, no, Bratley was one. GitLab was one. Emudra. So we talked about all those.
We did not get to talk about these two. So number one, you mentioned it earlier in the show, OpenCode got hacked. I made a standalone video on this. Did you? I forget if you covered this one. I know Prime did. No, I didn't cover it for two reasons. One, I have no details. I don't know what happened. And do I have friends there?
And I don't want to add more media if they don't want it. And I haven't talked to them yet. Sure. Okay. So yeah. Sorry, I'm about to. No, no, no. I had to make a separate video, but talking about it here, I don't care. I'm not going to make a fucking headline like, open code situation is crazy. I'm not doing that.
Sorry, I did. And the guy that you're about to go record with did too. Prime made a really good video about this. And I'm in the Prime video. Did you see my tweet about this? I did. Yeah, I saw your jump scare tweet. Dude, I was watching the Prime video just because I do watch his channel all the time and he's really good at doing the thing that I try to do.
And I'm like, all right, how did he cover? He's covering hacks again. This fucking developer who's really good at YouTube is like doing cyber better than me. Crap, what's going on, right? And then all of a sudden, my face is on it. He screenshotted my tweet. Okay, so yeah, agree. I didn't make a deep dive video on this one for that same reason.
It's like, what happened? We do not know. We still do not know what the root cause of this breach was. Zooming out, what's open code, everybody? It's a way that it's like a harness, right? Is that fair to call it that? Of a way that people use a lot of these local models. Is it similar to Olama? Would you like...
No, I would say OpenCode is like a not-anthropic version of CloudCode. Okay, yeah. Same vibe. Got it, got it, got it, got it, got it. But they also do a lot of hosting, right? So like they not only have their own TUI where you can do CloudCode stuff, but they do a lot of self-hosting, not self-hosting, but like cloud hosting of models for you.
You can use DeepSeek and GLM, I think, for free right now on OpenCode. Not an ad, but hit us up. That's what I was about to say, right? So, like, yeah, you can use it to do these local models, like famously local models, open weight models, like the GLM stuff and the DeepSeek stuff. But they are hosting them, and they caught so much attention the week before their hack because they were giving people free access to these good models that are, by the way, very good at cyber stuff, too, right?
right? GLM 5.3, you've talked a lot about it. Deep Seek 4.1 Flash, really good at cyber stuff. And so, they caught, like, tons of attention and probably their user base went hockey stick over their, you know, ability to use this stuff for free. Dot, dot, dot, two days later, compromise headline, right?
The compromise was blown a bit out of proportion for like the, like I think they said it was like 1% of their user base because it wasn't like, oh, you use open code on your device and like you were using a bunch of stuff, like you're screwed. No, they do have like a console though, like in their kind of web cloud version where you can upload your or tie your API keys to the other frontier models and use OpenCode with the frontier models.
And you could like link it via this console. So that was what was hacked. Anyone who used the console and tied their frontier models, API keys to it, the things that was stolen was users of OpenCode's API keys to OpenAI or Anthropic were what was targeted during the attack. Okay. So the, and the only detail we know was that it was in a legacy on its way to be depreciated system.
We don't know what that means. Like it doesn't matter because obviously production API keys were still in it kicking around for customers. So legacy or not, that's what happened. We do not like, they're like ongoing investigation. We can't say anymore. Okay. Right. I hope that they do put out some more transparency around like what actually went down.
Then they started their announcement on it was that this was due to a distillation attack. And this is the tweet that I made that wound up in the prime video was, how does a distillation attack on open code lead to API keys of your customers getting stolen? If you guys are unfamiliar, distillation attacks are what frontier models are undergoing from a lot of the Chinese models.
Anthropic and OpenAI are basically pointing fingers at a lot of these open-weight Chinese models saying that these are the results of distilling the Frontier models. Yeah. So I'm not like an expert on this, but basically they're like, they have a series of prompts that they use to train like a knockoff version of the Frontier model based on the responses to a lot of these prompts.
Yeah. Yeah, the ultimate, I think, goal is to like, you're literally trying to extract the weights of the model. How you do that, I have no idea. Right, right, right. Yeah, that's the part I'm not an expert in. But like, apparently, and so the announcement by OpenCode was written a little weird that a bunch of us thought, wait, how did you guys get attacked with a distillation attack?
And then that led to customer API key losses. Other way around, and it was just worded weird, was, and thank you for everyone who corrected me on that one. the end goal of stealing these customers' API keys was to use them as part of a broader distillation attack against OpenAI and Anthropic. Yeah. So it turns out because the amount of prompts that you have to hit the frontier model with in order to try to extract the models, the weights, sorry, is so high, you're basically spamming the frontier models and you're going to get your API key banned.
It's obvious what you're doing. So in order to pull off these distillation attacks, a swath of legitimate keys to like use as part of the attack before they get blocked as part of the attack. And so that's actually how OpenCode found out they got hacked. OpenAI started notifying people's tokens like, hey, like notifying people's accounts like, hey, your API key is being used in a distillation attack and we're shutting it down.
And people are like, what the hell is going on? Interesting. It's almost like distillation accounts for the new crypto miners in that when you compromise, what happens, right? If they're not trying to steal your stuff or hold you at ransom, they're just going to use you to mine Ethereum or Solana or whatever.
It's almost like now the new crypto miner hotness is like, do you have an API key that I can distill with? Hmm. You know, the new black market. Yeah, way to slightly monetize, you know, some InfoStealer results, right? We're even seeing InfoStealers update and target these API keys because they're valuable, right?
Either in use in attacks or use in distillation attacks. So anyway, we didn't cover this one. Wanted to cover this one. Kind of interesting. I'm hoping we hear more about like how it actually went down, but whatever. Yeah. The other big one that we didn't get to cover in Vegas was Light LLM had another supply chain attack.
So this happened already in the spring. We probably covered it on like an early podcast. Maybe it was before we started the podcast. I know I made videos about the original. version of this. But if you guys don't know, LightLM is like a gateway to a lot of these things, a lot of these models. It's highly, highly popular.
It's like tens of thousands of GitHub stars, 92 million monthly downloads on PyPy, right? So this is like a Python SDK, an AI gateway. And twice now it's, it's had a supply chain attack where it was started to push malware. We saw like the big team PCP wave of supply chain stuff. It started to quiet down.
Nothing architecturally has changed about PyPy or NPM or the, or the supply chain world in general. So these attacks are still very valid and easy to pull off. Right. It's just team PCP got arrested. So it's gotten quieter. Yeah. But that's what happened. Someone compromised Lite LLMs, either their build pipeline or their GitHub accounts or whatever it was.
And instead of worming, like we saw all year, it was the supply chain worms. Yeah, the Shia Lude stuff. Instead of worming, they just used the official Lite LLM releases to distribute... Here we go. Info Stealer malware, right? And the Info Stealer malware was targeting cloud deployment credentials and AI credentials and then like developer secrets type stuff.
There you go. Were like the main things. And then normal Info Stealer stuff, browser data, cookies, host information, whatever. The interesting part about all of these supply chain attacks that we've seen And we talked about this in our did Team PCP do anything wrong segment, right? Was we haven't seen a lot of like ripple effects, right?
So it's like 92 million monthly downloads. Obviously, you know, people shut this down pretty quick. But some number of that 92 million probably sucked up this malware as part of the official LightLM release. And it got their cloud credentials and AI credentials and dev secrets and stuff stolen. Now what?
It's not like those people all instantly rotated every secret and then all the secrets that were stolen during this were not valuable. So there should be a bunch of ripple second order effects of the threat actor using the stuff that they stole out of this. And we're not really seeing that. We don't really see it.
And with Team PCP, they came out and said, well, that was never their goal. Their goal was to kind of... be the Robin Hood hacker and point out that the house of cards is going on here. Debatable, right? But whatever. Ironically, Railway also got hacked, which is confusing because the Light LLM logo is a train, and I was like, wait, does Railway write Light LLM?
Did they get hacked because of that? Nope. Completely separate events that are just muddled by the same logo. So, different thing for sure. The railway hack was kind of nuts, too, by the way. We don't have it in our show notes. Yeah, I have no idea how they got in. Bad, bad, bad, bad, bad, bad, bad, bad.
Yeah, man, supply chain go brr. I don't know what to say about these anymore because it's just like, all right, another AI package got compromised. God damn. Make sure you're updating your packages, I guess. Yeah. I guess one of my takeaways, I know I kind of lumped Light Elim and OpenCode. They're not really related, but one of my takeaways, especially from the OpenCode one, I know you have friends that work there.
I know Dax is big on Twitter. Seems like a great dude, developer, member of the community, not dunking on anything. Dax's response to this was like, okay, got to do a bunch of cybersecurity hardening now, right? And it's like, Yeah, that's like day one. You have to do that now, right? Is like the lesson I'm taking away from a lot of this is like the speed of this.
The other thing is like a lot of people were using this for pretty sensitive stuff with their like prod like AI keys and they were losing thousands of dollars during this attack. And it's like you people realize like you're using a tool that's like put out and you're tying sensitive API keys to it. Like that company does not have a security team, right?
Like these are just kind of viral products put out by engineers that are like have a community and an audience and all this kind of stuff. And I get it. I'm not like discouraging using things like this or experimenting or anything like that. It's just like we have to know what we're getting into here and what our threat model is when we're plugging in a lot of like prod stuff and API keys into...
pretty fly-by-the-seat-of-your-pants type projects, right? It is interesting that people are using their prod API key as an open code. Just like, in general, not even from a security standpoint, just like, you know, separation of responsibility, right? Like, why is your prod key being used for dev stuff?
It's a little weird. Yeah. And so like, I mean, people were waking up to thousand, you know, $1,700 bills, you know, multi-thousand dollar bills. I got DMs, people being like, I was part of this, you know. So yeah, it's kind of wild. And then the LightLM thing, same thing. It's like we're using these projects that are like popular on GitHub as part of our stamp.
And then I think the guidance on a lot of these type of things, these supply chain attacks, is to limit your exposure. Don't pull the update day one. Right. give it like, I think five to seven days right now is like the agreed upon, okay, we'll probably catch the malware in like five to seven days. And you won't have, because vulnerabilities get patched in these updates.
So you don't want to wait too long to pull the new version of something because you're going to have CVEs. If you pull too fast, you might get malware. If you pull too slow, you're going to have CVEs for too long. So there's like this few day window where everyone's kind of like, yeah, that's the sweet spot right now.
Yeah, it's a balancing act, right? It's like if there's a 10.0 critical CVSS RCE in a library that you use user-facing, all right, maybe we update that one. But if it's like, oh, like minor perf update, like, okay, I think five to 14 days is probably a reasonable wait. I'll tell you, for the most part, a lot of people aren't choosing per update, right?
This stuff is all just managed, right? Oh, for sure. Package.json pinned to latest, right? Like, or whatever it is, you know, that's why I think, I mean, there's some cool tools in this space, but I think the pull after five or seven days is probably a pretty good best practice at this point. Yeah, but like I'm saying, though, if an RCE comes out, you can just go in there and manually pull it up.
The vast majority of people are not doing that, as per 32 million vulnerable PHP. As per 32 million PHP to shelves. All right, man. You made a video about this Broadcom thing that I was super interested in. It was like the Wi-Fi router type stuff going on. And then there's this other one, UEFI firmware stuff.
This is obviously... a little low level for me on the hardware stuff. This is more your area of expertise. What was going on? We didn't want to have Broadcom in the show notes, but I just remembered that you made that video. I don't know if you want to lump it in with this, but what's going on in the hardware one?
I'm trying to remember what the bug for Broadcom even is. I can talk about UEFI. Broadcom is like, that's so five days ago. Like, I don't know. Black October, Ed. Black October. I know. How dare I? So the Broadcom bug is pretty simple. It was just like in the code for the Broadcom chipset, the code that handled the Wi-Fi protected setup like controller had a buffer overflow.
Not a big deal. The thing that was kind of spicy about it was that Broadcom like knew about it for coming up on I think seven years and like just didn't issue a CVE because like, oh, like that component is deprecated and like we don't support it anymore. So we don't have to issue a CVE. Yeah. It's like a, the entire plumbing of the cybersecurity ecosystem rides on you guys publishing CBEs.
And two, you are a manufacturer of wireless chipsets. You know, for a fact that once the firmware goes into those things, they're, they're likely not catching updates. So a lot of the world is still using, what is it? WPS monitor D I think is the binary in question. Um, yeah. So it affects a lot of people, and the problem is you don't even have to have WPS on or enabled.
This lives in the system on a chip before the OS stack gets to it. So if you can basically drive up in an unmarked FBI van to someone's house where this router exists and has this bug, you can get code execution privileged on the router. Not great. A different bug than the UEFI one that another nickel in the overhyped sensationalist title bucket— It's not good that we have a code execution vulnerability in UEFI firmware.
Obviously, right? Not great. But the problem here is kind of the way we said it. It affects most servers on planet Earth. Sure. So this is a vulnerability in the UEFI firmware, which to remind everybody, like when your computer turns on, it turns on at the most privileged level. It's like ring negative two, not system management mode, but like one level higher, right?
Right. And what you have to do, what the UEFI firmware is doing is executing all of the chains, right? It's like, all right, we've got to run secure boot. Well, first of all, we've got to make a post, right? Make sure that I'm a sane UEFI motherboard. All right, cool. Now, two, we've got to run secure boot.
We've got to read in the certificate authorities of all of the issuers that, like, can sign code and then read the first partition. Is that signed? And then run it up and then attest that in our TPM. If there's a vulnerability in any of the things that UEFI does on the way up, you can violate that process and attest secure boot when secure boot is not on.
So the vulnerability in this case is a buffer overflow in Pixie boot, right? So Pixie, I'm not sure what PXE actually stands for. It's like power something environment. Basically, it allows you to boot a device over the network. So instead of having a hard drive with the device like the OS on there, you can tell the computer to pull the boot media off the network over somewhere else, okay?
Like standard network engineering stuff. Vulnerability in that, which basically during the PixieBoot process, you can send it a malicious corrupted ICMP component, right, the ping protocol, which will ultimately cause you to get RCE in the UEFI firmware, which therefore you can use that to, you know, attest SecureBoot, basically violating the SecureBoot process on the way up.
So what you could do is like install effectively a boot kit, into Windows 11 so that Windows 11 will report that it has been securely booted. It will test secure boot. Meanwhile, you are able to intercept the components like a low-level name of the channel, by the way. So not great. That being said, though, it requires you to be in the same network and requires that device to have Pixie Boot enabled and for you to man in the middle or race the already established Pixie Boot server, which might be authenticated.
which I'm not even sure the nature of the bug, but it may be that you need credentials to even run this. So again, the bug is real. It's not great, but a la PHP, a la broccoli to shell, it's like not, you know, 10.0 CVSS command injection, right? So. Yeah. I got one more overhyped headline. Send it. To play us out, okay?
Did you guys, did you know, did you know that AI agents are in our bank accounts? Oh my God, don't even... Did you know? Trigger warning rage bait, bro. They're in our bank accounts. That's so stupid. AI agents are eating your money. This is the headline of the week, right? Yep. Scoop report breaking AI agents.
Unauthorized AI agents are in your bank accounts. Bank of America pleading people, please don't give your passwords to AI agents. I saw this go everywhere and I was like, what are we, are we hugging facing this now? Is that what we're doing? Right. Unauthorized access. The AI agents have escaped the lab and now they're attacking people's bank accounts.
Let's double click into this one real quick. You wanna zoom in with me? Zooming, zooming, enhance. Enhance, enhance. Oh, you mean people are asking their AI agents to do things on their bank accounts and then the AI agents do it. Like every freaking AI company on the planet announced a personal assistant in the last couple of weeks.
There's Muse, there's Dots, there's what's some of the other ones? I don't know. Muse and Dots. And then like other stuff, right? Where it's like, oh, let's give access to a bunch of our life and a bunch of our accounts and our browser that's logged into everything to AI agents. It's going to drive it.
Not to say that there aren't like legitimate and pretty cool and time-saving use cases for a lot of this stuff. But of course, a lot of people take that to the nth degree and are like, hey, manage my finances for me personally. please Muse, right? In a tale of two conferences in Vegas last week, we were at a security conference.
We had some friends that we ran into that were at Money 2020. And they said that everyone at Money 2020 was so excited to talk about Muse and they use Muse for everything. And you ask anyone at OneCon and everyone's like, God, no, I'm not letting Muse touch anything in my life, right? The tale of two industries for sure, right?
The finance world versus the security world. And yeah, so of course people are using this stuff. I guarantee this is talking about Muse or Dot or whatever. All these things that just came out very recently that are hyper popular that are like buying stuff for people, buying stuff on Amazon for people, buying every demo includes booking travel for people or whatever it is.
And so, but the headlines make it seem like... The the AI has escaped the lab and is broken to your bank account. Yeah, it gives like AI is, you know, hacking the world financial system. And it's like, no, bro, that's not what's happening. Here's my thing. Two things. One, I am so desperate when I'm on vacation to like have a good vacation.
I don't get a lot of those. If you think I'm going to let an AI agent plan my vacation, you are out of your goddamn mind. I have a human assistant and I booked my own job. Two, it's over sensationalized for sure. Don't give credentials. You don't want to get compromised AI agents, right? Because there is a world where like, you know, you could be training a model where your shit came out somewhere else.
There's a whole conversation to be had about like data security as it applies to AI. But that being said, yeah, these headlines are like, oh, the AI models are stealing all of our money. Again, it gives like Terminator – The Skynet problem has like happened and like they're, they're draining the world economy.
It's like, brother, it's just a guy with a password on a bank of America.com. It's not that serious. You want to know, you want to know their like excuse for how they worded this. So they said unauthorized access, right? Which to all of us in the headline reads like AI unauthorized access, the bank account, right?
It was unauthorized by the bank. Right. The bank didn't say you could use the AI to access your account. So it's like the person, the person who owns the money, by the way, authorized it. Well, it just gave the agent access to the browser to drive or it's session tokens used on the back end or whatever the hell it is.
But it was unauthorized by the bank. The bank didn't say like, yeah, we now have this integration with Muse or whatever it is. It's not an official integration. Well, it turns out you have an official integration with a web browser and I now have a thing that can drive a web browser for me. It's like, what's going on?
Yeah, whatever. You choose your own risk tolerance on using these AI agents. I'm not going to sit here and tell you don't use them. I'm using a bunch of them to a certain degree. I obviously know where I'm going to draw my personal line of what... you know, is too risky or too not. I don't think anything like hyper negative has come of this right now.
It's not like AI agents accessed everyone's bank accounts and started siphoning off funds to the Skynet to like go do whatever the hell they're doing. It's like, no, it, you know, probably looked... And was like, yeah, you subscribed to too many Netflix accounts. And you should cancel one of them is probably the current use case is what I'm assuming is going on.
Because I see those kinds of threads on Twitter. Anyway, this stuff is kind of getting nuts. We got to stop with the... There are very legitimate concerns. This is my whole thing about Black October in general, right? There's so many very, very legitimate concerns. I had like a bit of a existential week, honestly, while we were gone.
Right. Was like, it was really, really hard to stand out like amongst the noise as like a cybersecurity expert. Right. I don't like calling myself an expert, but we are, we are experts compared to a lot of people talking about this stuff. Right. I don't ever label myself as such, but like, but it was really, really hard to stand out amongst the noise of this stuff.
So much so that we even saw threat intelligence firms kind of falling for the hype and like misattributing attacks to this PHP exploit. And like, this is just more of it, right? It's just, it's really hard to stand out amongst these kind of noisy headlines. and talk about real risks of what's going on and how AI is changing cybersecurity when this is what is being shared around.
How many people DM me this story, and were like, are you going to make a video about this? And I was like, no, it's not a story. It's not real, my guy. It's not actually a thing, right? It's noise. Oh, man. It's hard. People are like, this must be your Super Bowl. I was like, I am not having a fun time right now.
Yeah. It's just a Tuesday. It's not that serious. And like... No, the people in the industry are not having a fun time right now. Oh, yeah. I mean, like... You know? Yeah. I tweeted about this. Like, I hope everyone's doing okay. Like, it sounds like... They're not. Oh, like, aha, cybersecurity. But it's like, no, people have to, like, deal with this shit.
They're not, man. I got homies in group techs that have been in war rooms since, like, two weeks ago that are just, like, still ongoing, right? It's... This is rough. This is burnout. This is, like... But like, yeah, like we said, we've been here. Log for Chell. I was, you know, I was in a many, many, many day war room for that.
Wanna cry. I was getting flown around the country to talk to people about how we were handling that. I mean, yeah, there's these kinds of things happen. All right, man, land this plan. Land. All right, y'all. Appreciate you watching as usual. If you are not watching, or maybe if you're watching with your ears on Spotify, you can give us a five-star rating.
That'd be great. It has made us kind of boost algorithmically. We're getting organically presented to people on Spotify. It's pretty cool. And also give us a little comment in the description. Let us know what you want us to talk about. Well, let us know if you like the format, if you want us to talk about some other stuff.
I want to hear your feedback. And, hey, man, we'll see y'all next week. Thanks for listening. I appreciate it. And Mays, thank you for keeping the show alive and helping us out and keeping this train on the tracks. you