SN 1083: Patch Tuesday à la AI - Arch Linux Repo Under Siege

Summary

Security Now – Episode 1083: Patch Tuesday à la AI - Arch Linux Repo Under Siege
Published: June 17, 2026
Hosts: Steve Gibson & Leo Laporte

---

Overview

This episode of Security Now centers on two major, timely security stories:

• The Arch Linux Repository supply chain attack affecting over 400 packages with sophisticated rootkit and infostealer malware
• The record-breaking “AI-fueled” June Patch Tuesday, where Microsoft and other vendors shipped their largest-ever volume of security updates—signaling the lasting impact of advanced AI on vulnerability discovery

Steve and Leo also dissect marketplace reactions to the US government’s directive to shut down Anthropic’s cutting-edge AI models (“Fable” & “Mythos”) for possible security risks, evolving AI patching requirements from CISA, and debate the consequences of new security defaults in npm, the world’s most attacked package manager.

Throughout, listeners get a nuanced exploration of how generative AI is transforming both cybersecurity offense and defense—sometimes to industry-wide discomfort and disruption.

---

Key Discussion Points & Insights

1. AI Is Changing Security — Faster Than Anyone Anticipated

• AI's Role in Vulnerability Discovery: This month’s Patch Tuesday set a new record (200+ Windows vulnerabilities addressed, not counting the separate Edge fixes) due to AI tools used by both defenders and attackers.
• Race to Remediate: The industry now faces a true race—whether defenders can fix flaws faster than attackers using AI can discover and exploit them.
• New Patching Directives (CISA BOD 26-04): For federal agencies, CISA now requires vulnerabilities that carry high risk (publicly exploited, automatable, known to give total system control) to be patched within three days. Steve calls this “a watershed moment—patching is no longer back-room, but absolutely central and urgent.” [1:50:00]

"It is just no longer the case. Any federal agency...has to patch on the timeline we say, and it's fast. Patching...has moved right up to the front of operational readiness."
— Steve Gibson [02:50]

---

2. Deep Dive: Arch Linux User Repository (AUR) Supply Chain Attack

What Happened?

• Over 400 AUR packages were found to contain advanced malware (nicknamed “deps”), which delivered a stealth Linux rootkit and infostealer payload.
• The attack vector: malicious code leveraged npm “pre-install” lifecycle hooks to execute an ELF binary (named deps) during package install.
• The payload targets developer workstations: extracting tokens, credentials, browser/app data, vaults, Docker, shell histories, and SSH/VPN/private keys. With root, it installs an eBPF-based rootkit for near-invisible persistence.

Analysis

• Unlike prior incidents, the attackers showed deep knowledge of both the Linux ecosystem and the nuances of modern developer machines.
• The incident underscores the dangers of “magic” automation in package managers: hidden scripts can quietly run, exfiltrating secrets as soon as a package is built or installed.

“No developer wants this thing anywhere near their machine.”
— Steve Gibson [19:40]

"This is not an edge case, it's a meaningful slice of the most depended-on packages in the registry. The day v12 lands, those packages stop working till someone approves them." — Quoting an open source security expert on npm changes [82:56]

• Leo and Steve walk through (in exhaustive, sometimes tongue-in-cheek detail) the enormous list of browsers, Electron apps, collaboration tools, and secrets this malware targets [from ~34:30–41:15]. It highlights the breadth of “developer stack” risk.

Root Causes & Takeaways

• "InfoStealer" malware is on the rise; attackers are more interested in the credentials and access a developer holds than compromising the developer per se (supply chain risk!).
• Steve issues a wake-up call: package maintainers and users must adopt better hygiene, including skepticism about “legit” packages and readiness to patch at speed.

---

3. AI and the Anthropic “Fable” Shutdown: National Security Meets Market Competition

Event Recap

• US government issued an export-control directive requiring Anthropic to block access to its newest AI models, Fable 5 and Mythos 5, for all foreign nationals (citing undisclosed “national security” concerns).
• Anthropic’s public response: They dispute that any so-called “jailbreak” demonstrated a unique safety issue with their models, noting that “perfect jailbreaking resistance does not appear possible for any model provider...every safeguard used in the industry is vulnerable to non-universal jailbreaks.”
• The supposed “jailbreak”? As reported by Katie Moussouris: downloading code to review, then asking the model to “fix this code”—something other models also allow, raising questions if this is a meaningful threshold for export controls.

Broader Implications

• Major security figures (Alex Stamos et al) have authored a letter demanding the government “Free Fable,” arguing “this is not that different from everything else” [62:51].
• Fear of “AI brain drain”: Blocking researchers based on nationality may push talent (and model training) offshore.
• US and EU may soon see model competition as a matter of sovereignty and innovation, potentially fracturing the AI landscape.

“I think it’s a very big tactical error, and I think it’s more about politics and corruption than it is about actual security...the only jailbreak we’ve seen so far is just: ‘fix this code.' That’s absurd.”
— Leo Laporte [62:28]

---

4. npm Changes: Is Security by Default Coming—Or Just Moving the Problem?

What’s New?

• npm v12 will disable auto-running install scripts by default (a long-demanded change to combat rampant supply chain attacks).
• Package maintainers will need to explicitly allow install/prepare scripts; similar restrictions for git and remote tarball dependencies.
• "Cool-downs" (delayed installability of new/updated packages) are becoming default across major package managers.

Critical Reflection

• Many essential packages rely on install scripts for legitimate reasons; flipping the default may break widespread workflows.
• Security consultant insight:
  • Deny by default is essential, but will cause pushback and may train developers to mindlessly “approve” scripts, blunting the effect.
  • Malware, when forced out of the registry, simply relocates (e.g., into shell scripts or third-party binaries)—possibly becoming harder to detect and quantify.
  • Attackers will adapt; defenders must too, ideally through AI-driven scanning and layered controls.

“When the malware moves out of the registry…NPM gets to report that registry-resident malware is down. They’ll claim victory. Meanwhile, the risk simply relocates.”
— Steve Gibson, quoting open source malware blog [93:50]

“Turn on cooldowns today. Single best ratio of effort to protection available.”
— Steve Gibson [98:45]

---

5. AI in Practice: Anecdotes from the Hosts

Both Leo and Steve share recent personal experiences using Claude Opus/Fable models for advanced technical troubleshooting.

• Leo recounts a catastrophic Linux workstation boot failure, which AI (Claude) diagnosed and fixed remotely—engineering custom scripts and automating checks with “care as if it was his mission-critical agent.” [09:33–14:52]
• Steve reflects on seeing the “shift” after years of tech experience: AI now actively reviews past (even bad) interactions, apologizes, and self-corrects.

“I would never…have been able to fix this. It wrote a little web server, curled the key over, logged in and did it all for me…You tell me these things are just autocorrect!”
— Leo Laporte [13:02]

“It’s easy to poo-poo it…until you’ve had this experience.”
— Steve Gibson [15:21]

Both agree: If this sounds outlandish, it’s only because you haven’t tried it for deeply technical tasks — “it speaks computer really well.” [16:11]

---

6. Patch Tuesday à la AI: The New Reality

• By the Numbers: June Patch Tuesday delivered 200+ vulnerabilities patched (not counting 360 Chromium-based Edge vulnerabilities), including 60 critical CVEs, and multiple actively exploited zero-days.
• Impact of AI: Steve attributes this "tsunami" of fixes to Microsoft’s new AI-driven internal tooling (internally codenamed M-Dash), which is now both finding and helping to eliminate legacy vulnerabilities at an unprecedented rate.

“This is what the next several months are going to look like. The race is on…and at least in software, there’s really no comparison: man vs. machine—machine wins.”
— Steve Gibson [148:00 & 150:16]

• Key Fixed Issues:
  • Multiple privilege escalation and remote code execution flaws in Windows and key services.
  • Two zero days in BitLocker (Yellow Key & Bitskrieg), including one developed in less than 24 hours after a previous fix (showing the dynamic between bug hunters and patch engineers).
  • A six-year-old CVE in Cloud Files suddenly re-exploited—raising questions about patch completeness and regression.

---

Notable Quotes & Memorable Moments

• “Patching, again, has moved right up to the front of operational readiness, business-wise.” [02:50]
• “You get an account, it can be free, but that creates context…and if what we’re saying sounds wacky, it’s because you haven’t tried it.” [15:31]
• “The infostealers are more interested in what other systems their victim has access to than in the victim themselves.” [41:50]
• “No one imagines that next month will be much better. You know, buckle up for July.” [122:10]
• “What a month. What will next month look like? No idea, but it’s going to be really interesting.” [147:33]
• “If this standard was applied across the industry, it would essentially halt all new model deployments for all frontier model providers” — Anthropic statement [56:37]
• “Turn on cooldowns today. It’s the single best ratio of effort to protection available, and there’s no reason to wait for v12.” [98:45]
• “The only way to ever be truly safe is to require some information at boot time that’s not present anywhere else in the system.” [133:11]
• “We’re living in a science fiction world.” — Steve, on AI self-service repair [12:59]

---

Timestamps for Important Segments

• 02:45 – US federal patching update & importance of patching, CISA BOD intro
• 09:29 – Leo’s tale: Claude AI repairs mission-critical Linux system
• 19:11 – Arch Linux AUR supply chain malware deep dive
• 34:30–41:15 – The epic (and sung) list of things the infostealer grabs
• 47:11 – Anthropic “Fable & Mythos” export control and industry reaction
• 61:43 – Katie Moussouris explains the “fix this code” jailbreak
• 68:51 – CISA’s new patching timeline tree explained
• 77:02 – npm disables install scripts by default, security analysis
• 98:45 – Practical recommendations for defending against supply chain risks
• 121:54 – Patch Tuesday à la AI: why this month broke records
• 148:00 – “Machine wins”—reflections on AI’s supremacy in code review and vulnerability discovery

---

Episode Tone & Language

Conversational and occasionally playful, with the dry nerd-humor, wordplay, and “song of the infostealer” you expect from Security Now. Leo and Steve alternate between technical depth, measured skepticism about both industry and government, and amazement at the real-world impact of AI on their daily work as security professionals.

---

Takeaways for Security Professionals

• Expect more Patch Tuesdays like this: The surge is likely temporary, but marks a sea change.
• AI is rewriting both the offense and defense playbooks—orgs must prepare for more rapid cycles of vulnerability discovery, disclosure, and exploitation.
• Supply chain hygiene is critical: Even trusted repositories and common workflows are under siege.
• Security “defaults” are shifting (in npm and government patching policy), but are not silver bullets; attackers will adapt, and defenders must continuously raise the bar.
• Policy and politics will play a growing role in access to advanced AI: anticipate cross-border, legal, and sovereignty disputes.

---

For more, transcripts, and resources visit: grc.com or twit.tv/shows/security-now
(See show notes for Steve’s curated links and further reading.)

Transcript

[A]

It's time for Security Now. Steve Gibson is here and he's raring to go. There are more supply chain attacks to talk about, including on the Arch Linux user repository npm. They're going to try to make that a little bit more secure. Steve has some recommendations until they do. And June shows that AI has arrived for vulnerability discovery. We'll talk about that and a whole lot more next on Security Now.

[B]

Podcasts you love from people you trust.

[A]

This is twit. This is Security now with Steve Gibson. Episode 1083 recorded Tuesday, June 16, 2026. Patch Tuesday a la AI it's time for Security now the show we cover the latest in security, privacy and all that stuff online with the man, the myth, the legend, not the mythos. Mr. Steve Gibson.

[B]

No mythos for you. That's no fable here. No fable either. Wow, wow, Crazy story. Well, yeah, I'm gonna share Anthropic's response and then we'll do a little editorializing around that because that was an interesting weirdness. So last Tuesday was June's Patch Tuesday and boy did we break records.

[A]

Yeah.

[B]

So today's podcast is titled Patch Tuesday a la AI because you know, this is what we were expecting to see. It'll be interesting to see how long this tsunami crescendo tidal wave pulse lasts. I don't expect it to be like this is not going to be an every month thing, but five, six months would be my guess. And then we're gonna see a, a reaction drop in the number of monthly patches because the AI is going to get deployed in the case of Microsoft. And Patch Tuesday horribly named code name M Dash, which they make me say every time will, will be the thing that, you know, changes, I really believe changes the Windows side of the industry. Anyway, we're going to dig deep into that. I want to talk about rootkits having been found in more than 400 arch Linux user repository packages.

[A]

I had to really worry about that. I'm an Arch Linux user. Yeah.

[B]

