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

[00:00:00] 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.

[00:00:29] Podcasts you love. From people you trust. This is TWiT. This is Security Now with Steve Gibson. Episode 1083, recorded Tuesday, June 16th, 2026. Patch Tuesday à la AI. It's time for Security Now, the show where we cover the latest in security, privacy and all that stuff online with the man, the myth, the legend, not the mythos.

[00:01:01] Steve Gibson. No mythos for you. That's no fable here. No fable either. Wow. Wow. Crazy. Well, yeah, I'm going to share Anthropic 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 what

[00:01:31] boy, did we break records? Yeah. So today's podcast is titled Patch Tuesday à 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.

[00:02:00] But five, six months would be my guess. And then we're going to see 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, codename M-Dash, which they make me say every time, will be the thing that, you know, changes.

[00:02:29] I really believe changes the Windows side of the industry. Anyway, we're going to dig deep into that. I want to talk about root kits having been found in more than 400 Arch Linux user repository packages. I had to worry about that. I'm an Arch Linux user. Yeah.

[00:02:49] Yeah. U.S. government requests Anthropic, as we said, to remove both access to both Mythos and Fable for four 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'll just have to tell everybody no. CISA has also had an interesting response to AI driven attacks, changing their patching requirements for federal agencies.

[00:03:18] And boy, if patching was ever a back room or like on the back burner, this is it is just no longer the case.

[00:03:29] And any federal agency who, and this is a BOD, what I can't remember that stands for, binding operational directive from CISA, which, you know, has legal strength, which says you have to patch on the timeline we say.

[00:03:49] And it's fast. So patching, again, it's like this has moved right up to the front of, you know, operational readiness business wise. Well, we'll look at that. Also, NPM, the most attacked repository we have, you know, the Node.js packet manager has switched to more secure installs.

[00:04:19] Install defaults. 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.

[00:04:46] 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, you know, we've got great loop closure now with email communications.

[00:05:01] 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 think a lot of fun stuff to talk about. And of course, a picture of the week that actually is a kind of a coding theme or that's how I'm going to spin it anyway. Oh, well, you know, I'm always up for that.

[00:05:31] Yeah, I have a little tale to tell about AI saving my bacon yesterday, too, at some point. Oh, yeah, I was it was like a lifesaver. Speaking of Linux. Well, we won't in that case. Let's do the first sponsor that then you have to tell us because I can't wait. Yeah, yeah. I just the more I use it, the more valuable it becomes. It's that's what's really there. Yeah, I miss Fable. But, you know, this was with 4.8. It was 4.8. It did a great job.

[00:05:59] 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 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.

[00:06:26] The legacy providers with inflexible 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 the company's fault, really. I mean, the Internet has exploded and is more and more important for every business.

[00:06:55] 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.

[00:07:25] 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,

[00:07:53] major hospitals, branch offices. You know, you acquire a new company. Now you've got branch offices with a completely different system you need to communicate. Worse, maybe. They have a 200,000-square-foot warehouse that's depending on Wi-Fi. Nothing works. 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.

[00:08:21] So does the assistant director of technology for the Webb 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,

[00:08:47] 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.com slash security now to book a demo today.

[00:09:15] That's M-E-T-E-R dot com slash security now. Book a demo. You need Meter. Now, back to Steve and our picture of the week. First, tell us about AI saving your bacon. So I run my agent, everything, all of it, all the models, all the memory, everything on that nice framework desktop I bought. Really designed to do that.

[00:09:45] I bought it to do local AI, 128 gigs of RAM. It's got that AMD AI plus 395 AI specific processor. It's really nice. Yesterday, I come in. I mean, and I use it every day. That's where Claude is, where everything is. And it says emergency. Can't boot. And it gives me a prompt. And I go, oh, that's not good.

[00:10:10] Now, in the past, what I would have done is I would have reinstalled Linux on that machine. 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 just see if Claude Code can help.

[00:10:39] It said, don't erase it. Tell me what the message is. And I told her, 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 type in 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 I said, this is a lot to type in. I'm going to make mistakes. It said, oh, of course.

[00:11:09] This is Claude talking. What am I thinking? It said, look. You're human. You, you, you, you. You poor human. I need to SSH into this machine. But of course, you're running the boot thing. 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.

[00:11:37] And then I will SSH in and do it for you. I did. It did. It SSHed in. It said, it looked and looked. It 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, and this is how mission critical, if one dies, the other one has still got everything on it.

[00:12:04] And it, and it, it does have, because the Lux encryption, it has the password in the TPM. So it, cause 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 there is something to do with UEFI. There are two, two different ESP modules. And for some reason they had different Linux kernels.

[00:12:33] One had 7012, one had 7011. 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, it'll 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 fixed. We're living in a science fiction world. I wouldn't, I don't even know what ESPs are.

[00:13:03] 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 curl. I curled the key over, logged in and did it all for me. Yeah. And you tell me these things are just auto correct. Wow. No, it's very good. It's funny. I had an experience yesterday.

[00:13:34] I'm, I'm configuring the house's security and environmental monitoring and management stuff. Oh, it's really good at that actually. 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 am I doing? Why am I, why am I using Dumbo? So, uh.

[00:14:02] Sonnet's pretty good, but not for the hardcore stuff. Yeah. 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. It said, uh. 4.8 is very apologetic. 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. That was Sonnet. Don't, don't take the blame.

[00:14:33] That's one thing that's 4.8 is notable for. It does apologize a lot. I don't, but when it makes, but, but. This one, it 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 was flawless. It was amazing. Oh, and in fact, I had to say now, now that I was on 4.8, every answer was correct.

[00:14:57] 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 then it came back and it's like, okay, you know, I, I, I verified that this is the case. It's like, I'm just sitting here thinking, wow. I have an assistant. Some people listening are thinking, oh, these Leo and Steve lost their marbles. They've drunk. Where's the Kool-Aid?

[00:15:21] But, but until you've actually had this experience, it's easy to poo-poo it. Once you've had the experience, it's like, wow. And I, and as I said to our listeners a couple of 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.