US government requests Anthropic, as we said, to remove both access to both Mythos and Fable for foreign nationals. But since you can't, I mean it's like the age restriction problem, right? It's like, well, we're not really sure so we just have to tell everybody. No. CISA has also had an interesting response to AI driven attacks changing their patching requirements for federal agencies. And boy, if, if patching was ever a back room or like, like on the back burner, this is. It is just no longer the case. And any Federal agency who and they might. This is a bod. What I can't remember that stands for Binding Operational Directive from. From cisa which you know has legal strength which says you have to patch on the timeline we say and it's fast. So patching again is like this has moved right up to the front of you know, operational readiness business wise. We'll, we'll, we'll look at that. Also npm, the most attacked repository we have, the Node JS packet manager has switched to more secure install defaults. The problem is a lot of non malicious use of these install defaults occurs and so this is going to create breakage which is going to have an unclear effect on long term security. I found a really interesting analysis of this from somebody on the inside who understands what's going to happen that we're going to take a look at. Also a bunch of people responded across the spectrum about my little rant on about php which of course is not the first time I've ranted about php. But we've got great loop closure now with email communications and so I'm going to share a bunch of that and then we're going to look at the consequence of AI having been here long enough code cognizant AI long enough to have a serious impact on June's patches. So I, I think a lot of fun stuff to talk about and of course a picture of the week that actually is a. Has a kind of a coding theme or that's how I'm going to spin it anyway.

[A]

Oh well, you know I'm always up for that. Yeah, I have a little tale to tell about AI saving my bacon yesterday too at some point. Yeah, I was, it was like a lifesaver. Speaking of Linux.

[B]

In that case let, let's do the first sponsor then. Then you have to tell us because I can't wait.

[A]

Yeah, yeah. I just. The more I use it, the more valuable it becomes. That's. That's what's really clear. Yeah, I miss Fable. But you know this was with 4.8 opus 4.8. It did a great job. But let me tell you about our sponsor for this segment of security now and it is one that you all you network engineers are going to want to know about. It's brought to you by Meter today, the company building better networks. Actually I wish I could get Meter here. My company really doesn't need Meter, but I bet yours does. Meter was founded by two network engineers who feel your pain if you're a network engineer. You know what I'm talking about the the legacy providers with inflexible prices, pricing the IT resource constraints, stretching you thin, complex deployments across fragmented tools. You, my friend, you, network engineer, are mission critical to the business. But you're working with infrastructure that just wasn't built for today's demands. And it's not your fault. It's not that the company's fault really. I mean, the Internet has exploded and it is more and more important for every business. But that's why businesses are switching to Meter. Meter delivers full stack networking infrastructure, wired, wireless and cellular that's built for performance and scalability. See, these network engineers realized that if they wanted to give you a quality experience that scales that can grow with you, they need to do it all. They design the hardware. It's beautiful by the way. Beautiful hardware. They write the firmware, they build the software, they manage deployments, they provide after sales support. They do it all. And they do everything from ISP procurement to security to routing, switching. They can do wireless firewall, cellular, they do power, power is really important. DNS security, they do VPNs, they do SD WANs, multi site workflows, all in a single solution. Meter's single integrated stack is designed to work in the most challenging environments. Major hospitals, branch offices. You know, you acquire a new company, now you got branch offices with a completely different system. You need to communicate. Morse, maybe. They have a 200,000 square foot warehouse that's depending on WI fi. Nothing works. And IT and IT has to interoperate with you. They can solve those problems. They do again and again. Large campuses, data centers, even Reddit. Yes, Reddit uses Meter. So does the assistant director of technology for the Web School of Knoxville. They moved to meter. He said, quote, we had more than 20 games on campus between our two facilities. Each game was streamed via wired and wireless connections. The event went off without a hitch. We could never have done this before Meter redesigned our network. With Meter, you get a single partner, one phone number for all your connectivity needs, from first site survey to ongoing support, without the complexity of managing multiple providers or tools. Meter's integrated networking stack is designed to take the burden off your IT team and give you deep control and visibility, reimagining what it means for businesses to get and stay online. Meter is built for the bandwidth demands of today and tomorrow. Thanks to Meter for sponsoring. Go to meter.comsecuritynow to book a demo today. That's M e t e r.com SecurityNow book a demo. You need Meter. Now back to Steve and our picture of the week.

[B]

First tell us about AI saving your bacon.

[A]

So I run my agent, everything, all, all of it, all the models, all the memory, everything on that nice framework desktop I bought, really designed to do that. I bought it to do local AI, 128 gigs of RAM. It's got that AMD AI plus 395AI specific processors, really nice. Yesterday I come in, I mean, and I use it every day. That's where Claude is, where everything is. And it's, it says emergency, can't boot. And it gives me a prompt and I go, oh, that's not good. Now in the past, what I would have done is I would have reinstalled Linux on that machine and, and then had to go through. I've got backups, of course, but I'll go through the hairy process of restoring it. And because it's my agent, I wouldn't have any assistance doing it, fortunately. Right, yeah, it would be on my own, buddy. Fortunately, I do have Claude code running on my laptop. So I thought, well, let me, let me just see if cloud code can help. It said, don't erase it, tell me what the message is. And I told it, I said, oh, good news, that might just be a minor thing, let's figure it out. It had me type in, it started to have me typing a lot of stuff. Basically I went to rebooted it through the Linux install USB key so that I have an operating system and I can look at the hard drives and it's. I said, this is a lot to type in. I'm going to make mistakes. It said, oh, of course, this is Claude talking. What am I thinking? It said, look, I human. You, you human, you poor human. I need to SSH into this machine. But of course you're running the boot thing, you know, it doesn't know who I am. It's not going to let me SSH in. So here's what I'm going to do. I'm going to write a little web server, run a little web server on your, on the laptop here, and you're going to curl the, the key, the SSH key into the boot thing, turn on ssh and then I will SSH in and do it for you. I did it. Did it. Ssh 10. It said. It looked and looked and said, oh, you know what the problem is? It's a little weird, but you have two. I don't even know what an ESP is, but you have two ESPs. The way I set this up is it's just dual SSDs. They're lux encrypted and they're mirrored so that if one dies, I mean, this is how mission critical. If one dies, the other one has still got everything on it. And it does because the Lux encryption, it has the password and the tpm. Because the other thing is it has to reboot. If I'm not around and the power goes out, I have to reboot. But I do want it encrypted. I just don't want to have to be there to enter the password. So it does that automatically through the tpm. I don't know what an ESP is, but apparently it's something to do with uefi. There are two different ESP modules and for some reason they had different Linux kernels. 1 had 7012, 1 had 7.0. 11. And that's what was stopping it from booting. It figured that out. It said, okay, I'll just. No problem. I'll just put the other kernel, I'll make a match and from now. And I'm going to write a little stub now, when you. When you do an upgrade, that will automatically make sure it's the same kernel on both ESP modules so this doesn't happen again. It said, okay, all done. Reboot. It's. It's fixed.

[B]

We're living in a science fiction world. I would never.

[A]

I don't even know what ESPs are. I would not have been able to fix this. Yeah, it has to do with the UEFI boot. I wouldn't have known where to start. It would have been a massive chore. Instead, it wrote a little web server, curled. I curled the key over, logged in and did it all for me. Yeah. And you tell me these things are just autocorrect.

[B]

Wow.

[A]

No, it's very good.

[B]

It's funny. I had an experience yesterday. I'm. I'm configuring the house's security and environmental monitoring and management stuff.

[A]

Oh. It's really good at that, actually.

[B]

Yeah. And I was using Claude, but I was. I had it turned down to Sonnet something. Yeah. And. And it was kind of stumbling along and I was getting some bad answers and I sort of thought, what. What am I doing? Why am I. Why am I using Demo?

[A]

So Sonic's pretty good, but not for the hardcore stuff. Yeah.

[B]

So I switched to Opus 8.4.8. And what was interesting was that it. It. That model, in reviewing our dialogue, started to apologize about the previous bad answers that I'd been given. I said 4.

[A]

8 is very apologetic.

[B]

I'm not sure what happened here. But you know, you got, I got. There was like, oh, that was somebody else. That was just dumb. That was dumbo.

[A]

Don't, don't take. So that's one thing that 48 is notable for. It does apologize a lot. I don't. But when it makes, but, but it, this one was so careful. It said, I know this is, you know, I understand this is your agent. This is, this is mission critical. I'm going to move slowly and make sure that I'm doing everything right. And it, it was flawless. It was amazing.

[B]

And in fact, I had to say now, now that I was on 4 8, every answer was correct. And at one point it said, I'm going to make sure that I've not given you the wrong information by, by checking on, blah, blah, blah, blah. And it went off and did something and it came back and it's like, okay, you know, I, I verified that this is the case. It's like I'm just sitting here thinking, wow, I have an assistant.

[A]

Some people listening are thinking, oh, Leo and Steve lost their marbles. They've drunk.

[B]

Where's the Kool Aid?

[A]

But, but until you've actually had this experience, it's easy to poo poo it. But once you've had the experience, it's like, wow.

[B]

Yes. And as I said to our listeners a couple weeks ago, you get an account, it can be free, but that creates context. And my feeling is if you, if what we're saying sounds wacky, then it's because you haven't tried it or there's nothing you need it to do. The idea is, you know, if you're trying to do something, then. And also, old habits die hard. I mean, this is all new. And so, you know, it takes a while to get used to the idea that there is this astonishing assistance available.

[A]

It's kind of amazing. Well, and the thing is, it speaks computer really well. It's very good at speaking computer.

[B]

It's funny too, because that's significant. I remember when Google searches only turned up the results I wanted because only computer geeks were on the Internet.

[A]

Right.

[B]

And so the Internet was very computer quality. Now you got all this, you know, all this nonsense out there. So you get, you know, search results are nearly as interesting for, for computer people because it's got, you know, everybody else. So it's nice.

[A]

Anyway, that's, that's my tale. I, I was just blown away. It was just really surprising.

[B]

Yeah.

[A]

So, okay, thank you, thank you, Claude, for fixing my computer.

[B]

So it's, now it's picture. So I gave this one the caption a loop with the branch test at the end.

[A]

Okay, I'm ready to look at it.

[B]

I haven't seen the branch test at the end.

[A]

Okay, I like it. This is a. Now Steve's turned this into a coder joke, but it is really a coder joke or is it correct?

[B]

So the sign says. So this is some signage somewhere, like at a service window or something. And it Sundays back in 15 minutes. And then on the next line it says minutes. If not read sign again,

[A]

go to 10.

[B]

Exactly what we have here is a loop with a delay statement in it and it branches back to the top. Now, for those who don't code, there are different configurations for looping. You are able to say, for example, while something then do the following, right? Or you can say when, when, when you're finished doing something, you can perform a test and maybe do it again. So, and. And it turns out these are diff. Like subtly different constructs in computer science. It's one of the things b like programmers who are just starting out learn is that there are cases where you never want to execute some code that could be executed multiple times, which is why we call it a loop, because you loop back, in which case you would test for that decision at the beginning of the loop before you've even done it once. There are other times where you always want to do it once and then you want to see do I do it again? And so that's where you put the test at the bottom. So anyway, I gave this one a loop with the branch test at the end because, you know, back in 50 minutes. If not read sign again. So.

[A]

Yeah, that's very funny. I love it. Yep.

[B]

Okay, so Arch Linux user repository, abbreviated AUR, seriously compromised more than 400 instances of with. Well, seriously, not only in count, but in what 400 instances of Linux rootkit and Infosteeler malware were found? The infostealer targets credentials and access tokens. I'm going to. We're going to dig somewhat deeply into that here in a minute because we've never really talked about Infosteeler malware. We've referred to it. You know, it's like, oh, that's an info stealer. But we haven't like. Like what info is stolen? So we're going to answer that. Last Tuesday, the site, which great domain, ioctl, which is the abbreviation for IO control, you know, input, output, control, ioctl fail is the. Is the site.

[A]

What a good name. Yeah, what a good name.

[B]

And I didn't know you had there's a like a dot fail top level domain.

[A]

I didn't either.

[B]

That's just amazing.

[A]

That one.

[B]