[00:15:51] The idea is, you know, if you're trying to do something, then, and also old habits die hard. I mean, the, 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. It's kind of amazing. Well, and the thing is it speaks computer really well. It's very good at speaking computer. It's funny too, because that's significant.

[00:16:20] I remember when Google searches only turned up the results I wanted because only computer geeks were on the internet. And so the internet was very computer-centric. Now you've 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. Anyway, that's, that's my tale. I was just blown away. It was just really surprising. Yeah.

[00:16:49] So, okay. Thank you. Thank you, Claude, for fixing my computer. So it's now it's picture of the week time. So I gave this one, the caption, a loop with the branch test at the end. Okay. I'm ready to look at it. I haven't seen it. A loop with the branch test at the end. Okay. I like it.

[00:17:15] This is a, now Steve's turned this into a coder joke, but it isn't really a coder joke or is it? Correct. So the sign says, so this is some signage somewhere like at a service window or something. And it says back in 15 minutes. And then on the next line, it says minutes. If not read sign again. So. Go to 10. So exactly.

[00:17:42] So 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, like, for example, while something, then do the following. Right.

[00:18:03] Or you can say, when you're finished doing something, you can perform a test and maybe do it again. So. So. And it turns out these are like subtly different constructs in computer science.

[00:18:21] It's one of the things like programmers who are just starting out learn is that there are cases where you never want to execute some code in that could be executed multiple times in a. And which is why we call it a loop, because you loop back, in which case you would test for that that decision at the beginning of the loop before you've even done it once.

[00:18:46] There are other times where you always want to do it once and then you want to see, well, 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, yeah, that's very funny. I love it. Yep. Okay.

[00:19:12] 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 InfoSteeler targets credentials and access tokens.

[00:19:39] 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 InfoSteeler. But we haven't like like what info is stolen. So we're going to answer that. Last Tuesday, the site, which is a great domain, IOCTL, which is the abbreviation for IO control. You know, input output control.

[00:20:07] IOCTL dot fail is the is the site. What a good name. Yeah. What a good name. And I didn't know you. There's like a dot fail top level domain. I didn't either. It's just amazing. That one. Yeah. Happened. Yeah. Yeah. It they posted their analysis of this infiltration campaign, opening their report by explaining.

[00:20:27] This report summarizes static reverse engineering of the Linux ELF, you know, ELF malware sample named Deps. D E P S is the name of the malware and static review of the recovered NPM package source associated with the incident. The sample and package were treated as malicious throughout handling.

[00:20:53] 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.

[00:21:17] OK, 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 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.

[00:21:46] It's abbreviation for executable and linkable format. That's 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 RTOSs. 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 its format.

[00:22:16] 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.

[00:22:41] And since this malicious binary had been stripped of any latent symbolic names, it was just pure, you know, binary code that did the work. You know, variable names or function names were not there. The analyst assigned the names as they worked through the decompilation of this once a function's purpose had become clear. So they go on to explain.

[00:23:10] 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 a malicious NPM package.

[00:23:31] 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 depths is where it was in the file system.

[00:23:58] 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.

[00:24:22] This means, they wrote, a developer workstation, a maintainer's machine, or CI slash 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.

[00:24:47] E-BPF, 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.

[00:25:10] You need to be down in the kernel in order 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.

[00:25:30] 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. Yikes. In other words, no developer wants this thing anywhere near their machine.

[00:25:56] They said the recovered supply chain package identifies itself as atomic lot file version 1.4.2. It contains a malicious NPM lifecycle entry pre-install at source hook steps. That lifecycle script executes the ELF directly during NPM installation when lifecycle scripts are enabled. The ELF in the package source is byte-identical to the analyzed sample.

[00:26:25] So that was a little bit of repetition, and they're just saying what they analyzed was byte-identical. They said the attacker-controlled 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.

[00:26:53] It's just a long string of gobbledygook, like all the onion addresses are, ending in .onion for the domain name. The command result callback is a post at slash API slash agent sent through a local loopback sock-style transport. The local 127.001 traffic is an intermediate transport layer, not the attacker endpoint.

[00:27:23] When BPF is available, the malware can hide local process and socket artifacts used by the transport. 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. It just disappears.

[00:27:51] So that anyone looking at the machine, looking at, you know, NETS, the equivalent of NETS stat, looking at who's, what processes are listening for connections on ports, what communications are occurring on the fly, you know, 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.

[00:28:20] 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 recovered package source,

[00:28:44] 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, you know, big JavaScript, you know, TypeScript.

[00:29:07] And they just sort of tacked in this ELF binary and then used the NPM pre-install functionality 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,

[00:29:33] and no package layer references to, you know, temp.sh, API agent, Discord webhooks, or a public C2 domain IP. In other words, 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.

[00:30:00] The C2 endpoint is included 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.

[00:30:28] So we learn further why no developer wants to have this anywhere near the system. So it installs persistence using root or per-user systemd service units, enforces a single active instance using Flock, so to keep like multiple instances from running at once,

[00:30:54] redirects standard input-output error to dev null, so that you won't see it doing anything, any of its output, ignores SIG pipe, 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,

[00:31:22] enumerates Chromium family browser profiles and electron app data, reads SQLite cookie databases and level DB local storage, extracts Chromium and electron cookies and service tokens, queries Slack, Microsoft Teams, Discord, GitHub, NPM, and OpenAI chat APIs with stolen tokens or cookies,

[00:31:50] searches local file system locations for SSH keys, your shell history, vault tokens, Docker slash 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,

[00:32:17] uses a local loopback SOC 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 it goes completely stealth once it gets into your system,

[00:32:46] 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 info stealer malware from time to time. It is, unfortunately, an increasingly prevalent form of malware

[00:33:14] because its goal is obtaining information that would allow an attacker to pivot to some other target. They don't really care about a developer's machine, you know, 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.

[00:33:42] So the bad guys are 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 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.

[00:34:11] 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,

[00:34:39] and they enumerate them. 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,

[00:35:06] Yandex Browser, Epic Privacy Browser, Iridium, Ungoogled Chrome, Thorium, Komodo Dragon, SRW Wear Iron, Sent Browser, Slim Jet, Maxthon, UC Browser, Coco, Naver Whale, Chromium Flatpak, Google Chrome Flatpak, Microsoft Edge Flatpak, Brave Flatpak, Vivaldi Flatpak, Opera Flatpak, and Yandex Browser Flatpak. I never heard half of those.

[00:35:36] I know, but they exist, and so these developers took the time to put in some specific code for each and every one of those, because if the developer has it, they want to get into it. Profile artifacts targeted include local storage, level DB, the network and cookies, network slash cookies, default slash cookies,

[00:36:05] and Chromium encrypted cookie values. Collaboration and electron applications, which it knows about and goes after, Slack, Slat Flatpak, Slack Snap, Microsoft Teams, Microsoft Teams Legacy Stores, Microsoft Teams Flatpak slash browser-derived stores, Discord, Discord PTB, Discord Canary, Discord Flatpak variants, Discord Snap variants,

[00:36:34] Vesk Top, Leg Cord, Web Cord, Arm Cord, Ven Cord, Native Cord, Abaddon, Descent, Rip Cord, and Dat Cord. They also confirmed the Slack paths and data. Rip Cord and Dat Cord? That's right. They also confirmed the Slack paths and data where this thing looks at it, dot config slash Slack,

[00:37:04] dot var slash app slash com dot Slack, Slack slash config slash Slack, snap slash Slack slash current slash dot config slash Slack, Slack cookies for asterisk dot Slack dot com, Slack API enrichment, thorough slash API off dot test, API users dot info,

[00:37:33] and API conversations dot list. And we're about halfway through. Confirm Microsoft Teams and Microsoft service artifacts include dot config slash Microsoft slash Microsoft slash Teams, auth service dot Teams slash Microsoft dot com, Teams dot Microsoft dot com, Skype token, region GTM, cash dot token, authorization, bearer, X Skype token, Teams account,

[00:38:03] tenant, and team metadata. They've confirmed Discord artifacts, which it digs around through, including Discord tokens from Electron, Electron slash browser storage, API V9 users at me, API V9 users at me slash guilds, MFA state, premium nitro type flags, guild ownership permissions, and member count metadata, developer accounts, and package ecosystems,

[00:38:33] including GitHub, NPM, and open API, JAT TPT, account metadata. Confirmed GitHub strings and endpoints include API dot github dot com, um, where they get, uh, a, a bearer token user agent. Uh, they look for, uh, credentials, account and repository metadata, such as login company, public repository count followers, and repository stars, NPM strings, and endpoints,

[00:39:02] including dot registry dot NPM JS dot org. They get the public, uh, the package publishing identity and maintainer package metadata. The open API chat, GPT path queries, API dot open API.com with stolen bearer material for account metadata. Um, this is, so it's a credential validation enrichment against a third party service.

[00:39:27] 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, pod man command history and registry credential material, SSH keys and SSH configuration, putty private key material, VPN profiles, and dot O VPN.

[00:39:55] And that's open VPN files, shell histories for bash ZSH and F and F I S H, uh, command history containing S FTP, S H key, Jen, S H copy ID, S H add our sync,, uh, putty, plink, Docker, Docker compost, and pod man commands. And yes, I know that was a lot.

[00:40:25] I've made a song. Uh, out of it. Oh God. Would you like to hear the, uh, Oh, we have to have it. Microsoft Teams, Microsoft Teams, legacy stores, Microsoft Teams, Flatpak, browser, derive stores, discord, discord, PTB, discord, canary, discord, flat pack, variants. It's a long song. You don't want to, it's really pretty good. There is a little more.

[00:40:54] Discord snap variants, Vesk top, leg cord, web cord, arm cord, ven cord, native cord, abbot on descent, rip cord, and dat cord, slack path, config, slack, slack, slack, slack, slack, I'm sorry. I'm sorry. Go ahead. 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.

[00:41:24] It could possibly have happened. 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, were expressly designed to root out any and all instances. Sorry. Any and all instances of any of that developer data.

[00:41:53] And send it back to its command and control server. So the real takeaway here is this info stealer stuff. This is what an info stealer 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.

[00:42:20] It's going to 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. Yeah.

[00:42:48] But you know, Leo, what's real and good? Oh, our ads. I have a feeling we have a sponsor. There might be, I don't know, a sponsor in your future. It could be. 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 Thinkst Canary. Let me just go back to the picture so I can put my face in it. There we go.

[00:43:19] 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? There is 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.

[00:43:50] 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 there are 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 honeypot. And that's exactly what the Thinkst Canary is. It's a honeypot.

[00:44:16] 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 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.

[00:44:46] 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 payrollinformation.xls. Right? It looks just like an Excel file. And a bad guy looks at it and goes, I need that. Whatever payroll information. The minute they access it or try to download it, boom.

[00:45:11] 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, 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. I might change it every day. I could change it every 10 minutes. It's very quick.

[00:45:41] 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. 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.

[00:46:10] For $7,500 a year, you get five Thinks 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 Thinks Canaries. 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.

[00:46:41] In all those 10 years that we've been partnering with Thinks 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 Thinks Canaries. You got to have them. Canary.tools.twit. And we thank them so much for supporting security now.

[00:47:11] Steve? Okay. So, last Friday afternoon, at the request of the U.S. 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.

[00:47:39] We should note that, though, that claiming national security has become the catch-all phrase used by the U.S. 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

[00:48:05] week's podcast that Claude Fable 5 first appeared. I think I mentioned it, didn't I, on the show? 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. It did. It found a lot of security flaws. It was very good. So, it looked like another major leap forward.

[00:48:31] So, as a consequence of all of that, I want to share what Anthropic posted because there's some interesting pieces 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 jail breaks because this is their pushback.

[00:48:58] And it echoes the position everyone here has heard me articulate from the start, which is that our, 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.

[00:49:25] I don't mean hostile like in a belligerent way, but I mean, it's just that 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 could turn up and down. So I believe it is inherently an uncontrollable technology that is from the standpoint of guardrails.