Yeah. Happened. Yeah. They posted their analysis of this infiltration campaign, opening their report by explaining this report summarizes static reverse engineering of the Linux elf. You know ELF malware sample named deps DEPS is the name of the malware and static review of of the recovered NPM package source associated with the incident. The sample and package were treated as malicious throughout handling. No dynamic execution of the ELF NPM package lifecycle scripts or package code was performed. The binary is stripped and implemented with Rust style async state machines. Function names in this report are an analyst assigned names based on decompiled behavior. Okay, so to interrupt for a minute, what they're saying here is that at no point did they actually execute the malware under any context. You know, that's sometimes done right. You run it in a, in a protected virtual environment in a sandbox and see to. In order to watch it go see what it does. And just for the record, this elf, this elf, which is referred to here and throughout, for those not well versed in Linux lingo, is abbreviation for executable and linkable format. Thus ELF executable and linkable format. It's a very flexible format that's used almost universally by Linux and the Unixes also and as well as some embedded RTOs and pretty much everywhere other than Windows, which you know, has its own pe, the Portable Executable Format, and Mac, which uses Mach O AS as its format. In any event, they chose not to let this thing, as I said, loose. I don't know why. In a sandbox, you know, such as, you know, a secure vm, the idea there would be any damage that it might attempt or you know, to do could be observed and contained. Instead, they reverse engineered the malware from a static binary sample of the malware code. And since this malicious binary had been stripped of any latent symbolic names, it was just pure binary code that did the work. Variable names or function names were not there. The analyst assigned the names as they worked through the the decompilation of this once a function's purpose had become clear. So they go on to explain. This sample was recovered from a supply chain compromise involving an arch user repository package build flow. In the reported intrusion path, the attacker modified AUR build steps so that the build process downloaded and installed is a malicious NPM package. That package masqueraded as atomic lock file, which is that like a useful thing version 1.4.2. So that itself is not malicious. It was masquerading pretending to be atomic lock file version 1.4.2 and included the Linux elf payload at source hooks. DEPS is where it was in the file system. The malicious NPM package uses a pre install lifecycle hook. Now this is interesting. We're going to be talking a little about this whole thing coming up a little bit later. A pre install lifecycle hook to execute the ELF automatically during NPM installation could be useful. In this case, it's a source of abuse. This means they wrote a developer workstation, a maintainer's machine or CI build host could execute the malware as a side effect of building or installing the compromised AUR package. Deps, that's the malware is a Linux credential stealer with optional root only EBPF rootkit capabilities. EBPF I'll just interrupt. Refers to the extended Berkeley packet filter technology that allows user provided code to be run in the Linux kernel. This gives that code direct access to the most privileged information in the system. You know, normally this is very useful for analyzing communications. You need to be down in the in the kernel in order to to reduce the analysis overhead. Thus the extended Berkeley packet filter. This is an abuse of that privilege, essentially. So they continue to describe the malware writing. It's designed for developer workstations and build environments. It targets browser and electron application data, Slack, Microsoft Teams, Discord, GitHub, NPM Vault, Docker, Podman, SSH VPN material, shell histories and other local developer secrets. Yikes. In other words, no developer wants this thing anywhere near their machine. They said. The recovered supply chain package identifies itself as atomic lot file. Version 1.4.2 contains a malicious NPM lifecycle entry. Pre installation at source hooks depths. That life cycle script executes the ELF directly during NPM installation. When life cycle scripts are enabled, the ELF in the package source is bite identical to the analyzed sample mean. So that was a little bit of repetition and they're just saying what they analyzed was, you know, byte identical. They said the attacker controlled, you know, Command and Control. C2 endpoint was recovered from the ELF. It's not supplied by the NPM package command line arguments or a JavaScript wrapper. The binary decodes an onion service address at runtime and then they give the address as just a long string of gobbledygook. Like all the onion addresses are ending in dot onion for the domain name. The command result callback is a post at API agent sent through a local loopback SOC style transport, the local 127001 traffic is in an intermediate transport layer, not the attacker endpoint. When BPF is available, the malware can hide local process and socket artifacts used by the transportation. Okay, so in other words, if the code has access to the extended Berkeley packet filter functionality, then that access will be used in a rootkit like manner to completely obscure any and all evidence of any infection or the software itself. It just disappears so that anyone looking at the machine, looking at, you know, nets the equivalent of. NET statistics looking at who's, what processes are or are listening for connections on ports, what communications are occurring on the fly. Looking for example for a connection to a command and control server, it just won't show up. The rootkit system that it brings completely makes it just vanish. And we of course covered rootkits way back in that Sony infiltration, the advanced persistent threat that got Sony. So they said without ebpf, the local network presence of something could be observed. So the recovered package they wrote source. The recover package source appears to be a mostly legitimate TypeScript npm package with a malicious ELF inserted into the source tree and then wired into that NPM lifecycle execution. In other words, it's a normal benign piece of big JavaScript typescript and they just tacked in this ELF binary and then use the NPM pre install functionality to, to get it, you know, to execute it. And then it would do all of its bad stuff, they said. Static review of the package source outside the elf found no JavaScript wrapper, no additional command and control configuration, no command line arguments passed to the ELF, and no package layer references to, you know, temp, sh, API agent, Discord, webhooks or a public C2 domain IP. In other words, the the TypeScript npm package was clean, did not contain any other infection. The infection, such as it was, was all in this ELF binary. So they said. Conclusion the malicious NPM package provides the execution vector. The C2 endpoint is encoded inside the ELF itself. Okay, so now we know what it is and how it's delivered and carried into the system. Which brings us to what does it do inside the developer's machine once it takes hold? And remember, there are 400 instances of these bad things that were discovered in the Arch Linux repository, the user repository. So this no doubt infected a bunch of people. So we learn further why no developer wants us have to wants to have this anywhere near the system. So it installs persistence using root or per user system. D service units enforces a single active instance using Flock so to to keep like multiple instances from running at once Redirects standard input output error to dev null so that you won't see it doing anything. Any of its output ignores sigpipe so it takes itself out of any external control Reads proc self exe to locate and copy and install its current executable Uses Rust Async runtime logic to run collectors and transport tasks Enumerates Chromium family browser profiles and Electron app data Reads sqlite cookie databases and level DB local storage Extract Chromium and Electron cookies and service tokens Queries Slack Microsoft Teams Discord, GitHub, npm and OpenAI chat APIs with stolen tokens or cookies Searches local file system locations for ssh keys, your shell history, vault tokens, Docker, podman credentials, VPN material and developer secrets Uploads file content to temp sh calls back to the recovered onion command and control over a post query to API agent Uses a local loopback sock style transport before reaching proxy destinations Includes a downloader stager path tied to user Bin, Monero Wallet GUI and if sufficiently privileged, loads an embedded EBPF rootkit to hide its processes, its process names and all of its socket nodes. So goes completely stealth once it gets into your system if it's able to use EBPF. And again, just to reiterate, more than 400 instances of arch Linux repository packages have been found infected with this nastiness. So as I said before, we've referred tangentially to InfoStealer malware from Time to time. It is unfortunately an increasingly prevalent form of malware because its goal is is obtaining information that would allow an attacker to pivot to some other target. They don't really care about a developer's machine, but they're hoping that they'll get into the machine of a developer who also happens to have, for example, AWS credentials for some other juicy target like the company he works for or consults to or something. So the bad guys are less much less interested in the initial victim in this case than in what other systems or networks that victim may have access to. And of course the classic example was the LastPass developer who had a a bug in his NAS software that was way out of date, and the bad guys got into him, found out that he was a developer at LastPass, and then got into LastPass. So we've never looked closely at info stealers since they're definitely something that no one wants to discover in their systems, since they're growing in prevalence, and since we have a very Nicely reverse engineered info stealer here to take a look at. I want to share the details of what info this representative info stealer steals the malware targets developer and collaboration data and they they enumerate them. This is, this is literally what they found this code doing it digs into the browsers and Chromium profile stores for Google Chrome Chrome Beta, Chrome Dev, Microsoft Edge Edge Beta, Edge Dev, Brave Brave Beta, Brave Nightly, Vivaldi, Opera Opera Beta, Opera Developer, Yandex Browser, Epic Privacy Browser, Iridium Ungoogled, Chrome, Thorium, Komodo Dragon SRW Where Iron Scent Browser Slimjet, Maxthon UC Browser, Coco Naver Whale, Chromium Flatpak, Google Chrome Flatpak, Microsoft Edge Flatpak, Brave Flatpak, Vivaldi Flatback, Opera Flatpak and Yandex browser Flatpak.

[A]

In other words, half of those I

[B]

know but they exist and they so these developers took the time to put in some some specific code for each and every one of those because if that if the developer has it, they want to get into it. Profile artifacts targeted include local storage level db, the network and cookies, Cookie Network slash Cookies, Cookies default slash cookies and Chromium encrypted cookie values Collaboration and Electron applications which it knows about and goes after Slack Slat Flat pack, Slack snap Microsoft Teams, Microsoft Teams Legacy stores Microsoft Teams Flatpak browser derived stores, Discord, Discord PTB Discord Canary, Discord Flatpak variants, Discord Snap variants, Vesc Top Legcord, Web Cord, arm Chord, Ven Chord Native Cord, ABADDON descent, RIPCord and DAT cord. They also confirmed the slack path data ripcord and datcord. That's right. They also confirmed Slack paths and data where this thing looks at at dot config Slack varapp com Slack Slack slash Config slash Slack Snap slash Slack slash Current slash dot config slash slack Slack. You're just tuned in cookies for *.slack.com slack API enrichment thorough API auth test API users.info and API conversations list and we're about halfway through Confirm Microsoft Teams and Microsoft service artifacts include config Microsoft Microsoft Teams, auth service.teams Microsoft.com, teams.Microsoft.com, skype Token Region GTM Cash Token, authorization Bearer X Skype token teams account tenant and team metadata. They've confirmed discord artifacts which it digs around through, including discord tokens from Electron Electron Browser storage API v9 users at me, API v9 users at me Guilds, MFA State Premium Nitro type flags, guild ownership permissions and member count metadata Developer accounts and package ecosystems including GitHub npm and and open API JTPT account metadata confirmed GitHub strings and endpoints include API GitHub.com where they get a a bearer token user agent. They look for credentials, account and repository metadata such as login, company, public repository count followers and repository stars NPM strings and endpoints including.registry.npmjs.org they get the public the package publishing identity and maintainer package metadata. The open API chat GPT path queries API.open API.com with stolen bearer material for account metadata. This is so it's credential validation enrichment against a third party service. They note not evidence that open API is attacker controlled infrastructure and finally local developer secrets vault token files, Docker command history and registry credential material Podman command history and registry credential material SSH keys and SSH configuration putty, private key material, VPN profiles and dot OVPN that's OpenVPN files shell histories for Bash, ZSH and F and f I s h command history containing sftp, sh, keygen, sh, copy id, sh, add, rsync, putty, plink, docker, docker, compost and podman commands and Yes, I know that was a lot.

[A]

I've made a song out of it.

[B]

Oh God.

[A]

Would you like to hear the oh,

[B]

we have to have it. Slack Snap Microsoft Teams Microsoft Teams Legacy stores Microsoft Teams flatpak browser derived stores Discord, Discord PTB Discord Canary Discord Flat pack variant.

[A]

It's a long song, you know, it's really pretty good. There is a little more Scorch snap,

[B]

variance vest, top leg cord, web cord, arm cord, bend cord, native cord, abaddon descent, rip cord and DAC chord slack path config slack slack slack current slack cookies.

[A]

Sorry. Go ahead please. That's wonderful. It's amazing what AI can do. We shouldn't laugh because this has been a nightmare for everybody using Arch. I mean it is the worst thing you could possibly have happen.

[B]

Yes, terrible. So as I said, I know that's what I just did to everybody was a lot. But I think it's important to appreciate that the more than 400 instances of this malware which were discovered residing in the Arch Linux repository, which were expressly designed to root out any and all

[A]

instances,

[B]

any and all instances of any of that developer data and send it back to its command and control server. So the real takeaway here is this infosteeler stuff. This is what an infosteeler looks like. It's what it feels like, it's what it does. If it gets into your computer, it's out there. And developers really need to be extremely cautious, more so than ever, that this doesn't get into their system because it's going to elevate its privileges. It's going to, you know, rummage around through your system, sing a little jingle to itself and just suck everything out of your computer that you just take for granted. And the developers will get it and use it against you or anybody whose information you have on their behalf, AWS or an employer, someone that you're consulting for and so on. So it's real and it's bad.

[A]

Yeah,

[B]

but you know, Leo, what's real and good?

[A]

Oh, our ads.

[B]

I have a feeling we have, as we have a sponsor, there might.

[A]

There might be, I don't know, a sponsor in your future. I could be. Let me just. Let me just pull it up here and talk about our. Oh, actually, one of my favorite sponsors. It's time to talk about our thinxt Canary. Let me just go back to the picture so I can put my face in it. There we go. Our show today, brought to you by. I'm having way too much fun. Way too much fun. Our show today, brought to you by Thinkst Canary. There is nothing fun about getting compromised, right? The worst, you know what area something worse, getting compromised and not knowing you've been compromised for days or weeks or months. On average, companies don't know they've been breached for 91 days. You may have the best perimeter defenses in the world. In fact, that's probably what happens, is people go, well, no one will ever get in. But they do. We know that, because they're breaches every single day. And then once they're in, they can wander around, they can exfiltrate stuff, they can look at all your files. You need a way to know if somebody is inside your system. You need a honey pot. And that's exactly what the Thinks Canary is. It's a honeypot. But unlike previous honeypots, which were hard to write and hard to configure, this is an easy honeypot that could be deployed in minutes. You go to the Thinks Canary console and you can choose to any of dozens of different personalities. Whether it's a Windows server, a Linux server, SharePoint Exchange, it could be a SCADA device. In my case, it's a NAS device. Oh, one other thing you can do is you can create little files. Canary tokens, they call them. That you spread around your network. You can even put them in your. In fact, I would recommend you put them in your cloud drives like Google Drive and Azure and everywhere. Because if somebody sees that file, I have some, let's say, called payroll information.xls, right? It looks just like an Excel file. And a bad guy looks at it, goes, I need that, whatever payroll information, the minute they access it or try to download it, boom. The minute they try to brute force your fake NAS or your SSH server, boom. Thinks Canary will alert you. They'll tell you you have a problem. No false alerts. No, no, just the alerts that matter in any way you want. Email, Slack, sms. Of course they support webhooks. They have an API syslog where any way you want it, all you do is you choose a profile for your device. It's so easy to do. You might change it every once in a while. It might change it every day. I could change it every 10 minutes. It's very quick. Register it with the hosted console for monitoring and notifications. Then you just sit back and you relax. Because if an attacker breaches your network or a malicious insider is in your network, they cannot help but make themselves known by accessing that thing's Canary. They look like the real thing. They look like valuable artifacts that they're. This is why the hacker's there. They're in your network to get that file to open up that SharePoint server. Visit Canary Tools/TWIT. For 7,500 bucks a year, you get five things Canaries, you get your own hosted console, you get upgrades, you get support, you get maintenance. Oh, and if you use the code twit in the how did you hear about us? Box, you're going to get 10% off, not just for the first year, but for as long as you have your things canaries now, you can always return your Thinks Canary. You have a two month money back guarantee, 60 day money back guarantee for a full refund. I should probably also tell you this. This is their 10th anniversary advertising with us. In all those 10 years that we've been partnering with Things Canary, that refund, that guarantee has never been claimed, not even once. Because once you get a Thinks Canary, you go, how did I live without this? Visit Canary Tools twit. Enter the code twit in the how did you hear about us? Box. Get those things canaries, you got, you got to have them. Canary Tools slash twit. And we thank him so much for supporting security. Now, Steve.