[00:49:51] So the headline of Friday's posting, and 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, so their statement is, the U.S. government, citing national security authorities, has issued an export control directive to suspend

[00:50:20] 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.

[00:50:46] 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 521 p.m. Eastern. The letter did not provide specific details of its national security concern.

[00:51:12] 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 I saw elsewhere, Leo, that apparently some Amazon employees or someone on Amazon 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

[00:51:42] 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. Anthropics posture with respect to Fable's safeguards, as laid out in our launch blog post, is the following. So they said, and we have some bullet points.

[00:52:13] 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.

[00:52:37] And as we saw, they sort of kick you out to the Opus family if you make the mistake of crossing one of their tripwires. They said, in fact, our safeguards are so strong that many users have complained that they are overly broad. Right. Again, because that's like the only way to do this, if you're going to try to do it,

[00:53:02] is to fail closed because it just isn't possible to control these models. And so this is an artifact of that lack of ability to control is they have to do just blanket overreaction. They said, in the weeks leading up to the launch of Fable, Anthropic worked with the U.S. government, the U.K., AISI, multiple private third-party organizations and internal teams

[00:53:32] 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 is important in a minute.

[00:53:56] 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.

[00:54:20] 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.

[00:54:48] 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 jailbreak.

[00:55:18] 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.

[00:55:42] So, like, you know, by holding on to 30 days worth of interaction, if they find something 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.

[00:56:10] 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 that's important. In other words, yes. In other words, you know, those that have not been banned by the U.S. government, because the U.S. government says, yeah, these are fine.

[00:56:40] 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 provide no mythos-specific uplift.

[00:57:09] 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.

[00:57:34] 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 they said, and is used every day by the defenders who keep systems safe. We'll share more details over the next 24 hours.

[00:58:01] 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.

[00:58:24] 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.

[00:58:52] 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. Increasingly, this looks like a political move, a business move. Pete Hegseth.

[00:59:22] Well, we know that Hegseth is pissed off at Anthropic. He tweeted, you see, you know? I mean, he clearly. So Katie Mazuris, who was a well-known security researcher, was apparently given the paper. We think it was Andy Jassy, the CEO of Amazon, who talked to the White House and said, yeah, there's a jailbreak. This is the third-party research paper. Anthropic shared it with Katie Mazuris.

[00:59:50] 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.

[01:00:15] 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, turned 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 a code because of munitions. This is crypto.

[01:00:40] 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 ammunition. Now, this is her assertion. I don't, you know, it's possible there are other jailbreaks.

[01:01:05] I had heard that Pliny the Liberator, who's a well-known jailbreaker, had another jailbreak. 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.

[01:01:20] Alex, as you know, a really well-known security researcher, has released a letter to Secretary Lutnik and National Cyber Director Cairncross 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. And it's annoying that this comes from a competitor, right?

[01:01:48] I mean, that's what really feels wrong. Well, the funny thing is Amazon has a huge investment in Anthropik. So I don't know if they're a competitor. We don't know what Andy Jassy told Lutnik. But we do know that Anthropik has been very good to the administration. The Anthropik has... And it is being used throughout the administration. And is being used, yeah.

[01:02:15] We also know that OpenAI has donated to the administration. I think it's very hard. 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 our audience would know very well.

[01:02:41] Well, I think that the strongest case that Anthropik made in their response to my mind was, this isn't that different from everything else. You know, you've singled us out. You could do the same thing. You've singled us out. And, you know, we could suggest maybe this is the flip side of the consequence of all that marketing attention,

[01:03:07] which many have called hype, that Anthropik deliberately created to a company that restricted access to Claude Mythos Preview. So, you know, I mean, they painted a target on their back. But, again, you know, I think 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.

[01:03:36] It's a wake-up call for foreign national researchers and all of the AI companies in the United States. You've 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 U.S. can block useful AI from the EU, they're going to be working on their models. It's, I think, a very big tactical error.

[01:04:03] 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 are other jailbreaks. I understand why the government might say, you know, this AI model is too dangerous to be released. But they need to be able to prove.

[01:04:25] Well, and the other thing we've seen is other people achieving mythos-grade success with non-mythos model. So, you know, and we've talked about that here. It's not as if there's some really magic pixie dust that Anthropic uniquely has. They just, you know, they're pushing ahead as is everybody else. It's a good model. Yeah. It's a good model. We will talk to Alex Stamos tomorrow on Intelligent Machines, 2 p.m. Pacific, 5 p.m. Eastern.

[01:04:55] I hope everybody will join us for that. And he will talk about this open letter, which he has put out at freefable.org. Free Fable. That's great. Free Fable. Okay. As we saw last week, the change to the historical attack pattern that was already accelerating prior to the rise of AI.

[01:05:19] You know, I mean, we before this all happened, we were noticing, wow, like this is an accelerating problem. I made the comment, you know, a couple of years ago about that. We used to have quaint it was. 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. So. So.

[01:05:44] Will access to significantly more advanced autonomous AI attacking capabilities by a much wider range of attacker. Change this further. And, you know, it absolutely clearly seems that we are seeing an AI driven acceleration.

[01:06:08] And it will for the first time, unfortunately, aided by AI include those who are far less knowledgeable and skilled. So, you know, it broadens the the the base of of attackers because they don't have to be experts any longer.

[01:06:29] Just as we've seen many of this podcast, 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.

[01:06:52] Last week's report from Anthropics 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.

[01:07:18] 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 26-04 titled Prioritizing Security Updates Based on Risk. This BOD formalizes me.

[01:07:45] 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.

[01:08:10] 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 eight, 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.

[01:08:40] 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. This is worse than the FIFA chart here. This is holy cow. The four branching decisions are, has the vulnerability been publicly released?

[01:09:04] Is the vulnerability in KEV, you know, the known exploited vulnerabilities list? Is the exploitation of the vulnerability 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.

[01:09:34] That is to say, you have three days to patch this guys or 14 days to patch or 60 days to patch or patch on system upgrade, meaning don't worry about it. You know, when you upgrade everything else, you know, you'll you'll get patches.