[B]

Okay, so last Friday afternoon at the Request of the US Government's well, non specified concerns for national security, Anthropic shut down all access to their two most advanced models, Claude Fable 5 and Mythos 5. And I'm sure everyone has seen this a lot. We should note that though, that claiming national security has become the catch all phrase used by the US government, which, you know, should be taken to mean either because it's what we want or because we say so. So it's, you know, often not very satisfying. It's not at all clear why this is the case, but in any event, since it was just Leo, it was at the start, the very start of last week's podcast.

[A]

Yeah.

[B]

That Claude Fable 5 first appeared.

[A]

I think I mentioned it, didn't I, on the show.

[B]

Yeah, you did. It's like, hey, there's a new model. And in fact you began playing with it. I think it was during the podcast. You ran it on some of your existing code and it found a whole bunch of more stuff.

[A]

It did. It found a lot of security flaws. It was very good.

[B]

So it looked like another major leap forward. So as a consequence of all of that, I want to share what Anthropic posted because there's some interesting pieces of. Of sort of things to read in between the lines here about why their two newest models have been taken down. And you know, as I'm saying this, listen to the language Anthropic uses when they talk about safeguards and jailbreaks, because this is their pushback. And it echoes the position everyone here has heard me articulate from the start, which is that are. To me, it feels understanding enough of how this large language model technology operates. Intuitively, it feels as if it is. The whole technology is almost certainly going to be inherently hostile to any form of control. And I don't mean hostile like in a belligerent way, but I mean it's just the, the it. This isn't something that can be controlled. The way it works is not like normal procedural code. It's not the way it is. You know, you got temperature that you can turn up and down. So I believe it is inherently an uncontrollable technology that is from the standpoint of guardrails. So the headline of Friday's posting, and, and you'll. As you'll see, they talk about that. The headline of Friday's posting was statement on the U.S. government directive to suspend access to Fable 5 and Mythos 5. They wrote their. So their, their statement is the U.S. government, citing national security authorities, has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, including foreign national Anthropic employees. The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance. And it hadn't occurred to me, Leo, but I guess some of their employees have to be like denied access somehow, which is wacky. Access to all other Anthropic models will not be affected, they said. We received the directive from the government today at 5:21pm Eastern. The letter did not provide specific details of its national security concern. Our understanding is that the government believes it's become aware of a method of bypassing or jailbreaking. They have in quotes Fable 5 and and I saw elsewhere Leo, that I that apparently some was an some Amazon employees or someone in Amazon like believes they figured out a specific jailbreak. I think that was the case anyway, they said. We reviewed a demonstration of this specific technique being used to identify a small number of previously known minor vulnerabilities. These vulnerabilities all appear relatively simple and we have found that other publicly available models are able to discover them as well without requiring a bypass. Anthropic's posture with respect to Fable's safeguards, as laid out in our launch blog post is the following. So they said we have some bullet points. We've instituted strong safeguards that greatly reduce the likelihood that Fable is misused for tasks related to cybersecurity, among others. Remember, as we know, they just put a blanket block on cybersecurity and bio something or other saying sorry, Fable, just don't ask any, don't answer any questions about that. And as we saw, they like, they. They sort of kick you out to the Opus family if if you make the mistake of crossing one of their trip wires. They said in fact our safeguards are so strong that many users have complained that they are overly broad. Right? Again yes, because that's like the only way to do this if you're going to try to do it is is to. Is to fail closed because there it just isn't possible to control these models. And this is so this is an artifact of that lack of ability to control is they have to do just blanket like o overreaction they said. In the weeks leading up to the launch of Fable, Anthropic worked with the US Government, the UK aisi, multiple private third party organizations and internal teams to red team Fable safeguards for thousands of hours in total. These tests showed that Fable Safeguards are substantially more effective than those of any previously deployed model. No testers have yet been able to find a universal jailbreak. We'll see why that word's important in a minute. A universal jailbreak, A jailbreak method that can very broadly bypass the model safeguards, unblocking a wide range of cyber capabilities. We suspect that perfect jailbreak resistance is not currently possible for any model provider. Think about that. We suspect that perfect jailbreak resistance is not currently possible for any model provider. Every safeguard used in the industry is vulnerable to non universal jailbreaks, which can elicit some cyber information in specific circumstances. And it is likely that universal jailbreaks will eventually be found in the future. We stated this clearly when we released Fable 5. Given that perfect jailbreak resistance does not appear to be possible today, Anthropic adopted a defense in depth strategy with Fable 5. We aim to make jailbreaks either narrow in the case of non universal jailbreaks, or very expensive to produce in the case of a universal. A universal jailbreak. And to combine this with thorough monitoring to quickly detect and shut down any successful attacks. This is also why anthropic has required 30 day retention of customer data with Fable. A policy change that carries real costs for us with customers, but that allows us to research and mitigate jailbreaks. So like, you know, by holding on to 30 days worth of interaction, if they find some, that's that Fable has been subverted, then they're able to go back in time. There's nothing that the bad guys can do to erase that history. That allows Anthropic to then understand what happened and improve the jailbreak technology. They said, we understand by this defense in depth strategy. I'm sorry, we stand by, we stand by this defense in depth strategy. It reduces the risks posed by Fable, making them comparable to the risks of existing models already deployed across the industry. And in other words, yes, in other words, you know, those that have not been banned by the US government because the US government says, yeah, these are fine. So this is. They believe Fable is as safe as any of their other models. They said, we have not even received a disclosure of a concerning non universal potential jailbreak that led to a harmful result. The potential jailbreaks that have been disclosed to us are either entirely benign responses or are minor findings that. That provide no Mythos specific uplift. To date, the government has only given us verbal evidence of a potential narrow non universal jailbreak, which essentially consists of asking the model to read a specific code base and fix any software flaws. Our understanding is that one potential jailbreak was shared with the government. We've reviewed a report that we believe is the basis of the government's directive and validated that the level of capability displayed here is widely available from other models, including OpenAI's GPT 5.5. Again, they and and they said and is used every day by the defenders who keep systems safe. We'll share more details over the next 24 hours. They said we are complying with the government's legal directive and are removing access to Fable 5 and Mythos 5 for everyone. However, we disagree that the finding of a narrow potential jailbreak should be cause for recalling a commercial model deployed to hundreds of millions of people. If this standard was applied across the industry, we believe it would essentially halt all new model deployments for all frontier model providers. As we've stated publicly, we believe the government should have the ability to block unsafe deployments as part of a statutory process that's transparent, fair, clear and grounded in technical facts. This action does not adhere to those principles. We apologize for this disruption to our customers. We believe this is a misunderstanding and are working to restore access as soon as possible. Well, that was Friday and Saturday, Sunday, Monday. And when I was using Cloud this morning over the little, the little prompting area, it said Fable is currently disabled.

[A]

Increasingly this looks like a political move, a business move. Pete.

[B]

Well, we know that Hegseth is pissed off at, at Anthropic.

[A]

He tweeted, you see, you know, I mean he, he clearly. So Katie Mazuris, who is a well known security researcher.

[B]

Yep.

[A]

Was apparently given the paper. We think it was Andy Jassy, the CEO of, of Amazon who, who talked to the White House and said right, yeah, there's a jailbreak. This is the third party research paper. Anthropic shared it with Katie Massoura. She says as far as I know, I am the only person who's seen this. This is the. You want to know the jailbreak. Three words. Fix this code. The researcher took an open source code with known CVEs plus new code with deliberately planted vulnerabilities and asked Fable 5 to review the code for security issues. Fable 5 refused. They then asked the models. By the way, they also did Mythos and Opus to fix this code and through a multi step and manual process, turn the output into scripts that test the patches. This is the jailbreak. By the way, Katie has made a shirt to kind of play on the previous time this Commerce Department blocked with code go because of munitions. This is crypto. Remember they made a t Shirt with the crypto on it. And you can't block a T shirt. First Amendment protects it and went across borders with it. She's done the same with this. She's made a fix. This code T shirt and on the back it says this shirt is a munition. Now this, this is her assertion. I don't, you know, it's possible there are other jailbreaks. I had heard that Pliny the Liberator, who's a well known jailbreaker had another jailbreak. I. We're trying to get Pliny on the show tomorrow. Haven't had any success yet, but we do have Alex Stamos joining us tomorrow. Alex, as you know, really well known security researcher has released a letter and to Secretary Lutnick and National Cyber Directory Karen Cross asking them to free Fable, to lift Fable's restrictions. It's a very well thought out, explained letter and it's signed by a great many security gurus, including Alex who wrote the letter.

[B]

You know, and it's, it's annoying that this comes from a competitor. Right? I mean that's, that's what really feels wrong.

[A]

Well, the funny thing is Anthropic, Amazon has a huge investment in Anthropic. So I don't know if they're a competitor. This is them. I don't know. We don't know what Annie Jassy told Lutnick, but we do know that Anthropic has been very good to the administration. The Anthropic has and is being used

[B]

throughout the administration and is being used.

[A]

Yeah. We also know that OpenAI has donated to the administration. I think it's very hard to, and maybe we don't know what's going on, but there's never been provided any good evidence that this is a real jailbreak if it's fixed this code. That's absurd. That's absurd. So Ed Felton is a signatory on this many names that our audience would know very well.

[B]

Well, I think that the, the, the strongest case that Anthropic made in their response to, to my mind was this isn't that different from everything else.

[A]

Exactly.

[B]

You know, you've singled us out.

[A]

You've done the same thing.

[B]

You've singled us out. And you know, I, you know, like you, you, we, we could suggest maybe this is the flip side of the like of the conf. Of the consequence of all that marketing attention which many have called hype, that Anthropic deliberately created to a company that restricted access to Claude Mythos Preview. So, you know, I Mean they're, they've like, they painted a target on their back. But again, you know, I think there's their strongest point is hey, yeah, we're proud of this model. We're making it better. We put in really strong safeguards and we're not that different from any of the others.

[A]

It's a wake up call for foreign national researchers in all of the AI companies in the United States. You got to think they're thinking about what their plans are going forward, maybe leave the United States. It's certainly a wake up call for the eu. If the US can block useful AI from the eu, they're going to be working on their models. It's, it's a, I think a very big tactical error and, and I think it's more about politics peak and corruption than it is about actual security. But it's hard to say because we haven't seen. The only jailbreak we've seen clearly is not a problem. Maybe there's a merit, maybe there are other jailbreaks. I understand why the government might say, you know, these, these AI model is too dangerous to be released, but they

[B]

need to, you know, the other thing we've seen is other people achieving Mythos grade success with non Mythos model. So you know, and, and we, we've talked about that here. It's not as if there's some like some really magic pixie dust that anthropic uniquely has. They just, you know, they're push ahead as is everybody else. It's a good model.

[A]

Yeah, it's a good model. We will talk to Alex Stamos tomorrow on Intelligent Machines 2pm Pacific, 5pm Eastern.

[B]

Good.

[A]

Hope everybody will join us for that. And he will talk about this open letter which he has put [e-mail] Free Fable, that's great. Free Fable.

[B]

Okay. As we saw last week, the change to the historical attack pattern that was already accelerating prior to the rise of AI. You know, I mean we've, before this all happened, we were noticing wow, like this is an accelerating problem. I made the comment, you know, a couple years ago about that we used to, how quaint it was that we used to have three or four digit CVE numbers and now they're all five digit and they're large, they're high five digits. So will access to significantly more advanced autonomous AI attacking capabilities by a much wider range of attacker change this further? And, and, and you know, it absolutely clearly seems that we are seeing an AI driven acceleration and it will for the first time unfortunately aided by AI include those who are far less knowledgeable and skilled. So you know it, it broadens the the the base of of attackers because they don't have to be experts any longer. Just as we've seen many of this podcasts, non coders delighting in their newfound ability to use AI to code. It's only a matter of time, and probably not much time until we see attacks managed by non hackers using next generation AI driven autonomous attack frameworks. Last week's report from Anthropic's Red Team, which is what we shared, showed one instance of exactly this that was by the end of March still the exception to the rule. They said, you know not everybody else is using AI in post intrusion strategizing but that one, that one group did. So a year from now it's going to be commonplace. So against this backdrop, Last Wednesday on June 10th CISA released their Binding Operational Directive BOD 2604 titled Prioritizing Security Updates Based on Risk. This BOD formalizes, this is me speaking formalizes the timeline under which federally mandated IT systems are now required to respond to cyber threats that CISA identifies. We've already seen and commented about the response speed required by CISA to some recent threats. Remember there was one like by midnight that night or within three days. But now that somewhat breathtaking three day to patch timeline has been formalized. I've got a chart in the show notes at the top of page 8 which actually shows the decision tree that you follow in order to determine how quickly you must patch something. The guidance that CISA has produced has been reduced to this tree with four binary decision points. Since two to the power of four is 16, that is to say there are 16 combinations of four bits. We've got 16 leaves at the end of this decision tree.