[01:09:53] So it's essentially patch it immediately like now with a deadline in three days or you got two weeks to patch this or you got two months to patch this or don't worry about it that much.

[01:10:08] So, for example, writing along the worst case branches of the tree for each decision point, a known vulnerability, 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.

[01:10:35] You know, I might 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.

[01:11:05] 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.

[01:11:33] 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.

[01:11:54] 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 clear and present threat from AI to push the change, which nobody wanted.

[01:12:20] I mean, this is going to upset a lot of agencies who have said, oh, we have no ability to actually do that. Well, they're going to have to figure it out and generate that ability. I think that's a good thing, though, right? It is a good thing. Yes, I 100% agree, Leo. I think that it's not anything anyone wanted, but patch. You got a patch. By the way, I hope this is okay with you for the album mark for the show.

[01:12:50] The Free Fable March. I know. I know. That really looks like you. Some of these things, and that really looks like me, actually. Actually, it looks like if you didn't know better, you'd think we were, in fact, leading a march to Free Fable. Yeah, and I think these photos must have come from the show because, I mean, it doesn't look AI. Darren is very good. Darren is our most adept AI user, I think, at this point. He's quite good.

[01:13:19] 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. And 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.

[01:13:46] But the uncomfortable truth is that when you promote your business, it's also opening you to attacks from bad guys. Ninety percent 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.

[01:14:16] 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.

[01:14:40] That's why attacks using verified personal information are, get this, likely to succeed five times more likely to succeed. And the average incident, 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, Delete Me, comes in. Reducing exposure by up to 95%.

[01:15:09] We use Delete Me, and we have to. Delete Me removes the boss, my, our employees' personal information from hundreds of data brokered websites. Starving hackers are the fuel they use to build their target lists. And it's not just a one-time thing. It can't be. Delete Me 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.

[01:15:39] 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. It's what we use. We recommend it. Protect your business. Protect your peace of mind.

[01:16:09] Here's what you do. You visit joindeliteme.com slash twit dash 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? Joindeliteme.com slash twit dash biz is a new campaign we're doing. We want you to use that address so that they know you heard it here.

[01:16:34] And I highly recommend you get this for your business, for your managers especially. We did, and it's very important. Joindeliteme.com slash twit dash 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.

[01:17:02] So the news is that the much-attacked NPM, the Node.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.

[01:17:28] The change hopes to counter the massive rise that we've been seeing, 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?

[01:17:57] 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 opensourcemalware.com to get a reality check. The posting was titled, NPM Disables Install Scripts by Default.

[01:18:25] 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 12, will come with several security improvements, including disabling install scripts. Is this a game changer or security theater? Its author wrote,

[01:18:49] On June 9th, 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.

[01:19:17] 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 DEF CON 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.

[01:19:46] 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,

[01:20:15] 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 approve scripts.

[01:20:41] Discover what's affected with NPM approve 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, a code execution hole,

[01:21:05] where a Git dependency's own .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.

[01:21:31] These three changes, he writes, ship around July 2026, and you can prepare today in NPM 11.16.0 and subsequent. At the same time, other security improvements are taking hold. Cool downs are also now everywhere.

[01:21:54] 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. The logic here, isn't that nice? Yes. I turn that on. Well, I do it manually, but for 14 days. If it's not more than 14 days old, I don't want to install it. That's smart. Yes.

[01:22:23] 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. P-NPM shipped minimum release age in 10.16 in December 25.

[01:22:52] 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.

[01:23:17] Developers are finally installing something on their machines that address malicious package threats. Datadog released an open source supply chain firewall in 2024. And Leran Tall released his tool NPQ back in 2017.

[01:23:39] 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.

[01:24:07] 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.

[01:24:36] 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.

[01:25:06] 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.

[01:25:34] The thing that announcement glosses over is that disabling install scripts is going to break a lot of stuff. An enormous amount 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 it's incredible.

[01:26:01] He said this, of course, explains why there's such a strong attack vector. There's a simplistic narrative going around that lifecycle 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.

[01:26:30] Some examples of popular packages that use lifecycle scripts are ESBuild with 200 million weekly downloads. Sharp at 60 million per week. Core-JS at 40 million per week. Puppeteer 10 million weekly. NX 9 million. Bufferutil at 6 million. UTF-8 validate at 8 million weekly downloads.

[01:27:00] 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.

[01:27:29] This is not an edge case. It's a meaningful slice of the most dependent on packages in the registry. The day version 12 lands, those packages stop working until someone approves them. So, I'm going to interrupt here for a second.

[01:27:52] 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 fire it up, and all this stuff happens. Packages are grabbed from here and there. Compilations are run and linked together.

[01:28:22] 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.

[01:28:52] 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?

[01:29:10] 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 5 p.m.

[01:29:38] 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.

[01:30:06] 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.

[01:30:30] If you really want to know if disabling install scripts will have the intended effect, You can look over to the VS Code ecosystem. With VS Code before version 1.109, The global allow automatic tasks setting was on by default.

[01:30:52] This meant that malicious task files would automatically run if victims opened 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.

[01:31:20] 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

[01:31:50] 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.

[01:32:21] 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.

[01:32:49] 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 DEF CON.

[01:33:12] 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,

[01:33:42] NPM gets to report that registry resident malware is down. Yay! 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.

[01:34:05] 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 cool-down periods and the disabling of install scripts,

[01:34:35] 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,

[01:35:03] 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.

[01:35:33] 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.

[01:35:59] 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, 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.

[01:36:29] Until it is. What 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.

[01:36:57] The reason 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 underinvesting in its own scanning.

[01:37:25] 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 has been this chronically under-resourced on internal security doesn't get to flip three defaults and call the supply chain problem handled.

[01:37:53] 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.

[01:38:17] 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...

[01:38:44] There's my minimum release age, 14 for NPM. And also do it on BUN. 14 days. Good. BUN you have to do seconds, I think. Right. 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 how to do that. Yeah, because that's the one that's really scaring me right now. Yeah. So I thought this was a really a terrific piece of from the field feedback.

[01:39:13] 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 in a time of need.