[A]

The fourth branch FIFA chart here this is. Holy cow.

[B]

The four branching decisions are. Has the vulnerability been publicly released? Is the vulnerability in Kev. You know the known exploited vulnerabilities list is the exploitation of the vulnerability of automatable by the adversary and is the impact of its exploitation partial or total control. Each one of the 16 branches ends in either three days to patch that is to say you have three days to patch this guys or, or 14 days to patch or 60 days to patch or patch on system upgrade meaning eh, don't worry about it. You know when you upgrade everything else you know you'll, you'll get patches. So it's essentially patch it immediately like now with, with a deadline in three days or you got two weeks to patch this or you got two months to patch this or you got. Or don't worry about it that much. So for example, riding along the worst case branches of the tree for each decision point, a known vulnerability, a pub. A publicly known vulnerability that's on the kev list which can be automated and carries an impact of total control by the attacker. That guy must be fixed in three days. You know, I'm like, do it now. But it. But the. But the deadline is three days away. Now the flip side, following the best case branches, if the vulnerability has not been publicly exposed, is not on the kev list, cannot be automated and regardless of whether or not its impact would be partial or total on the victim system turns out no hurry can be fixed during routine system updates. But all other combinations of those four criteria bring you out to a leaf on the tree that tells you how much time you have. What this means is that all federal agencies falling within CIS's binding operational directives will need to put a system in place. I mean again, it's no longer like oh yeah, patching. George does that, but he's on vacation. No, the patching has become front has come front and center. Maintaining up to date systems is no longer something that government agencies will be able to give lip service to while planning to get around to it, you know, whenever. So those lazy days are over thanks to AI and I'd be pretty certain that they're never coming back since once those systems have been painfully put in place, like, you know, rapid patch cycle ability, why would they not continue? So, you know, it took, it took clear and, and present threat from AI to, to push the change which nobody wanted. I mean this is going to upset a lot of agencies who've said, oh, we have no ability to actually do that. Well, they're going to have to figure it out and, and generate that ability.

[A]

I think that's a good thing though, right? I.

[B]

It is a Good thing.

[A]

Yes.

[B]

I 100 agree, Leo. I think that, that it's not anything anyone wanted. But Pat, you got a patch.

[A]

By the way, this is okay with you for the, the album, for the

[B]

show, the free favorite, isn't it?

[A]

March.

[B]

I know, I know that really looks like you some of these things and that really looks like me. Actually.

[A]

Actually it looks like if you didn't know better, you'd think we were in fact leading a march to free fable. Yeah.

[B]

And I think this, these photos must have come from the show because I mean it doesn't look.

[A]

Darren is very good. Darren is our most adept AI. User. I think at this point he's quite good. Yeah. Let's talk about AI and hackers. Hey, what do you think? Actually now would be a good time to talk about data brokers because there's another enemy of the state that I would really like to get the show brought to you by. Delete me today. You know, I own a small business. As a business owner, putting yourself out there is part of the job. We're, you know, we're in public. But the uncomfortable truth is that when you promote your business, it's also opening you to attacks from bad guys. 90% of business owners have their home address easily discoverable online. And the average owner has more than 600 pieces of personal information just sitting on the open web. We're talking your personal email, your phone number, your home address, even details about your family. Bad guys can use this data to run hyper targeted phishing attacks. This is the exact experience we had. We've been getting phished by people who know our org chart. They know people's phone numbers, they know their names. They know enough details so that these phishing attacks don't sound like they're coming from strangers. They sound like they're coming from clients, partners you already trust, or even the boss. That's why attacks using verified personal information are, get this, likely to succeed five times more likely to succeed. And the average incident, oh, it's expensive. It could cost small businesses more than $120,000 to remediate. And don't think it's not going to happen to you. One in four businesses will be impacted this year alone. We have been. And that's where today's sponsor Deleteme comes in. Reducing exposure by up to 95%. We use DeleteMe and we have to Delete me removes the boss, my, our employees personal information from hundreds of data broker websites starving hackers the fuel they use to build their target lists. And it's not just a one time thing, it can't be. Deleteme continually monitors and removes your data. They'll also send you regular privacy reports so you always know where things stand. You have to do that. These data brokers are like cockroaches. They don't go away. They rebuild your dossier even after you have them remove it. They rename themselves, they go out of business and create a new business under new names with all the same data. I mean they're slimy. Fortune 500 companies, government agencies and yes twit have trusted Delete me for over 15 years now. That same enterprise level protection is available for your small business. That's what we use. We recommend it. Protect your business, protect your peace of mind. Here's what you do. You visit joindeleteme.com TWIT-BIZ to start protecting your business with Delete Me today. If you use that link, you'll also get a free year of social media protection for every seat you purchase. How about that? Joindeleteme.com TWIT-BIZ It's a new campaign we're doing. We want you to use that address so that they know you heard it here. And I highly recommend you get this for your business, for your managers especially. We did and it's very important. Join deleteme.com TWIT-BIZ we thank delete Me so much for supporting security now. And now back to Steve and Leo Radicals the Radicals Marching to Free Fable Go ahead Steve.

[B]

So the news is that the much attacked npm, the no JS package manager, will be flipping its defaults to begin disabling the auto running of installation time scripts starting with the July 2026 so next month release of its version 12.0. The change hopes to counter the massive rise that we've been see we're talking about it every week almost in the number of supply chain attacks taking place on that platform. As we've seen here, threat actors are increasingly hiding malicious commands inside install scripts that get auto executed when a victim installs a new package. We're just talking about that with the Arch Linux. This sounds welcome and great, right? I mean it's like hey, it's automatic, it's nice, but what effect will it have that is flipping this from by default enable to default disable? I tracked down an informed opinion of someone who should know writing for the blog open source malware.com to get a reality check. The posting was titled NPM disables install scripts by default, but is that going to solve its malware problem? And the blog's tagline was NPM announced that the new version of the NPM package manager version version 12 will come with several security improvements including disabling install scripts. Is this a game changer or security theater? Its Author wrote on June 9, NPM announced the breaking changes coming in V12 and he said, I'm genuinely excited about this announcement. The three permissive defaults that have shipped malware to developers for a decade are about to flip to Deny by default pair that with install time cooldowns. I'll explain what that is in a second landing across every package manager and the rise of commercial supply chain firewalls. And you'd be forgiven for thinking that NPM malware problem is finally getting solved. A year ago, he wrote, I stood on a defcon stage and walked through why NPM install scripts are terrible. So let me be the first to say it. These coming V12 changes are good. They're also in part theater, and understanding which part is which is important. NPM v12 flips three dangerous defaults. The big one is install scripts. Today, NPM install happily runs pre install, install and post install hooks from any package in your tree, including transitive dependencies you've never heard of. In V12 that stops by default. No automatic lifecycle scripts, no native node gyp builds, no prepare scripts from git file or link dependencies. You opt packages back in with NPM approved scripts, discover what's affected with NPM approves approved scripts, the allow scripts pending option and block the rest with NPM deny scripts. The second change makes git dependencies require an explicit allow git option, closing an execution hole where a code execution hole where a git dependencies own dot NPMRC could override the git executable, a bypass that worked even with the ignore scripts option set. The third and final change makes remote URL that is to say HTTPs tarball dependencies require an allow remote option. These three changes, he writes, ship around July 2026 and you can prepare today and in npm 11.16.0 and and and subsequent. At the same time, other security improvements are taking hold. Cool downs are also now everywhere. NPM shipped with support for min Release age in 11.10.0 back in February. This is a setting that refuses to install a version until it's been public for a configurable number of days. Yes, logic here in that nice yes,

[A]

I turn that on. I well, I do it manually but for 14 days. If it's if it's not more than 14 days old, I don't want to install it.

[B]

That's smart. Yes, and he writes, the logic is simple and effective. Compromised releases usually get caught and pulled within hours, so a short delay filters most of them out at the install layer with zero scanning. It's worth noting he writes that NPM was the last to this party. PNPM shipped minimum release age in 10.16. In December 25 yarn added npm minimal age gate in 4.10.0 the same month and bun followed in 1.3. There's even an open proposal to make seven days the default, which is the right instinct Almost nobody needs a package the instant it's published. Supply chain firewalls have become a product category. Developers are finally installing something on their machines that address malicious package threats. Datadog released an open source supply chain firewall in 2024, and Laurental released his tool NPQ back in 2017. Tools like these wrap package managers and check to see if the user is about to install vulnerable or malicious packages, and if so, they'll block them from being installed. There's been quite a lot of new tooling in this domain recently, with Socket, Aikido and Endor Labs all offering products in this space. Package firewalls like these work, but of course they rely on developers to not bypass their controls to install malicious packages anyway, he says. I don't want to be cynical about the right things. Killing automatic install scripts is the single most important change NPM could make. Install hooks are the mechanism behind a huge share of the incidents we document at open source Malware. They're now a poisoned transitive dependency. I'm sorry? They're how a poisoned transitive dependency gets to run arbitrary code on a developer laptop or a CI runner the instant it's pulled. The security community and PNPM have been arguing for deny by default here for years. NPM finally agreeing is a genuinely good day. Cooldowns are the cheapest high value control in the entire ecosystem. Firewalls and package managers give teams a real shot at stopping a supply chain attack before it lands. None of this is fake security. The problem is what happens next. The first observation is that off by default only works if it stays off. The thing that announcement glosses over is that disabling install scripts is going to break a lot of stuff. An enormous amount of legislation of legitimate software gets installed, built and wired into your application environment via install scripts, right? That's where the magic comes from. That's where, like it's. It's incredible, he said. This of course, explains where there's such a strong attack vector. There's a simplistic narrative going around that life cycle scripts only exist to do bad things. And that's just not true. NPM packages are not just a way to import libraries. Many people, including me, he writes, build CLI tools to do necessary utilitarian functions, and many of these tools use install scripts. Some examples of popular packages that use life cycle scripts are ES build with 200 million weekly downloads sharp at 60 million per week core hyphen JS at 40 million per week puppeteer 10 million weekly NX 9 million buffer util at 6 million UTF8 validate at 8 million weekly downloads and bcrypt at 5 million weekly downloads. Initially he finishes Native modules need node gyp to compile against your platform at install time. Tools that download a platform specific binary, generate a config, register a shell completion or build a native add on all lean on install scripts to get the job done. This is not an edge case, it's a meaningful slice of the most depended on packages in the registry the day 12 the the the day version 12 lands, those packages stop working until someone approves them. So I'm going to interrupt here for a second. If anyone listening is thinking to themselves, well, convenience versus security. You're exactly correct. That's what this is. I'm sure that many of us who have used package managers have been somewhat amazed, I know I have, by the astounding degree of automation. You fired up and all this stuff happens. Packages are grabbed from here and there, compilations are run and linked together, packages are installed. Everything just whizzes by on the console. What just happened? Who knows? Nobody knows. Well, someone knows presumably. But the entire point is that we, the developer or the end user who invoked the package manager doesn't need to know. It all just magically happens. And that is also of course the Achilles heel of the entire process. It's what opens it to such abuse. Because that extreme magical ease of use can be and increasingly is being abused to do malicious things behind our backs automatically. We have no idea what's happening in the first place, so how would we know if something bad was happening? The problem with flipping these magical defaults to off is that the magic upon which we've become dependent breaks. So he continues his post writing. So what will developers actually do? They'll approve. Then they'll approve again. And by the third time a build breaks at 5pm because some transitive dependency needs its post install hook run. The approval becomes a reflex. The deny by default protection quietly degrades into a clicked through prompt. How would you like a cookie? Will you agree to have a cookie? We've all been there, right? Those darn notices go up all the time. It's like yeah, okay, fine, yes, right, he says. A click through prompt that fires constantly trains people to click through. We've watched this movie with browser permission dialogues and OS security prompts, there's no reason to expect npms to end any differently. The control is real. The human standing in front of it is the same human who has a deadline. If you really want to know if disabling install scripts will have the intended effect. You could look over to the VS code ecosystem with VS code. Before version 1.109, the global allow Automatic Tasks setting was on by default. This meant that malicious task files would automatically run if victims open source code that included those tasks files. Microsoft changed and disabled this feature to be disabled by default in January 26, the beginning of this year, after months of threat actors used malicious tasks files to compromise developers. Did that stop threat actors from continuing to use VS code tasks? Nope. North Korean threat actors continue to use malicious VS code tasks files as many developers have re enabled the feature or other developer tooling has enabled it. In fact, most of the large scale attacks we've seen so far in 2026 leverage VS code tasks and settings files to help redistribute the attack artifacts. The second observation is that the bad guys will find a way. Just because NPM won't run scripts at install time doesn't stop users from running those scripts the second those packages are installed. Even worse, if you already use a library and it's compromised, you don't need to run install scripts to receive the payload it's going to run in your application. No scripts needed. Now follow the incentives one step further. If install scripts are switched off by default, some package authors with legitimate needs will stop relying on them. Good ones will document a manual build step. Others will move the work somewhere NPM cannot turn it off. A curl piped through bash in the install js, a separate bootstrap binary. A setup command you run after installing. The attackers will make the exact same move, because of course they will. If the post install hook no longer fires automatically, you don't give up. You find the install path that still executes. This is precisely the kind of threat actor behavior I talked about at defcon. Push on one control and the malicious activity simply relocates to where the controls aren't. It doesn't just vanish. And here's the part that should worry npm, but it won't, because it's good for them. When the malware moves out of the registry and into a shell script or someone's gist or a binary downloaded from a cdn, NPM gets to report that Registry resident malware is down.