[01:39:38] 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.

[01:40:04] So the scope of the task for an open source free for all repository should not be underestimated. 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.

[01:40:34] I think 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. Yeah. Yeah. And you know, Leo, it's time for me to tape a sip of my juice and for us to find out who's paying for this.

[01:41:04] This is a low caffeine day for Mr. Gibson. What is in your juice? Is it a green juice? Is it a... No, it's just, it's a third of regular orange juice, organic, of course, because Lori, and then two thirds water. So... That sounds good. Yeah. It's just diluted. It would be water, except water, eh, it's a little boring. So we just, you know, just make a little more interesting. Exactly. Okay.

[01:41:29] Our show today, while Steve drinks his tang, is brought to you by Zscaler, 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

[01:41:57] 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

[01:42:27] 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 Pallett 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. With Zscaler, as long as you've got internet, you're good to go.

[01:42:57] 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. Thank you, Chad.

[01:43:20] 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 more at Zscaler.com slash security. That's Zscaler.com slash security.

[01:43:47] We thank him so much for supporting Steve and security now. Back to you, Steve. Okay. Feedback time. Roger Vogtlin. V-O-E-G-T-L-E-N. Best I can do. I think the G is silent. I think it's Vogtlin. Vogtlin. Robert Vogtlin. Yeah. Hey, Robert. So get this, Leo.

[01:44:11] He says, dear Mr. Gibson, I started listening to security now when I was in the fourth grade. Oh, geez. Okay, Robert. I'm now 22 years old and have a degree in cybersecurity from Augusta University. Right on. Security now has always been there for as long as I can remember. As I've begun my job search, I've realized just how vast cybersecurity really is.

[01:44:41] 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 discover 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?

[01:45:10] Thank you and Leo for everything you've done through security now over the years. Sincerely, Robert Vogtlin, Spinrite owner. So first of all, Robert. Yeah. Wow. Wow. My question to you would be, what could have possibly motivated you as a fourth grader to tune into this podcast? I'm trying to find out about zero days, Mr. Gibson.

[01:45:39] You know, and it is the case that Leo and I have been here throughout your entire life. Wow. So anyway, I know that we both feel very glad and fortunate that we've been able to be here the whole time. So to your question, I have no idea.

[01:45:58] 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.

[01:46:18] Since my background, since about age five, 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.

[01:46:42] 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.

[01:47:09] 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.

[01:47:38] Leo, any thoughts? 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, 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. Even if it's not cybersecurity, 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.

[01:48:08] All you can do is try as many things as possible. Expose yourself. And I hope you found one. See what sticks. Yeah. And just listen to your heart. You'll know when it sticks. You'll know, right? Steve had no choice. He knew exactly what he wanted to do. He just, you know, and it's just like, it clicks. And you're going to 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. Oh, to be able to spend your life doing what you love. Yeah.

[01:48:33] I mean, I, I, I, I'd 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. Right. And I hope Todd Whitaker. You'll find that. Yeah. Yeah. Yeah. Exactly.

[01:48:56] Todd Whitaker, whose last name I can pronounce, uh, is a college professor listener of ours who uses PHP to teach security. Oh boy. Yeah. He wrote, hi, Steve. Your recent discussion of insecure PHP in episode 10 82 last week rang very true to me, but you know what? PHP is really quite useful in cyber security. PHP is really quite useful in cyber security.

[01:49:25] Just maybe not the way it's 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.

[01:49:53] It was because PHP is almost perfectly suited to showing students how insecure software gets built. SQL injection. SQL injection. Concatinate 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.

[01:50:21] 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.

[01:50:48] 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.

[01:51:03] 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.

[01:51:23] And if they leave the courses better equipped to be skeptical of PHP-based platforms in environments where security matters, so much the better. Awesome. Todd. 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 Kilgo said, hi, Steve.

[01:51:53] 20-year PHP veteran here. I thought you'd find this interesting. The foundation that governs PHP has added a grant-funded position to improve PHP's security posture given the realities of AI-powered development. Quote, the PHP Foundation grant will fund,

[01:52:18] 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.

[01:52:39] This person will act as a trusted intermediary between security researchers and maintainers 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.

[01:53:07] 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 disk. Love the show. Your perspective is appreciated. Derek. So, I think overall, the PHP project's move is great.

[01:53:33] 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.

[01:53:58] My problem with it, which has been informed through our two decades of covering its use, is that those who often gravitate 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.

[01:54:26] This next bit of listener feedback sets up a perfect example. Steve Myers wrote, and 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.

[01:54:49] You were using some obscure WordPress plugin with a whopping, and he's being, and he's not being serious here, sarcastic, with a whopping 4,000 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.

[01:55:14] 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 is Lisp as the originator of the eval function. Yeah, it's great. Yes, yes. Yes, yes. Scheme, cloture, and MATLAB.

[01:55:39] Anyway, he finishes, 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.

[01:56:08] And it's certainly true that similar 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.

[01:56:36] 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 eval.

[01:56:47] 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.

[01:57:15] 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. Yeah, which is worse than Lisp. Which is, yeah. Okay, Leo, our last break, then we're going to look at Patch Tuesday a la AI.

[01:57:44] Ah, Lisp. I seem to remember programming in that language once back in the day before I started coding in English, which also has an eval function. Incredible. And the code that AI is producing for you is C, largely? No, I let it choose its language. It's pretty evenly split. But Go is my current favorite because it's concurrent. But Rust is great because it's so safe. Safe, yes.

[01:58:13] And so it's a little provable, you know, you can, a little easier to prove that Rust's code is safe. And then TypeScript is often chosen for similar reasons. Right. So almost all my code is either Rust, Go or TypeScript. And the web has tons of examples for the AI to train on. Which is why I don't use Common Lisp because it's a little less prevalent. Not so common. Not so common.

[01:58:36] 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, I would say, a good choice. Python. Oh, I've left out Python. A lot of stuff's in Python. Just all those one-offs. Like that one-off web server for the curling of the SSH key.