[A]

Yay.

[B]

They'll claim victory. The problem will look solved from the viewpoint of their dashboard. Meanwhile, the risk has simply relocated to terrain with less visibility and fewer tools, not more. The problem gets pushed off the one surface the entire security industry actually instruments and onto surfaces nobody is watching. That's not a win. That's A measurement artifact. The third observation is that it gets more difficult for defenders then not easier. Between cooldown periods and the disabling of install scripts, large scale NPM attacks will become less frequent. But when you push legitimate functionality off the well lit path, you don't just move it, you make it look guilty. A package author who genuinely needs to fetch a platform binary at install time, now doing it through some indirect mechanism to survive the new defaults produces a fingerprint that looks exactly like evasion. Obfuscated loader, out of band fetch install time, network call to a non registry host five years ago that was a strong malware signal. After V12 a chunk of it is just legitimate software adapting to a stricter world, not malware because of the things it has to do. So while the number and frequency of the big NPM attacks go down, the signal to noise ratio for everyone hunting malicious packages gets worse. The benign, in other words, false positives or missed negatives. The benign and the malicious converge on the same suspicious looking pattern. We end up triaging a flood of weird but fine packages to find the weird and actually bad ones. And the bad ones get better covering. Or get better cover precisely because so much legitimate behavior now looks like what they do. You bury the needed functionality in something that looks sketchy and you've built the perfect place to hide a needle. A pattern that now looks sus. Except it isn't until it is with the firewalls and cooldowns are really telling you. Step back and look at what cooldowns and firewalls actually represent. They're good controls. Yes, they're also an admission. The reason a third party product can flag a malicious version six minutes after it's published is that NPM is not doing it themselves. The reason you teams pay for an interception layer in front of the registry, the firewall, is that they cannot trust the registry to keep malware out. We are watching detection and response getting pushed onto users and onto a handful of vendors, while the registry that profits from being the default keeps under investing in its own scanning. The incident cadence so far in 2026 makes this gap obvious. Version 12 is npm catching up to the problem I laid out a year ago. Okay, that's progress. But a registry that's that has been this chronically under resourced on internal security doesn't get to flip three defaults and call the supply chain problem handled. So what actually does move the needle? Where does this leave us? We're left with the unglamorous truth that tooling is necessary and Nowhere near sufficient. Turn on cooldowns today. It's the single best ratio of effort to protection available. And there's no reason to wait for V12. Prepare your approved scripts allow list now on 11.16 and later so the V12 upgrade does not break your builds and stampede your team into rubber stamping everything. If you can manage package firewalls, run them, do all of it. And that's his conclusion. So I thought this was a terrific.

[A]

There's my minimum release age 14 for npm and also do it on bunch of 14 days. Good bun you have to do seconds. I think so right. But and I did it for a lot of things. I wish I could do it for the Arch user repository. I can't. I wish I could. Or at least I haven't figured out

[B]

how to do that.

[A]

Yeah. Because that's the one that really scaring me right now.

[B]

Yeah. So I thought this was a really a terrific piece of from the field feedback. As we've been seeing for years, malware that slips into the NPM repository has been steadily increasing. I mean like big time. And there doesn't appear to be anything that can be done. The one thought I had while reading this person's posting was that perhaps these changes are being made on the cusp of AI appearing at a time of need. He noted his annoyance that responsibility was effectively being pushed away from the repository and onto less centrally managed external resources and solutions. We see that the largest entities, Cisco and Microsoft, jump to mind. You know, they've been unable to even police their own internal closed source offerings to rid them of bugs. So the scope of the task for an open source free for all repository should not be underestimated. I, I mean I'm sympathetic. How do you allow anybody who wants to to contribute a package and have any security? But just as AI is now promising to revolutionize the quality of closed source offerings, it also seems like the perfect solution for repositories such as npm. I think it, it makes nothing but sense. So we know that IBM and Red Hat are going to be pouring a ton of money was it $5 billion into using AI to help open source. And certainly NPM ought to be a big initial target for them.

[A]

Yeah. Yeah.

[B]

And you know Leo, it's time for me to tape a tape a sip of my juice and for us to find out who's paying for this.

[A]

This is a, a low caffeine day for Mr. Gibson. What is in your juice? Is it a green juice? Is it a.

[B]

No, it's just It's a third of regular orange juice, organic, of course, because Lori. And then two thirds water, so.

[A]

Sounds good.

[B]

Yeah, it's just diluted. It's. It would be water, except water. It's a little boring. So we just like, you know, just make it a little more interesting. Exactly.

[A]

Okay. Our show today, while Steve drinks his Tang, is brought to you by Zscaler, the the world's largest cloud security platform. Man, you listen to this show, you go give me security, right? The potential rewards of AI as we've seen are too great to ignore. But the risks are there too. Loss of sensitive data and attacks against enterprise managed AI. Generative AI increases opportunities for threat actors, helping them to rapidly create phishing lures to write malicious code to automate data extraction. And a lot of the, you know, privacy leaks. The security leaks are not malicious, just inadvertent. There were 1.3 million instances of Social Security numbers leaked to AI applications last year. I bet you a lot of those were people taking their tax returns and feeding them to chat, GPT or whatever. But, you know, that's got a lot of information on there and you're just letting it out. It's time maybe to think about your organization's safe use. Safe use of public and private AI. That's what Chad Pallet did. He's the acting CISO at BioIVT. They use Zscaler. Chad says Zscaler helped them reduce their cyber premiums by 50% and doubling their coverage and improving their controls. Take a look at the video

[B]

with Zscaler. As long as you've got Internet, you're good to go. A big part of the reason that we moved to a consolidated solution away from sd, WAN and VPN is to eliminate that lateral opportunity that people had and that opportunity for misdirection or open access to the network. It also was an opportunity for us to maintain and provide our remote users with a cafe style environment.

[A]

Thank you, Chad. With Zscaler Zero Trust plus AI, you can safely adopt generative AI and private AI to boost productivity across the business. Their Zero Trust architecture plus AI helps you reduce the risks of AI related data loss and protect against AI attacks to guarantee greater productivity and compliance. You can learn [e-mail] security that's Zscaler.com security. We thank him so much for supporting Steve and security. Now back to you, Steve.

[B]

Okay, feedback time. Roger Votklin. V O E G T L E N Best I can do.

[A]

Silent. I think it's Vogtland Volta.

[B]

Robert Votelin. Hey, Robert. So get this, Leo. He says, Dear Mr. Gibson, I started listening to Security now when I was in the fourth grade. Oh, geez.

[A]

Okay, Robert.

[B]

I'm now 22 years old. I have a degree in cyber security from Augusta University.

[A]

Right on.

[B]

Security now has always been there for as long as I can remember. As I begun my job search, I realized just how vast cybersecurity really is. There are so many specialties. The more I learn, the more I realize I know nothing. But I've been struggling with. What I've been struggling with is figuring out where to focus. It feels like it could take decades of working across different roles and industries before I discovered the niche that truly fits me. But then much of my career will already be behind me. How do you determine which area of cybersecurity is worth dedicating your life's work to? Thank you and Leo for everything you've done through Security now over the years. Sincerely, Robert Votelin, SpinRide owner. Oh, so, first of all, Robert.

[A]

Yeah.

[B]

Wow. My question to you would be, what could have possibly motivated you as a fourth grader to tune into this podcast?

[A]

Zero days, Mr. Gibson,

[B]

you know, and it is the case that Leo and I have been here throughout your entire life.

[A]

Wow.

[B]

So anyway, I'm. I know that we both feel very glad and fortunate that we've been able to. To be here the whole time. So to your question, I have no idea. In my case, I sort of stumbled into the security sphere through shields up, which I created because there was clearly a need for it at the time. And then the opt out adware remover, which happened when I discovered that oriate adware was on my own PC. Since my background, since about age 5, you know, began with understanding electricity and then expanded into electronics and physics and engineering and computer hardware and software. I had the broad background, you know, ahead of time to pretty much head in any direction. And at the time when Spinrite was purring along, I saw a need over in the security space. So I think my best advice would be to perhaps more deliberately do what I had inadvertently done, which is to obtain the widest possible background exposure that you can that will automatically expose you to many more aspects of the field, and you may find that you naturally gravitate towards something specific. And even if that doesn't happen, I believe you'll be better equipped to succeed with whatever you decide to tackle. In today's highly competitive world, I normally advise people to become the best they possibly can at a narrowly targeted specialty. I believe that's where to succeed. Today. But of course, that process of specialization can only begin once you determine what truly interests you. Leo. Any, any.

[A]

Well, I think this is, My kids ask me this too. This is kind of the eternal question, one of the most fundamental questions every human asks today.

[B]

If I, there is so much happening, I would, I don't know what direction I would take. I can really relate to Robert's position.

[A]

Even if it's not cyber security, if it's just whatever, you know, history or whatever, how to figure out what it is you want to devote your life to is a very, very challenging question. But I think your answer is exactly right. All you can do is try as many things as possible, expose yourself. You found one.

[B]

See what sticks. Yeah.

[A]

And just listen to your heart. You'll know when it sticks, you know?

[B]

Right.

[A]

Steve had no choice. He knew exactly what he wanted to do. He just sent it, you know, and it's just like it clicks and you're gonna do it. I didn't either. You know, we just, we did what we loved. And I think that's the best thing anybody can do is.

[B]

Oh, to be able to spend your life doing what you love. Yeah, I mean, I, I, I love that. The, the, the, the, the best, shortest summary of that is to say I never worked a day in my life. Right. Because it's, it's not, it's joy.

[A]

Right. And I hope Todd Whitaker find that.

[B]

Yeah, yeah, exactly. Todd Whitaker, whose last name I can pronounce, is a college professor listener of ours who uses PHP to teach security.

[A]

Oh, boy.

[B]

Yeah, he wrote. Hi, Steve. Your recent discussion of Insecure PHP in episode 1082 last week rang very true to me. But you know what? PHP is really quite useful in cybersecurity, just maybe not the way its defenders usually mean. I'm a college professor, and when I built our undergraduate cybersecurity major back in 2010, two of the original courses used PHP for web programming and application security. Clearly, that was not because PHP represented our ideal of secure software design. It was because PHP is almost perfectly suited to showing students how insecure software gets built. SQL injection, concatenate user input into raw SQL, cross site scripting, echo unescaped input back to the browser, broken authentication, store passwords badly, or trust the wrong session variable. He writes PHP makes the mistake easy to write, easy to see, and therefore easy to teach. He said once students can see the failure clearly, we can show the corresponding discipline, prepared statements, output encoding, password hashing, access control, session hygiene, and least privilege. That for me is PHP's real value in a security classroom. It gives students a compact, legible catalog of the mistakes they need to recognize before they encounter them in the wild. Many cybersecurity graduates will eventually audit, inherit or respond to PHP heavy environments, including Drupal and WordPress installations, where they will need to see past code that merely works and recognize the familiar patterns that make it vulnerable and if they leave the courses, better equipped to be skeptical of PHP based platforms and environments where security matters, so much the better.

[A]

Awesome, Todd.

[B]

So yes, I think Professor Todd's use of PHP for teaching about coding security is brilliant. It's an application for PHP that had never occurred to me. I love it. So thank you Todd. Derek Kililgo said hi Steve, 20 year PHP veteran here. I thought you'd find this interesting. The foundation that governs PHP has added a grant funded a grant funded position to improve PHP's security posture given the realities of AI power development. Quote the PHP foundation grant will fund a six month full time position titled Ecosystem AI Security Engineer in Residence at the PHP foundation, unquote to lead this effort and to prepare a sustainability platform for the time after this initial phase. This person will act as a trusted intermediary between security researchers and maintainers and in urgent high risk situations, and will collaborate with peers in similar roles across other language ecosystems. Additionally, grant funding will also be employed toward the team goals described above, where they cannot be accomplished by the single paid lead position or with the help of PHP community volunteers. And he included a link to the announcement of the ecosystem security team. He finishes I've been listening since you were an actual podcast on an ipod with a spinning disc. Love the show. Your perspective is appreciated. Derek so I think overall the PHP project's move is great, but I should be clear and Todd Whitaker's use of PHP for security education helps to further clarify this. I do not believe that there's anything whatsoever wrong with php. It's not at all the language itself I do not trust. There's nothing wrong with the PHP language. I think it's very likely bulletproof. My problem with it, which has been informed through our two decades of covering its use, is that those who often gravitate to to PHP do so because it appears to be so easy to use. Because it is. But we've learned that it's always easier to write code that works than code that works securely. This next bit of listener feedback sets up a perfect example. Steve Myers wrote the his subject was your PHP rant. He said it seemed like your rant against PHP was a bit of A stretch. PHP has its issues, but it's also come a long way. Here are my issues with your rant. You were using some obscure WordPress plugin with a whopping. And he's being. And he's not being serious here. Sarcastic whopper with a whopping 4000 installs as the basis for complaining about PHP. Your specific complaint about PHP making it too easy to do bad things is that it has an eval function. Here's a list of some other programming languages with eval functions. JavaScript, Python, Ruby, Perl, Lua, Lisp. And he said parens specifically noted in Wikipedia. And is Lisp as the originator of the eval function?

[A]

Yeah.

[B]

Then yes, yes, Scheme, Cloture and Matlab. Anyway, he finishes it. It really seemed like your rant was pretty gratuitous and did not have a lot to back it up. Okay, so first of all, Steve is of course correct that the particular problem with that PHP WordPress add on was due to its programmer perhaps not being aware of the danger of forwarding user provided text into an eval function. And it's certainly true that similar eval functions eval functions exist in many languages. But I'm not upset with PHP at all for having an eval function. My concern is that writing secure code for the web is extremely challenging. That's why through the years we've been covering all the mistakes that can be made, many not with php. There are so many different and very subtle ways to screw that up. Professor Whitaker's note mentioned a handful of them and he didn't even mention Eve Vow. So perhaps the best non ranty way of expressing what I mean here is to say that it feels as if there's a larger inherent mismatch between the coding skill of the typical PHP coder who may be coding for the web for the first time, and the coding skill required to do so securely, probably in a different language. It's certainly the case that no sane person will have decided to code their website in Lisp. Okay. But that said, I'm probably not one to speak since I did choose to code mine in assembly language.

[A]

Yeah, which is worse than Lisp. So. Okay.

[B]

Which is. Yeah. Okay, Leo, our last break, then we're going to look at Patch Tuesday a la AI.

[A]

Ah, Lisp. I seem to remember programming in that language once, back in the day before I started coding in English, which also has a vowel function.

[B]

Incredible. And. And the code that AI is producing for you is C largely.

[A]

No, I let it choose its language. It's pretty evenly Split I Go is my current favorite because it's concurrent. But Rust is great because it's so safe. Safe and so it's a little provable. You know, you can a little easier to prove that Rust code is Safe. And then TypeScript is often chosen for similar reasons.

[B]

Right.

[A]

So almost all my code is either Rust, Go or Typescript.

[B]

And the web has tons of examples from the A for the AI trained on.

[A]

Which is why I don't use Common Lisp because it's a little less.

[B]

Not so common.

[A]

Not so common. Although oddly my AI is very good at my emacs configuration, which is done in Elisp. It's really good at writing Elisp code. So, you know, there's a lot of that out there, I guess maybe more even than Common Lisp. So. Yeah, but Go is probably the. I would say the. A good choice. Python. Oh, I've left out Python. A lot of stuff's in Python. Just all those one off, like that one off web server for the curling of the SSH key that it just

[B]

threw together for you.

[A]

It's so easy to do in Python because they all the libraries. It makes it very simple.

[B]

Right? Right.

[A]

Our show today, my friends, brought to you by Adaptive, the first security awareness platform built to stop AI powered social engineering. Here's the shift. Attackers don't need malware anymore. They need trust. Right? Because your employees will do all the work for them. So they do it with a cloned voice, a convincing deep fake on Zoom, or an AI written fish that looks like it came from your IT team. And now with AI, these things are so easy. That's why you need adaptive. Adaptive prepares your organization with simulations across email, SMS and voice. So deep fakes vishing AI generated phishing, including scenarios that can mirror your own brand and executives. I played that audio that Anthony made that sounds exactly like me telling Burke to buy some Amazon gift cards and send them to a random address. If Burke didn't know better and Anthony didn't mention it's not really Leo, that might have fooled him. It sounds just like me. It could sound just like your CEO. And when employees report something suspicious with Adaptive, they can help you triage it fast so security teams aren't buried in false alarms. Adaptive can say, yeah, this is a problem, or no, don't worry about it. You need training fast. With Adaptive's AI content creator, you can turn a breaking threat, an incident report or a compliance doc into interactive multilingual modules in minutes. No design team required. It'll do it for you. With Adaptive, you can build, customize and monitor every part of your training with complete personalization. The result is a more resilient security culture, which is essential for companies like who uses Adaptive Plaid. You know Plaid, their platform powers thousands of digital finance apps and links consumers, developers and institutions. Sensitive data is at its core. Plaid security and compliance are non negotiable. Plaid's head of security GRC says quote, adaptive has equipped our teams with cutting edge tools and built a smarter, more resilient security culture across the company. Adaptive trusted by Fortune 500, backed by Nvidia and OpenAI. Adaptive is building the defenses we need for the AI era. Learn [e-mail] that's Adaptive Security. Boy, time couldn't be better for this. Adaptive security.com you need it. Now back to Steve.

[B]