[01:59:05] That it just threw together for you. It's so easy to do in Python. Because they all don't libraries. It makes it very simple. Right. Right. Our show today, my friends, brought to you by Adaptive, the first security awareness platform built to stop AI-powered social engineering. And here's the shift. Attackers don't need malware anymore. They need trust. Right? Because your employees will do all the work for them.

[01:59:33] So they do it with a cloned voice, a convincing deep fake on Zoom, or an AI-written phish 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, phishing, AI-generated phishing, including scenarios that can mirror your own brand and executives.

[02:00:02] 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.

[02:00:30] Adaptive could 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.

[02:00:56] 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's security and compliance are non-negotiable. Plaid's head of security, GRC, says, quote, Adaptive has equipped our teams with cutting-edge

[02:01:23] tools and built a smarter, more resilient security culture across the company. Adaptive, trusted by Fortune 500s, backed by NVIDIA and OpenAI. Adaptive is building the defenses we need for the AI era. Learn more at AdaptiveSecurity.com. That's AdaptiveSecurity.com. Boy, time couldn't be better for this. AdaptiveSecurity.com. You need it. Now, back to Steve.

[02:01:53] 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

[02:02:18] 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.

[02:02:41] 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.

[02:03:07] 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,

[02:03:27] if they weren't separated, June's Hall alone would land somewhere in the neighborhood of 566 security vulnerabilities. 566! Okay, so let's... Wow. Yikes. Let's first take the non-Edge Windows and Windows-adjacent patches.

[02:03:54] 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!

[02:04:23] Now that's seen as a quiet month. But, 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.

[02:04:50] But on the other hand, Windows software had 200 or more security vulnerabilities to be fixed. And no one imagines that next month 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.

[02:05:14] Among those 200 were six zero 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.

[02:05:37] 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.

[02:06:01] But 23 RCEs found and fixed in one month. It's nice to see Microsoft moving quickly to employ their code name M-AI. 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?

[02:06:26] 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.

[02:06:56] 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.

[02:07:15] 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.

[02:07:35] 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 been unable to get your software right. Maybe we need to make it easier for you.

[02:08:04] 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.

[02:08:29] 65, elevation of privilege vulnerabilities, which we know those are 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 really sink their teeth into the system. So 65, elevation of privilege vulnerabilities. 55, remote code execution vulnerabilities.

[02:08:59] 55! 30, information disclosure vulnerabilities. 27, spoofing vulnerabilities. 19, security feature bypass vulnerabilities. And 7, 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 HTTP2 bomb that we covered.

[02:09:22] And just for the record, even all of that, 206, 200 or 206, depending upon who you ask. They did not include flaws repaired previously in Mariner, Azure Horizon DB, Microsoft Copilot, Copilot Chat, M365 Copilot, Microsoft Exchange Online, and Microsoft Graph. They were all previously repaired, and they all had a bunch.

[02:09:51] 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.

[02:10:18] That was assigned the CVE this year of 455.86, 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 often seen CTFmon in my process list, so it's busy being something.

[02:10:42] 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, as a zero day, a means of using the CTFmon to elevate an account privilege from user to system.

[02:11:07] Microsoft was also able, and I was impressed by the speed of this, because this only just happened earlier in June, to quickly repair that HTTP2 bomb, which we just talked about, denial of service vulnerability, which was the deliberate headline grabbing irresponsible disclosure of which annoyed me so much, which we talked about last week, where the guys at Calif said,

[02:12:04] Hey, guess what? HTTP2 allows an unauthorized attacker to deny service over a network, which of course is microspeak for anyone's laptop can bring down our web servers.

[02:12:16] What we already know from Calif's disclosure is that the HTTP2 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.

[02:12:46] 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, basically don't allow the server.

[02:13:14] Basically, don't allow the inbound query to ever end. So the server just waits. And it waits with 32 gig of memory tied up. And the laptop keeps doing those until all the server's memory is gone and it crashes.

[02:13:29] So since this clever attack is more of an abuse of deliberate HTTP2 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.

[02:13:55] 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 resolve two problems with BitLocker. Nightmare Eclipse's so-called yellow key vulnerability. Remember, we talked about this. That was the wacky boot thing. That's been addressed as CVE 45585.

[02:14:22] 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.

[02:14:50] 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. So after last Tuesday's updates, this can no longer be accomplished.

[02:15:13] Microsoft is now careful to not leave the BitLocker encrypted drive in an unencrypted state. So what about the second BitLocker repair?

[02:15:26] 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, Bitzkrieg cleverly. Oh, even better. Bitzkrieg. Yes. By the guy who discovered it.

[02:15:54] He originally posted the news over of his discovery over on X under the name Jonas L. Since the view from a hacker's perspective is always interesting and often entertaining. I'm going to share 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.

[02:16:23] 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 4th to June 9th. Uh, so that's very quick. So, uh, Jonas L wrote, it is rare that anything new happens in the world of it security.

[02:16:51] It's mostly just an endless cycle of variance 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've, he said, I've myself done a BitLocker bypass before.

[02:17:16] And then he surprises, he supplies us with a link, uh, with an, with that, which has an embedded January 15th, 2021 date. So about five years, a little more than five years ago, he said, but this one was new to me, meaning, uh, yellow key. It expanded the attack surface onto an area I had not looked into before the recovery environment.

[02:17:41] 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.

[02:18:07] 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.

[02:18:27] I suspect, which was really clever, by the way, I suspect they simply copied the recovery environment from the unreleased windows cloud made for, 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.

[02:18:55] He said the yellow key trans transaction rollback hack enabled a file deletion, enabling launching a command prompt by holding down control when launching, um, uh, rec and R E C E N V dot XE. Uh, and which, which he also agrees is an elegant attack.

[02:19:18] 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.

[02:19:48] I call it bits. Okay. So it's 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 cap.

[02:20:02] And I'll note again, as I did before that vulnerabilities in BitLocker, um, access at this point, that is BitLocker access at this point is an, an inherent weakness that Microsoft really cannot do much about. Sure. Sure. They could be much less sloppy and more carefully consider the consequences of their design decisions.

[02:20:29] But if we want a system that has its BitLocker main drive encrypted at rest, which then autonomously boots into the windows OS environment.