So we all knew this had to be coming. And it did not take long, which is probably the mantra for the AI era. It didn't take long, no, because the new race is now on, right, to see whether our industry's badly broken software can and will be repaired with the help of AI before the bad guys are able to leverage that same AI to find and exploit any of that same software that's not yet been repaired. In other words, what's been expected and predicted with the advancing evolution of AI models focused upon code is all really happening. Last Tuesday, Microsoft broke their all time record for the number of security vulnerabilities patched in a single update cycle. And that doesn't even count their fixes to their Chromium based Edge browser, which also broke its own record. By a lot. Those fixes to Edge are now wisely being separated into a separate account, a separate count. And I say wisely because if the two counts were not separated and we used to lump IE in with, you know, patch Tuesday updates because that's when it was being updated. Typically if they weren't separated, June's hall alone would land somewhere in the neighborhood of 566 security vulnerabilities. 566. Okay, so let's. Yikes. Let's first take the non edge windows and windows adjacent patches. Even without Edge, there are so many that the exact number differs from one report to the next. Counting that high can be tricky, but everyone agrees that it was at least 200 and perhaps as many as 206. Now, you know, we've all become a little patch drunk, right? There was a time when 30 or 40 vulnerabilities would have raised eyebrows. Whoa, 40 vulnerabilities. Now that's seen as a quiet month. But stay, you know, it's like 200. So consider, just stand back and consider something north of 200 security bugs found and fixed. On the one hand it's great that Windows and its surrounding software will have at least 200 fewer discoverable security vulnerabilities. But on the other hand, Windows software had 200 or more security vulnerabilities to be fixed and no one imagines that next month will will be much better. I don't think they got them all. So you know, buckle up for July and it's not as if these were insignificant problems, you know, that could have just been ignored. Oh no. Among those 200 were 60 days, five of which had previously been publicly disclosed, most by you know who, and one which was under active exploitation in attacks. And among these 200 now blessedly resolved, Microsoft Windows and Windows adjacent bugs. Get this, 33 of those ranked as critical with all but five of those. So 28 of them being remote code execution. 28 critical remote code execution flaws. Of the remaining five, four of those were privilege elevation and the last one was an information disclosure. But 23 RCEs found and fixed in one month. It's nice to see Microsoft moving quickly to employ their code Name M-AI to the I hope that doesn't stick to the task of finding and fixing the many flaws we have come to understand Microsoft code contains. Right? I mean they're moving quickly with a purpose here because they are fully aware that increasingly capable AI models are also in the hands of malicious actors who are beginning to actively employ those models for the discovery and exploitation of Microsoft's many code shortcomings. So as I noted at the top of this, it could not be more true that a true race is on. This is really a race I continue to hold, however, that bugs are not inherently endless. Once removed, bugs almost always stay gone. There are some regressions from time to time, but mostly they stay gone. And if similar AI is employed eventually, hopefully already now to pre screen new code before it's released, the past's continuing supply of freshly created new bugs should finally also be cut off. This means that the consequences of this newly AI enabled race, which is motivating both sides more than anything ever has, is that we're all going to be receiving far better software from Microsoft than we ever have. Basically it's sort of like I remember noting this about Cisco, thinking okay Cisco, you've, you've been unable to, to like get your software right. Maybe we need to make it easier for you. AI will make it Easier for you. Similarly with Microsoft, AI is going to make it easier for Microsoft to have way fewer bugs than ever before. Okay, so what's the overall breakdown of these 200 some vulnerabilities last Tuesday's more worthwhile than ever round of updates fixed 65 elevation of privilege vulnerabilities, which we know those are just as just as important. They don't sound as scary as remote code execution where the bad guys provide the code they'd like to run in your computer. But many times bad guys get in on a user account so they need to elevate their privilege to get to really, you know, sink their teeth into the system. So 65 elevation or privilege vulnerabilities 55 remote code execution vulnerabilities 5530 information disclosure vulnerabilities, 27 spoofing vulnerabilities, 19 security feature bypass vulnerabilities, and seven denial of service vulnerabilities. You know, where you crash something. One of those we know one of those doss we will talk about in a second because that was the HTTP 2 bomb that we covered. And just for the record, even all of that 206. 200 to 206 depending upon who you ask. They did not include flaws repaired previously in Mariner, Azure Horizon DB, Microsoft Copilot, Copilot Chat, M35, M365 Copilot, Microsoft Exchange Online, and Microsoft Graph. They were all previously repaired and they all had a bunch. In other words, things really are quite furious up there in Redmond, Washington at the moment and that's great for everyone. So what do we know about the various zero days that were fixed? There were six of them, thanks to the tireless efforts of the renegade hacker Nightmare Eclipse. Another of their zero days known as Green Plasma, was fixed that was assigned the CVE this year of 45586, an elevation or privilege flaw that the disgruntled hacker discovered in Windows collaborative translation framework ctfmon. I don't know what that is, but I've all I've often seen ctfmon in my process list, so it's busy being something it had been publicly disclosed and enabled an unprivileged user account to upgrade itself to full system privileges. So again, Nightmare Eclipse was another nightmare for Microsoft publicly releasing a zero as a zero day, a means of using the CTF mon to elevate an account privilege from user to system. Microsoft was also able on June and I was impressed by the speed of this because this only just happened earlier in June to quickly repair that HTTP 2 bomb which we just talked about denial of service vulnerability, which was, you know, the deliberate headline grabbing, irresponsible disclosure of which annoyed me so much, which we talked about last week where the guys at California said hey guess what? We don't believe in responsible disclosure anymore because of AI. So here it is. Okay, the Microsoft variant was assigned a CVE of 49160 and was found in the HTTP sys module, which makes sense, that's the web the web server module or driver as Microsoft phrased it. Quote Uncontrolled resource consumption in HTTP 2 allows an unauthorized attacker to deny service over a network which of course is micro speak for anyone's laptop can bring down our web servers. What we already know from Caliph's disclosure is that the A the HTTP 2 bomb is a denial of service technique that abuses how the protocol itself compresses and manages web traffic headers which allow attackers to send very small amounts of data and force servers to allocate disproportionately large amounts of their memory. Then by combining two techniques, basically not bugs but just protocol features, the researchers at Calif. Discovered that they could dramatically increase server process memory consumption. Then keep the memory tied up by manipulating HTTP's flow control settings to prevent the server from freeing the resources. Basically don't allow the the the inbound query to ever end. So the server just waits and it waits with 32 gig of memory tied up and the and the laptop keeps doing those until all the server's memory is gone and it crashes. So since this clever attack is more of an abuse of deliberate HTTP 2 protocol features rather than a bug that could be fixed, Microsoft also added a new Max Headers count registry setting to limit the number of headers in a single request. If it's not specified that the default maximum header count is 200, it could be set as low as 50 or as high as 65535. So you know of all 16 bits turned on in the count. Tuesday's Updates also resolved two problems with BitLocker nightmare eclipses so called yellow key vulnerability Remember we talked about this that that was the quacky boot thing that's been addressed as CVE 45585. That was the hack that involved rebooting a machine while supplying a script on a thumb drive that had the effect of deleting some files and leaving the system in a pre booted state with its primary drive decryption key still loaded and the normally encrypted drive, the main system drive fully decrypted and accessible. As Microsoft phrased it, a successful attacker could bypass the BitLocker Drive encryption feature on the system storage device. An attacker with physical access to the target could exploit this vulnerability to gain access to encrypted data, unquote Quote so after last Tuesday's updates, this can no longer be accomplished. Microsoft is now careful to not leave the BitLocker encrypted drive in an unencrypted state. So what about the second BitLocker repair? Let's hope that the way they stumbled on this one was human derived and not AI, since it sure feels like the old Microsoft as you'll see in a minute, rather than the new and improved Microsoft we're hoping AI might be enabling. The second flaw was named Blitzkrieg. I'm sorry, bitskrieg cleverly oh he yeah, yes, by the guy who discovered it. He originally posted the news over of his discovery over on X under the name John Jonas L. Since the view from a hacker's perspective is always interesting and often entertaining, I'm going to share Jonas's originally Jonas's original posting, which was near the start of the month on June 4th. And again, as I said, I was impressed that Microsoft moved this quickly. Hadn't occurred to me before, but I wonder if AI might be accelerating the pace from just from them having knowledge of the problem and it being fixed. Or maybe the confidence, because after all that was five days from June 4 to June 9, so that's very quick. So Jonas L wrote it is rare that anything new happens in the world of IT security. It's mostly just an endless cycle of variants of the same vulnerabilities being exploited over and over again. That's why I appreciate when something new happens. And the yellow key exploit was for once an attack I had never seen before. I've done I he said. I've myself done a BitLocker bypass before. Then he surprises. He supplies us with a link with an with that which has a an embedded January 15, 2021 date. So about five years, a little more than five years ago, he said. But this one was new to me, meaning yellow key. It expanded the attack surface onto an area I had not looked into before, the recovery environment. The recovery environment is stored on a partition that BitLocker does not encrypt, and the TPM is not locked until you use any functionality. That's not the startup repair. So if you somehow get code running without causing the TPM to lock, you have access to the encrypted drive. Microsoft killed yellow key by removing the auto execution of a newly introduced component that could be manipulated into doing file operations by rolling back a transaction stored on a USB drive. Isis, which was really clever by the way. I suspect they simply copied the recovery environment from the unreleased Windows cloud made for thin clients. That also explained why the bare metal recovery EFI image identifies as Windows 365 when downloading what to boot on its RAM drive from the Microsoft server. The yellow key he said the yellow key trans transaction rollback hack enabled a file deletion enabling launching a command prompt by holding down control when launching rec env rv XE and which which he also agrees is an elegant attack. So when my friend asked if I wanted to try to help restore the vulnerability, I figured why not give it a try, he says Microsoft fixed yellow key by just killing a specific vulnerability, but they did not resolve the underlying design issue. So I'd be surprised, he wrote, if it wasn't doable. After 24 hours, a new attack was born. I call it Bitskrieg. Okay, so his posting then walks us through his successful hack and attack which demonstrated that that there was indeed more than one way to skin this particular cat. And I'll note again, as I did before, that vulnerabilities in BitLocker access at this point, I.e. bitLocker access at this point is an inherent weakness that Microsoft really cannot do much about. Sure, they could be much less sloppy and more carefully consider the consequences of their design decisions, but if we want a system that has its bitlockered main drive encrypted at rest, which then autonomously boots into the Windows OS environment that's contained within the bitlockered drive, without requiring some information that is not stored on the local machine, you know, which is where the user provided pin comes in, then there's really no way around the fact that the machine will be vulnerable to some form of local boot, you know, like local access, boot time shenanigans, there's just no way around that. So last Tuesday's patch update resolved this additional bitskrieg attack that Jonas L discovered and as I said, I'm surprised they did it in five days. And that's good, since he had made it public also. But enterprises and security minded end users should not rely too heavily upon the security of entirely self decrypting bitlockered systems. The only way to ever be truly safe is to require some information at boot time that is not present anywhere else in the system. That means depending upon a hardware dongle or a manually entered pin. This is the classic trade off between security and convenience, and there's just no way around it. Okay, so what else do we know about Tuesday's record breaker? The history behind this next zero day is curious because it's a fix for a CVE dated an unbelievable six years ago in 2020. CVE 2017 103, which is a Windows Cloud Files Mini Filter Driver Elevation of Privilege vulnerability. Like so many other recently released zero days, this one too owes our attention to none other than Nightmare Eclipse. Its reincarnation by that now infamous hacker was given the name Mini Plasma. So yeah, Mini Plasma. So what's up with the CVE from six years ago? Nightmare Eclipse explained that the flaw was originally reported to Microsoft by Google's Project Zero and indeed I found the original bug with its full description and its attached proof of concept in a zip file. However, Nightmare Eclipse stated that the flaw was still exploitable and it was unclear whether Microsoft fully patched the issue, or whether the bug may have been reproduced or I'm sorry, reintroduced. As I said, bugs sometimes come back may have been reintroduced at some point. In any event, it appears to have been fixed once again. And this brings us to the fifth and final zero day remote code execution vulnerability. Just to be clear, this is one of the 55 remote code execution vulnerabilities that were fixed last Tuesday, though the majority while RCEs were not zero days. Remember, there were 55 of those unbelievably. But this one CVE 202642897 was one of the zero days. This last one is a spoofing vulnerability that was present in Microsoft Exchange Server. It was being actively exploited in the wild to execute JavaScript in a targeted victim's browser. Microsoft explained, Quote an attacker could exploit this issue by sending a specially crafted email to a user. If the user opens the email in Outlook Web access and certain interaction conditions are met. Arbitrary JavaScript can be executed in the user's browser context. So technically this last one was not part of the primary Patch Tuesday bundle. At the time, Microsoft explained that they were still working on its update and that they would be pushing it out through the Exchange Emergency Mitigation service, which should be enabled by default on certainly on Exchange Server and hopefully for users that are that might be affected by this. We know nothing about two about who sorry disclosed this vulnerability nor how it was exploited, but it was a zero day. Scanning down the surprisingly lengthy list of critical so remember we had 55 critical remote code vulnerabilities. We find that one was present in Active Directory Domain Services and another In Microsoft Azure Kubernetes Service, Microsoft Office and the Remote Desktop client. Get this, each had seven remote critical remote code execution vulnerabilities, Remote Desktop and Microsoft Office each had seven. One was in Nuance Power Scribe three were found and removed from Windows Hyper V. Thank goodness because I'm about to start using it. There was one in Windows Development Services. Windows DHCP client had one and that's a scary place to have a a critical RCE since although it explains why it's critical since most Windows clients will be using DHCP so their client will be vulnerable remotely by default to any server that is able to supply DHCP information. In addition to the Windows HTTP 2 bom which you know we talked about last week and previously this week, which was that denial of service problem, the HTTP sys module also had a terrifying critical remote codecs and vulnerability fixed. I assume it was terrifying since it was in HTTP sys, that's the web, that's the Windows web server module and it was rated critical and it was a remote code execution and nothing is more exposed than a web server, which is why the HTTP 2 bomb vulnerability was such a problem. Windows Kerberos also had a critical rce. Not to be left out, Windows kernel did too. And finally two RCEs were found and fixed in the Windows Win32K graphic GRFX module. So yeah, I named today's podcast Patch Tuesday a la AI because this is what the next several months or so are probably going to look like. It's going to be very interesting to see the shape of the vulnerability discovery and remediation curve. As we know the pre previous months meaning May Patch Tuesday tied for the most ever patches in any month and that was like 125 or something. As we know this month's handily this month's patch number count fixes far exceeded that one. So are we seeing an acceleration? I mean we are in in the last couple months certainly. What a month. What will next months look like? No idea but it's going to be really interesting to see. And finally lastly over on the Microsoft Edge Chromium update side I will quote from bleeping computers reporting about that just one line which wrote quote There were also a massive their word there were also a massive 360 Microsoft Edge slash Chromium flaws that were fixed by Google this month. Okay, 360 and these were found in the Chromium browser which was already the recipient of an incredible expenditure of past manpower. But now our entire software industry is replacing manpower with AI power as rapidly as it can. And it's quickly becoming clear that at least in the field of software, there's really no comparison. Man versus machine. Since the results are pretty much speaking for themselves. Machine wins.

[A]

Yeah.

[B]

And I for not, I for one, Leo, cannot wait to see what happens next. This is a real ride lately.

[A]

It's crazy. Yeah. That there are that many flaws is in Chrome and Window. Windows is huge. I understand. But Chrome. Yeah.

[B]

And it does say that Google is busy running AI over Chrome. Yeah, I know. But I'm with you. I am stunned because, I mean, it was believed to be super secure.

[A]

Yeah.

[B]

And they said, whoops.

[A]

So in some ways this. I mean, if you could find the flaws, if you're a bad guy, you could also exploit the flaws. Right. I mean, that's why people are worried about Fable and. And Mythos is finding them and fixing them is. Is tantamount to finding them and exploiting them. It's the same.

[B]

And Mythos, Mythos, we know, produces proofs of concept, so it designs the exploit. That is an exploit is a proof of concept. Right.

[A]

Okay. I don't know where this is all headed. I have no idea. I know. We're going to talk more about it tomorrow. I'm trying to get Katie Mazuris on as well because she's the only one who's seen this. Check the code. Fix the code. Quote jailbreak. And Alex Stamos will also be joining us. He has created the campaign to free Fable. We will be talking about this tomorrow on Intelligent Machines. Big time. Big time. And I'm glad, really glad you've been talking about it as well because it's just, it is. It's a. It's an interesting time for security, for

[B]

cyber security, you know, re revolutionizing cyber security utterly.

[A]

And of course, the other thing that the Fable classifier was blocking besides cyber security and, and AI development because they don't want somebody else to develop another AI with that power is by. Yeah, bio.

[B]

Right.

[A]

Stuff. And that means bio biological warfare. And it's one thing to say, well, there's 360 bugs in Chrome, but if you could design a lethal pathogen that was highly contagious, that would be devastating. We would just. I mean, look what happened with COVID and that wasn't even designed. I mean, that would be devastating. We could. So I understand there's a legitimate concern about this. And you know, I think we're going to be facing this one way or the other, whatever the government does in the next few years. Right. You can't keep a lid on this forever. Everybody's working to make these AGIs. Maybe Anthropic was right. We should probably stop you first. That's what they said. We'll stop when they stop. Steve Gibson'[e-mail] that's where you can find Spinrite, the world's best mass storage maintenance, recovery and performance enhancing utility. Version 6.1 is the most recent and it is fairly recent and it is available. And if you have mass storage, you really should have it. Go to GRC.com and get it. There are other things there. There's his Spinrace's bread and butter. But he also has a lovely little $10 program, okay, 9.99, called the DNS Benchmark Pro that makes sure that your DNS is fast. You know, a lot of people think the web is slow and then they realize it's not the web, it's the DNS server they're using is slow to catch to find the, you know, the IP address. Speeding up your DNS server speeds everything up. And DNS Benchmark Pro can help you do that. You'll find both of [e-mail] if you want to send Steve mail or a picture of the week, send it to GRC.com no, don't send it to anywhere. Go to GRC.com mail and enter your email address. Because he has to whitelist you before you send it. But he has a magic tool to do that. Right below it you'll see two checkboxes for two different newsletters. One is of course, the weekly Security now show notes. Really nice to get that a couple of days ahead of time. The other rarely used. An announcement of new products. If there is a new product, Steve will announce it. Through that one, sign up for them both. But as you would expect with Steve, neither are checked by default. So you'll have to manually do that. Steve also has copies of the show. He has unique copies, 16 kilobit for the bandwidth impaired. 64 kilobit sounds great, but it is smaller than the version we have. He also has those show notes. You can download those there. And a couple of days after the show, he'll have a transcript created by a human being. Elaine Ferris. Hi, Elaine. Who does a great job with those. Those are [e-mail] along with a lot of wonderful free stuff, including shields up, which really will help you check your router before you go online. We have on our website 128kilobit audio. Long story, that's what we got. We also have video. Long story, that's what we got. You can find both of Those@Twitt TV SN. There is a YouTube channel dedicated to Steve's show, YouTube.com SecurityNow a great way to share clips which you may want to do on any of these to, you know, let people know what you've just learned. Great way to spread the word about the show. And of course you can subscribe because it's a podcast in your favorite podcast client. We do the show right after Mac break weekly. 1:30 Pacific, 4:30 Eastern 20:30 UTC. Every Tuesday. You can watch us do it live if you're a club member, and I hope you are. Please, if you're not, join the club. 10 bucks a month for ad, free versions of the show. Lots more. The club you can watch in the club Twit, Discord, but everybody's invited to watch on YouTube, Twitch, X dot com, Facebook, LinkedIn or Kik. We stream on all those platforms so you can watch us live if you want. And we would love it if you do every Tuesday. We'll be back here next Tuesday at 1:30pm Pacific for another gripping, thrilling edition of Security. See you then, Steve.

[B]

Bye, Leo. See you then.

[A]

Hi there. Leo Laporte here. I just wanted to let you know about some of the other shows we do on this network you probably already know about. This Week on Tech. Every Sunday, I bring together some of the top journalists in the tech field to talk about the tech stories. It's a wonderful chance for you to keep up on what's going on with tech, plus be entertained by some very bright and fun moms. I hope you'll tune in every Sunday for this Week in Tech. Just go to your favorite podcast client and subscribe. This Week in tech from the TWiT network. Thank you, Security.

[B]

Now.