[02:20:44] If we want a system that's contained within the BitLocker 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, like local access boot time shenanigans.

[02:21:14] There's just no way around that. So last Tuesday's patch update resolved this additional bits Krieg 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.

[02:21:43] 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 tradeoff between security and convenience, and there's just no way around it. OK, so what else do we know about Tuesday's record breaker?

[02:22:10] 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 2020 17103, which is a Windows Cloud Files mini filter driver elevation of privilege vulnerability.

[02:22:37] Like so many other recently released zero days. This one, too, owes our attention to none other than nightmare eclipse. It's 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?

[02:23:01] Nightmare eclipse explained that the flaw was originally reported to Microsoft by Google's project zero. And indeed, I found the original bug with a full description and as 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.

[02:23:29] 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.

[02:23:58] Remember, there were 55 of those unbelievably. But this one CVE 2026 for 2897 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 victims browser.

[02:24:23] 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.

[02:24:48] 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.

[02:25:15] So we know nothing about who disclosed this vulnerability, nor how it was exploited. But it was a zero day. So we've got to say, OK, scanning down the surprisingly lengthy list of critical. So remember, we had 55 critical remote code vulnerabilities.

[02:25:36] 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 PowerScribe.

[02:26:06] 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 critical RCE, although it explains why it's critical, since most Windows clients will be using DHCP.

[02:26:29] 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 bomb, which we talked about last week and previously this week, which was that denial of service problem,

[02:26:52] 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 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.

[02:27:22] Windows Kerberos also had a critical RCE. And 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, whew, 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.

[02:27:51] It's going to be very interesting to see the shape of the vulnerability, discovery, and remediation curve. As we know, the previous months, meaning May, Patch Tuesday, tied for the most ever patches in any month. And that was like 125 or something.

[02:28:13] As we know, this month's patch number count fixes far exceeded that one. So, are we seeing an acceleration? I mean, we are in the last couple of months, certainly. What will next months look like? No idea. But it's going to be really interesting to see.

[02:28:37] 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.

[02:29:07] 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,

[02:29:35] there's really no comparison, man versus machine. Since the results are pretty much speaking for themselves, machine wins. And I, for one, Leo, cannot wait to see what happens next. This is a real ride lately. It's crazy. Yeah. That there are that many flaws. Windows is in Chrome and Windows. Windows is huge, I understand. But Chrome. Yes.

[02:30:03] And it does say that Google is busy running AI over Chrome. Yeah. No, but I'm with you. I am stunned. Because, I mean, it was believed to be super secure. Yeah. And they said, uh, whoops. So, in some ways, this, I mean, if you could find the flaws, if you were a bad guy, you could also exploit the flaws, right? I mean, that's why people are worried about fable and mythos,

[02:30:30] is finding them and fixing them is tantamount to finding them and exploiting them. It's the same process. And mythos, we know, produces proofs of concept. So, it designs the exploit. That is an exploit, is a proof of concept. Right. Uh, 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,

[02:30:57] this check the code, fix the code, uh, quote, jailbreak. Uh, and Alex Stamos will also be joining us. He has created the campaign to free fable. Uh, we will be talking about this tomorrow on Intelligent Machines, uh, big time, big time. And I'm glad, I'm really glad you've been talking about it as well. Cause it's just, uh, it is, it's a, it's an interesting time for security, for cybersecurity, uh, you know, Rev revolutionizing cybersecurity utterly.

[02:31:25] And of course the other thing that the, uh, fable classifier was blocking besides cybersecurity and, and AI development, because they don't want somebody else to develop another AI with that power is by, yeah, bio 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,

[02:31:54] that would be devastating. We would just, I mean, look what happened with COVID. Uh, and that wasn't even designed. I mean, that would be devastating. We could, so I understand there's a legitimate concern about this. Um, 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, you can't keep a lid on this forever. Everybody's working to make these AGI's. Maybe, maybe Anthropic was right.

[02:32:24] We should probably stop. You first. That's what they said. We'll stop when they stop. Uh, Steve Gibson's at grc.com. 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, uh, Spinrite's his bread and butter,

[02:32:54] 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 those at grc.com.

[02:33:22] 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 slash 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.

[02:33:49] Sign up for 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.

[02:34:17] Those are all at grc.com, 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 128 kilobit audio. Long story. That's what we got. We also have video. Long story. That's what we got. You can find both those at twit.tv. There is a YouTube channel dedicated to Steve's show, youtube.com. A great way to share clips,

[02:34:47] which you may want to do on any of these to 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 and 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.

[02:35:16] But everybody's invited to watch on YouTube, Twitch, X.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.30 PM Pacific for another gripping, thrilling edition of Security Now. See you then, Steve. Bye, Leo. See you then. 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

[02:35:46] about This Week in 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 minds. 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 Now.

[02:36:21] Relax and let Fred Meyer Pickup handle your grocery shopping this week. We start with only the freshest items. Then choose your favorites. Carefully pack everything up and load it right into your trunk so you can feel confident it's what you ordered. And right now, you can save $30 on your first pickup or delivery order and get unlimited free delivery. Restrictions apply. See site for details. Fred Meyer, fresh for everyone.

[02:36:51] Yay to Bruce, the streaming king. With Quantum Fiber in the net, he's gonna binge. He wants more. He's got to have more. More bedtime to drive. More podcasts in the shower. Quantum Fiber Wi-Fi has the power. More, more, more. Fast internet speed. He's got the gigs to go big. Bring him the games. Right now. And his royal wig. More sports non-stop. His Quantum Fiber's on top. There we go. Switch today at QuantumFiber.com. Limited availability, service and speed in select locations only.

[02:37:21] You can't reason with the sun. Trust us. We've tried. This summer, it's time to put that angry ball of fire on mute. Columbia's OmniShade technology is engineered to protect you from the sun's harsh rays that can burn and damage your skin. The sun is relentless, but so is our gear. Level up your summer at Columbia.com to spend more time outside and less time slathering on aloe lotion. You're welcome. Columbia. Engineered for whatever.