Security Now 1104 transcript

Please be advised that this transcript is AI-generated and may not be word-for-word. Time codes refer to the approximate times in the ad-free version of the show.

Leo Laporte [00:00:00]:
It's time for Security Now. Yes, I'm back. Steve Gibson is here, and there's a lot to talk about. An interesting discovery Steve made that might help 6.2 version of Spinrite come a little bit faster. What is AI-pilled? And is Steve AI-pilled? Plus, 700 French refrigerators hacked. Is that a terrorist attack? Yes, as it turns out. That and a whole lot more this week on Security Now.

Steve Gibson [00:00:27]:
Podcasts you love.

TWiT.tv [00:00:29]:
From people you trust.

Leo Laporte [00:00:32]:
This is TWiT. This is Security Now with Steve Gibson, episode 1104, recorded Tuesday, November 10th, 2026. The hole in OpenSSH. It's time for Security Now. Hello everybody. Yes, it's Tuesday once again, and yes, I am back from traipsing all around the world. And thanks to Micah Sargent for filling in for me in the last 3 weeks and Steve Gibson for putting up with me being gone.

Steve Gibson [00:01:03]:
You're back, but your voice is still somewhere over the Pacific.

Leo Laporte [00:01:08]:
I got a, I got a bad cold, as one does. Last 2 cruises I got COVID. This time I just got a cold, so I figure I'm ahead now.

Steve Gibson [00:01:16]:
I would think you are. Yeah.

Leo Laporte [00:01:18]:
Uh, anyway, I missed you, and as I'm, I'm reading all the tech news, uh, on the boat, I'm thinking, man, there was a lot to talk about.

Steve Gibson [00:01:25]:
Boy, we were not short of news, and we've got a lot of stuff to talk about today. Um, There is a delicious bug which has been found. And everyone will see what I mean by delicious. First of all, I was just going to talk about this in the regular, you know, what's new in the past week. But when I got into the details of how this happened, it's like, oh, this has to be the topic for today because it is so wonderful. I know, bad. Really bad, bad, bad

Leo Laporte [00:02:02]:
bug.

Steve Gibson [00:02:02]:
But, but, oh, it tastes good.

Leo Laporte [00:02:05]:
Okay.

Steve Gibson [00:02:06]:
Anyway, uh, I'm gonna open with, uh, the fact that I have a surprising announcement regarding Spinrite. It's been— it was difficult for me. What? All of our 21,000+ listeners who subscribe to the show notes, uh, know that they didn't get their show, uh, when they normally do, like sometimes days ahead. Uh, it— I find finally got it, uh, sent midnight, at midnight last night.

Leo Laporte [00:02:35]:
Oh, wow.

Steve Gibson [00:02:36]:
Um, because I've been so distracted by something that happened, which I just have to share with everybody because it's, you know, it's amazing. Uh, also, uh, we're going to talk about what, what it means because that, you know, I'm going to start off topic. And so I'm going to stay with that a little bit longer and talk about what it means to be AI-pilled.

Leo Laporte [00:02:57]:
Oh, that's me. I'm AI-pilled for sure.

Steve Gibson [00:03:00]:
Yeah, I know. But because I've been reading Kevin Roose's book and it's so fun to get a look behind the scenes. Also, as of midnight last night, I knew about OpenAI's release of GPT-6 Cyber. But of course, Anthropic was like right there with a bump, bumping fable and mythos from 5.1 to 5.2. So we're going to talk about what that means. That is specifically what OpenAI has done with, with GPT-6, up from 5.6, I think, is where they were before they switched. We've got an interesting story of an irresponsible hacker who published more than 30 zero days affecting one company called N-able, N-able. And they're off the net because of the trouble that this guy, this, I have to say, jerk caused.

Steve Gibson [00:04:13]:
Even not only not giving them any notice because he felt like they snubbed him in the past, but then refusing to take down all of the exploits that he published on GitHub. after they said, okay, we're sorry, we hear you, could you please take those down? Anyway, uh, more details there. Of course, we've got the 700 French refrigerator hack story, uh, and what's next. Um, lots of listener feedback about, uh, the cloud— the Cloudflare tunneling solution that I shared, uh, thanks to a listener of ours last week. Where Voyager 1 is and what it's— what milestone it's approaching, uh, a little bit more on true hardware drive encryption following what we learned last week, uh, and also of course the random number 4, uh, and an actual enumeration of the amount of debris in orbit following a comment that I made about how much space junk there is and the nature of it. And then as I said, we're going to take a look at a 10-year-old Serious SSH authentication bug, which is also kind of wonderful.

Leo Laporte [00:05:27]:
So it's kind of one of the amazing things about this era of AI discoveries is that many of these are very old. They've been around forever, 10 years undiscovered, presumably. Yeah.

Steve Gibson [00:05:39]:
Yes.

Leo Laporte [00:05:39]:
That's kind of amazing.

Steve Gibson [00:05:41]:
And, you know, we are what we expected to have happening is happening. We are now in, uh, good guys and bad guys, uh, you know, leveraging the power of AI on both sides, you know, to hurt people and to help people. So, but, you know, look, uh, I'm still here, Leo. You're mostly here. Mostly. And, you know, the world hasn't ended. And I think this is kind of the way it's going to be.

Leo Laporte [00:06:11]:
We're—

Steve Gibson [00:06:12]:
and again, It's in the same way that the, the, the early well-publicized instances of ransomware did cause other companies to say, oh, uh, we're— we have backups, right? Do we have backups? Uh, so this— the, the same sort of thing. This widely covered French refrigerator meltdown, literally, uh, that's gonna, you know, cause people who have stuck their refrigerators on their own, like, you know, consumer crap on the internet just because it's there and because they can, to sort of think, oh, maybe we need to check our own security. So I, I think we're going to get through this, and I think we're going to end up with a, with a lot more security in the future. Although what I learned from GPT-6 Cyber. Well, okay. I have to— Save it.

Leo Laporte [00:07:10]:
I'm going to save it. Save it. We will get to that in a moment. How about that? What he's learned from GPT-6 Cyber. Picture of the week time.

Steve Gibson [00:07:22]:
Yes, Leo. I'm just going to let you stew on this one.

Leo Laporte [00:07:25]:
Okay.

Steve Gibson [00:07:26]:
Because it's just a wonderful example of, I'm not sure what, As I often do, I love giving one of these pictures the simple caption, but officer.

Leo Laporte [00:07:41]:
But officer. No parking all year, 3 AM to 5 AM. No parking November 1st to April 1st, 2 AM to 6 AM. 2-hour parking all year, 7 AM to 5 PM. Good luck.

Steve Gibson [00:07:53]:
So, okay, you got to know what day it is and Okay. So no parking all year from 3 AM to 5 AM.

Leo Laporte [00:08:08]:
Except during daylight standard time.

Steve Gibson [00:08:11]:
Yeah, it kind of, but it didn't shift them both. It expanded them. It starts, you, you can't park an hour earlier and an hour later for some reason, which suggests that the day is longer or that is the day shorter? I mean, it depends upon whether you're—

Leo Laporte [00:08:29]:
Maybe there's a parade there.

Steve Gibson [00:08:31]:
Every southern— and then 2-hour parking all year between 5 a.m. and 5 p.m. But what, what about after 5 p.m. and before either 2 or 3 a.m.?

Leo Laporte [00:08:45]:
Yeah.

Steve Gibson [00:08:45]:
Or, uh, but between that 1 or 2 hours after 5 a.m. or 6 a.m. until 7 a.m., and if— can you not park at all? Or can you never park more than 2 hours? All year? I, I, uh, anyway.

Leo Laporte [00:09:06]:
There wasn't enough room on the sign for the complicated rules. No.

Steve Gibson [00:09:10]:
And notice that the font had to change. They had to use like lighter point and a smaller font. We got bold here, but no, no, we had to go to thin, narrow down here. Oh, what a mess.

Leo Laporte [00:09:22]:
This smells like homeowner association rules is what this smells like. This is an HOA for sure. And there's some guy sitting looking out the window waiting for you to break this rule. Wow. Wow.

Steve Gibson [00:09:34]:
Okay, so I will get everyone's attention.

Leo Laporte [00:09:37]:
Yes, as you do.

Steve Gibson [00:09:39]:
Those actually who, uh, have a, uh, an appreciation for Spinrite. When I say the phrase Spinrite for UEFI,

Leo Laporte [00:09:53]:
Oh, we've been waiting for this.

Steve Gibson [00:09:56]:
Oh my God, Leo, I, I get so many people who are saying, well, I love it and I used to love it and I've loved it for 30 years, but I can't use it now on all my new stuff because it's all UEFI. So I normally withhold any conversation about SpinRite until we've caught up with the news and listener feedback. But in this case, so many of our listeners have such a strong interest in Spinrite, uh, that, you know, I said I would have some news at the top of the show at— in, in the rundown. So here it is. Last Thursday, just 4 days ago, 5 days ago, everything about my near-term software development plans changed when one of Spinrite's very involved and prolific development testers who uses the handle MilQ. He sent me email saying that he had SpinRite running on a UEFI-only machine without any BIOS or that, you know, the so-called CSM, the Compatibility Support Module. It was the ongoing and long-lived presence of an original BIOS or the CSM that has allowed DOS to boot and then to run SpinRite. And I might have been skeptical if this came from anybody but Mel Q, but I mean, he was really instrumental in with the quacky systems that he had and help, help helping us like get all the little edge cases resolved.

Steve Gibson [00:11:42]:
Um, but you know, as time marched forward, legacy support for the BIOS and even the CSM slowly drained out of the population of newer machines. Um, and so it— so here we are today with more and more of SpinRite's longtime users reporting that their machines, which they would like to run SpinRite on, won't boot DOS. Uh, you know, they still— they say it's still— SpinRite still works great on their older machines, but not on what they would like to run it on that is newer. Well, it turned out that SpinRite was not alone in its need to run on older machines. Um, you know, that total withdrawal and disappearance of the BIOS, and then later this CSM, you know, compatibility wrapper thing, uh, that was affecting other old-school software as well. Um, for example, it turns out People still want to— I don't know why, but Windows 98 and I think maybe XT won't boot on these newer machines. And maybe just as a curiosity, but still, that seems to be something people wanted. So about a year and a half ago, back in May of 2025, a project was started on GitHub called CSM Wrap.

Steve Gibson [00:13:08]:
And the idea of it was to create a UEFI bootable module that would use hypervisor-style technology to emulate the older BIOS-era hardware and software that the pure, most modern UEFI firmware and their chipsets had eliminated over time. So that was a year and a half ago. Since it first appeared, I've occasionally received queries from hopeful Spinrite users who encountered that project, you know, and then it's like, hey, maybe this will work for Spinrite. So they would write to ask whether this CSM wrap thing would make Spinrite possible on newer systems. Um, as a consequence, I've looked at it several times over the past year and a half. Um, and I even had, as it happened, a conversation with Claude about, about that possibility a few weeks ago. Um, and the most recent impetus for me was that my own main Intel NUC system seemed to be acting a bit oddly, and I wanted to run SpinRite on it, which is, you know, what you do. Um, And the— but the problem was always the same.

Steve Gibson [00:14:29]:
The CSMWrap project, because they were like trying to— they wanted to boot with old versions of Windows, uh, and maybe some gaming, uh, or to do like text, like, like DOS with a text screen, it only supported BIOS writing to VGA's text mode. In order to obtain the full-screen UI performance that SpinRite has, SpinRite writes directly to the original CGA, you know, the Color Graphics Adapter framebuffer memory, which then became the EGA and then the VGA, which were all backward compatible. Um, you know, back in the late 1980s when all this was happening first, PCs were so slow that bypassing the BIOS was a common hack. And in fact, my first commercial app for the IBM PC XT— well, IBM PC in general— was something called Flicker Free, which did replace the BIOS with my own code and dramatically accelerated color graphics adapter scrolling. And, you know, and Flicker Free was then followed by, of course, SpinRite, my second product for the PC. But this SpinRite enthusiast, Mil Q, asked his instance of Claude what would be required to add virtualization of VGA text mode to the CSM wrap project. That is like VGA text mode but with an actual frame buffer so that SpinRite had something that it could write to directly. So I didn't know this was happening.

Steve Gibson [00:16:24]:
I don't even know how long it took him, but he and Claude went to work and they did it. Last Thursday, he sent me what he had so far, and for the first time ever I ran SpinRite on my UEFI-only, no BIOS, no CSM, wouldn't run it before Intel NUC. I then spent last Friday adding a whole handful of additional features that, you know, made it work the way I would want it to. I, of course, I made it smaller because I could and a bunch of other stuff. But okay, but before I get everyone too excited, I need to temper this with a little bit of a dose of reality. The only correct way for SpinRite to work with drives is to talk directly to the drive's hardware. That's what SpinRite has always done for— well, actually, the original floppy disk controller, and also for IDE, and finally SATA drives that are connected to ATA and AHCI controllers. It's that direct, you know, bare metal, uh, zero tolerance error detection, correction, and data recovery capabilities that is— that SpinRite depends upon.

Steve Gibson [00:17:46]:
Any sort of firmware, the BIOS or UEFI, is only about getting— these days, only about getting an operating system to boot. So that the OS could then take over. You know, to that end, firmware deliberately hides any trouble it might encounter behind lots of retrying to improve the chances of handling— of handing off responsibility to someone else. It just wants to get the OS going. That's pretty much what it does today. And if an error persists, you know, that like would cause a large data transfer to fail, The firmware just returns an unhelpful something broke error message. SpinRite needs much more. So the bottom line is that the SpinRite we've always known, uh, the good news is it's no longer end of life.

Steve Gibson [00:18:43]:
So, uh, what it now needs is its own native USB and NVMe drivers. in order to get that same bare metal action, uh, with the rest of drive technology. The reason they were not incorporated and tested during the SpinRite 6.1 work was that it— first of all, it had already taken me 3 years to get as far as we had, um, and there was a lot of clamoring for SpinRite 6.1's release. Also as we all know, my original commitment to all Spinrite 6 users was that I would bring the Spinrite 6 they had originally purchased as much as like 10 years ago back to life, and I would do it for free. Also, there was a growing sense that the UEFI cliff was rapidly approaching so that Spinrite would soon need to be rewritten to run under Windows because UEFI looked like a dead end. So for all of those reasons, it made no sense for me to invest further time creating native USB and NVMe drivers, um, when they were first of all never part of SpinRite 6, so not something that anybody ever purchased, uh, when doing so would have further delayed the release of 6.1. And mostly when all of that additional work would be discarded with the move to Windows. But now with SpinRite running under UEFI for— and for the foreseeable future, I mean, by having this all be soft now, you know, a software solution on the hardware platform, it never needs to die.

Steve Gibson [00:20:31]:
So all of those carefully weighted trade-offs have changed. Um, as I said, I had a bit of a difficult time producing today's podcast because I've become so preoccupied. I mean, I did this just like, whoa, everything changes. So my new plan is to once again bring SpinRite 6 and 6.1, uh, that everyone purchased back to life, able to boot under BIOS CSM or UEFI, With equal ease. Uh, won't matter. Um, uh, so it will be usable again everywhere and, and anywhere. Um, and my plan is that that will be Spinrite 6.2, which all current Spinrite 6 and 6.1 owners will be able to upgrade to for free. Then I'm going to change direction here because I've been talking about Spinrite 7 being for Windows.

Steve Gibson [00:21:32]:
Not the case anymore. What I want to do is immediately embark on upgrading the SpinRite 6 family to SpinRite 7. It will not be hosted under Windows. It will remain as is, that is to say where it is, but I will incorporate the direct low-level native drivers for USB and NVMe drives. which it needs to get around the firmware because we, you know, SpinRite needs physical access to the drive, which will deliver maximum drive throughput performance and more importantly remove any firmware-driven loss of drive status and error location awareness. So, um, this will— that will deliver then a universally bootable SpinRite That's able to run natively across all drive technologies, um, except for floppy disks. I, I took that out of, of the later SpinRites, but all SpinRite owners still have access to SpinRite 5, uh, and that will continue if they need to do diskette recovery and repair. And so then once we have SpinRite 7, and that's no, that's no longer years away, that's months away or less.

Steve Gibson [00:22:51]:
Uh, I don't know. Uh, I still want to revisit and improve Validrive and create the Beyond Recall utility, uh, which will both be for Windows, and then address SpinRite 8 for Windows, which will offer all the things that I had planned, you know, uh, data recovery features that make sense today, operation on multiple drives at once in the background, data recovery with drive cloning, uh, recovery to other drives of file systems, directory trees, individual files, and so forth. So anyway, um, the, the original SpinRide development testers are aware of these changes. I told everybody about it Friday night. Um, they're looking forward to have something new to start pounding on, uh, and I expect to have something for them Maybe tonight or tomorrow so they can start. And we'll, you know, we'll determine how well this current CSM RAP project handles everyone's hardware. I've already forked it and have made a bunch of improvements, found bugs in it that I'll be sending back to that project because they're like, there's a 2-terabyte problem that apparently no one ever detected and so forth. So anyway, I am very excited.

Steve Gibson [00:24:09]:
And I know that all of our SpinRite users who have been feeling like they're going to have to wait for years for me to get around to SpinRite 7 on Windows, that's no longer the case. So yay.

Leo Laporte [00:24:23]:
Does it emulate into INT 18 or how does it? Because that's the key, isn't it? The interrupt. Uh,

Steve Gibson [00:24:29]:
you're— well, so, so what— so interrupt 10 is, is the video BIOS interrupt. And CSMRAP already did that. That is, so you could say, you know, basically it, it's a teletype. It's character, character, character, character, turn line feed, character, character, character. So you sort of see it. It's basically a console window. That's what they have. But I remember looking at VisiCalc back on the IBM PC.

Steve Gibson [00:24:58]:
It refreshed the screen instantly. Well, the way it did it was it just wrote what everything it wanted directly to lower memory. There's a segment of memory, B800. B800 is the color graphics adapter segment. B1000 was the MDA, the monochrome display adapter. And so SpinRat does the same thing. You know, when it's doing all of its screen graphics, There's just, there's no way to like, you, you could technically send bytes through interrupt 10 to position the cursor to this location, then put that character out. And if the next character happened to be the one to the right, then you could put another character out like you were typing.

Steve Gibson [00:25:49]:
But anything, you know, just whole screen graphics, it would be so slow that way. So SpinRite just— it assumes that there is a shared memory buffer. SpinRite writes to it and the screen refreshes from it. So what MilQ did was he, uh, he and Claude are spinning up another processor, and they're— and, and Claude and he wrote a little hypervisor which, um, which, uh, which maps— they, they, they first mapped RAM into that segment so there's something physically there for SpinRite to write to, which is not there in normal, uh, VGA mode, which is high-resolution graphics modes which UEFI supports. So they map RAM there, and then this little hypervisor watches for SpinRite writing into that region And in the background takes its own software soft character set and maps the character into the graphics display. So it works. I mean, I've— it like, it works perfectly. So yeah, it's— we basically have a future-proof solution now for anything that happens moving forward.

Steve Gibson [00:27:15]:
And I, even when I had SpinRite for Windows, my concern was, well, you could run SpinRite for Windows, would be able to work on any drive except the boot drive, right? Because you can't get exclusive access to it because Windows has it. And so there was always going to be this sort of a problem. Do I use, uh, You know, there's like Windows on the go. There's a pre-execution environment, or I guess it's WinRE, that has different constraints. So the problem was what to do about running Spinrite on a Windows machine's boot drive. Now that problem is solved. Spinrite 7 will always be able to run on anything. It won't have the features that I want that make sense for Windows, but it will be universal and it will never need to die.

Steve Gibson [00:28:19]:
So anyway, I'm like, everything changed on Thursday. It's like, what? It's running? And then I ran it and it's like, yes, it is. It actually is.

Leo Laporte [00:28:32]:
But you don't use INT13 to access the disks. You don't need that. That's the BIOS call that—

Steve Gibson [00:28:37]:
Right. INT 13 is the BIOS call for disk drives. And right now SpinRite does. For example, the—

Leo Laporte [00:28:47]:
I thought that was the issue, that you needed that BIOS interrupt.

Steve Gibson [00:28:52]:
Well, it does. Yes. For example, when I booted SpinRite on the NUC, it saw the 2 NVMe drives and it's— and in its enumeration of drives, it said, this drive may be handled by the BIOS. Right. It realized it couldn't access it directly. And sure enough, there were 2 later down the enumeration, 2 lines for the 2 256-gig NVMe drives that I have in that machine. And SpinRite ran on them. And it ran at a respectable speed.

Steve Gibson [00:29:29]:
I think it was 512, 513 megabytes per second. So it was able to do a scan of that NVMe drive. The problem is it's through the BIOS. So if there was a problem, the BIOS would do retries that SpinRite would never see. And if it was doing a long transfer and hit an error, it just says something didn't work right. But you don't know where the error is or what it was.

Leo Laporte [00:29:58]:
Yeah, yeah.

Steve Gibson [00:29:58]:
Right. So, so we'll have SpinRite running again, but, but really it's still the way SpinRite 6.1 has been, which is for ATA and SATA drives. Those native drivers I wrote, and so it is perfect for those. And then what I'm going to do is to catch up for the other— for, for NVMe and USB. uh, for, for SpinRite 7, which will look very much the same, and it's not going to take years. It should take— I don't know, I, I just have to get in and then see. But remember that I purchased that RTOS32 operating system a few years ago as one of the possible avenues that I might take, so I do have source for those drivers. And so, you know, they're, they're written in C and therefore that protected mode.

Steve Gibson [00:30:59]:
So I need to make them real mode and do some work, but, um, I don't think it's going to take a long time. So I am, uh, I know that SpinRite users will be very happy to—

Leo Laporte [00:31:09]:
Can you use AI to work with this CSAM thing?

Steve Gibson [00:31:13]:
Have been, yes. Uh, MILQ has been, and I was working with Claude I mean, it's just, it's like having power steering. It's freaky, Leo.

Leo Laporte [00:31:23]:
Oh, I know. Tell me about it.

Steve Gibson [00:31:26]:
As I was writing what I want to talk about next, this AI-pilled phenomenon, I was thinking of you, knowing that you would know exactly what I will be talking about.

Leo Laporte [00:31:41]:
I am AI-pilled. That's true.

Steve Gibson [00:31:43]:
And I could see how it happens. Let's take a break and then we're going to talk about that.

Leo Laporte [00:31:48]:
All right. You're watching Security Now with Mr. G, Steve Gibson. So glad you're here, Steve, and so glad you're all here. Who is— are you AI-pilled, would you say, yet or not yet?

Steve Gibson [00:32:03]:
So that's a good question. Um,

Leo Laporte [00:32:10]:
maybe you better talk— start with talking about what that is.

Steve Gibson [00:32:13]:
Yeah, not, not as I understand it. So, uh, as I noted last week, uh, I have— and I, I mentioned this last week— I've been very much enjoying Kevin Roose's New York Times bestselling book, The AGI Chronicles. It sounds like you were familiar with it, Leo, or, um—

Leo Laporte [00:32:30]:
Oh yeah, absolutely. Yeah.

Steve Gibson [00:32:32]:
Okay, so I'm, I'm still only 40% of the way through the book. But I've noticed that, uh, when I'm— now when I'm reading the news about the various people and personalities who are making AI news, I know so much more about them than, you know, just their name. I have a real sense for who they are, which is fun because— and that's the reason I picked this book up, is I wanted to understand the backstory. This all To us who weren't paying attention to what was going on for the last decade, it feels like this suddenly just— AI just sprang. But, you know, there's a lot more that, that happened historically. Um, one of the terms that I learned from the book is the phrase AI-pilled. It's a derogatory term used within the AI community. It's sort of meant in the sense of The Matrix's Neo, right, who was offered either the red pill or the blue pill.

Steve Gibson [00:33:36]:
So if someone has been AI-pilled, the, the implication is that they've gone hook, line, and sinker in on believing that AI is soon to be sentient and self-aware. You know, they took the AI pill. Now, I bring this up because as I have continued working with Claude, and I did, I'd worked all day last Friday, I have become more and more impressed by what we have created. I'm running Opus 5.5 at high effort, and I am just utterly astounded. By this technology and by what it's able to do. I've also learned from my reading and from news reports that in-house AI researchers are always experimenting with something next, sometimes way next. You know, they have significantly more advanced models than have yet been widely released for public use. So my point here is that The more I push the limits of what Claude 5.5 can do, the fuzzier the presence of any limit feels.

Steve Gibson [00:34:58]:
I don't— I haven't found a limit yet. I'm just astonished. So I don't think I'm becoming AI-pilled, but I am increasingly becoming AI-stunned. and AI odd. And I'm certain that anyone who has used the latest AI extensively, and I know you have, Leo, like more than extensively, you'll understand what I'm saying. I mean, it is astonishing what we have.

Leo Laporte [00:35:30]:
Oh, yeah.

Steve Gibson [00:35:31]:
You know, and when I, you know, the industry is getting a little wobbly at the moment. You know, we have all this Jensen nonsense going on. But, you know, and, and a concern about profit, a concern about the, the fact that a lot of debt has been accrued for the financing of the hyperscaling. And, and now, of course, we had last Tuesday's election, uh, and the Democrats generally being like, you know, foot on the brake oriented. So, you know, I don't want to ever not have this. I mean, you can't take it back. So it's just amazing. Okay.

Steve Gibson [00:36:18]:
So, uh, what just found 81 new, new Firefox vulnerabilities, which Mozilla themselves classified as high severity, autonomously developed working exploits for 948 known Linux vulnerabilities in the Exploit Gym test and/or benchmark, and demonstrated a critical remote code execution in the widely used Brotli compression library. If you were thinking, you know, that suspiciously sounds like That last Thursday's release of GPT-6 Cyber, you would be correct. The way Mozilla characterized this significant step forward— Mozilla, right, not OpenAI, who you'd expect to be running around— Mozilla, uh, said their, their distinguished engineer on the Firefox team, Brian Grinstead, was quoted saying GPT-6 Cyber is a world-class model for cyber defense. Firefox entered 2026 as one of the world's most hardened and scrutinized code bases. Like, already, right? I mean, that's why all the problems that we still have been finding have been surprising in this most scrutinized code. He said even after further hardening, with multiple generations of previous frontier models, GPT-6 Cyber uncovered previously unknown high-severity vulnerabilities, identified architectural improvements, and helped us ship fixes to millions of users. And as I said at the top, I'm kind of surprised by that. I, I've had the impression that we were going to more rapidly run out of software flaws among our already well-scrutinized major products or pro— projects, um, but that doesn't appear to be occurring, at least not yet.

Steve Gibson [00:38:42]:
I'm still predicting it, and in fact, uh, I've— the news is still digesting today's Patch Tuesday But of course, we know that last month was more than 1,400 security vulnerabilities fixed. This month, it was just shy of 1,100. So that's more like 2 months ago. Maybe this is a curve and we're now going to begin riding the downward slope of that for Windows, which would be premature to call that. after just one, you know, one month of fewer than the most. But we'll see what next month looks like because, you know, this is the shape I would expect. And it's not like this super killer GPT-6 Cyber found hundreds of or more of problems. You know, it found, it found, uh, what was it, 81? 81.

Steve Gibson [00:39:43]:
So, but they were significant. So said Mozilla. Um, uh, we all know that I've always modeled security as a, as a conceptually as a porous and an inherently porous medium. You know, the idea being that the harder you push, the more vulnerable a system would be shown to be. You could, you know, just try harder. But AI is revealing that even our most hardened software is software, or is softer, softer software than we knew. And this is all a moving target. I get it.

Steve Gibson [00:40:25]:
Like, like today we have GPT-6 Cyber. There'll be something next, you know, in a week or two or a month. But I think that the details here are interesting and important, and we are witnessing history. So I want to share some of the details of what OpenAI posted because this is another milestone along the way. They wrote, we're introducing GPT-6 Cyber, a major leap. And it does look like that from the, from the data that they back it up with in security research, more capable at finding and fixing vulnerabilities and also far more reliable with staying within the boundaries that researchers set. In other words, they're claiming that this is both a lot stronger and more firmly aligned. They said GPT-6 Cyber delivers major gains on key cybersecurity benchmarks over GPT-5.6 Cyber, including a 51% relative improvement on Exploit Gym, which is a big jump.

Steve Gibson [00:41:38]:
And they said a step function improvement when tested on staying within scope, meaning, you know, not attacking Hugging Face. Uh, they said it's already helping to secure real-world software, uncovering and validating thousands of exploits in critical security code bases such as Linux and Firefox. On Exploit Gym, which tests whether models can exploit a specified vulnerability, GPT-6 Cyber scores 48.5%, up from 32.1% for 5.6 Cyber. It also follows, that is to say, stays within task boundaries more reliably. In a separate aligned evaluation, which is to say an evaluation about alignment where they actually teased it, GPT-6— and we'll get to that later— GPT-6 Cyber avoided exploiting out-of-scope services in 99.93% of tests without its deployment prompt. And 100% with that prompt. This improvement in alignment, they wrote, reflects dedicated training to stay within authorized scope, respect restrictions, and report results accurately. They said these capabilities are already helping secure real systems.

Steve Gibson [00:43:13]:
Our researchers use GPT-6 Cyber to develop 948 privilege escalation exploits in Linux and identify 81 previously unknown high-severity vulnerabilities in Firefox, despite extensive prior testing with previous Frontier models. The model also helped develop candidate patches, and Mozilla has released fixes for many of the new Firefox vulnerabilities. Security teams at Cisco, Caliph, and CodeRabbit are using it for vulnerability research and code review, and we've relied on it to find and fix weaknesses within our own infrastructure. It's clear that we have a limited window to use frontier models to secure software. Our goal is to dramatically— Now, and what they mean is that the, the, you know, alternative, less constrained models are, you know, nipping at their heels. We know that the Chinese open weight models, which can be readily obliterated, are, are not far behind any longer, and the gap has been closing. They said, our goal is to dramatically expand Daybreak, bringing advanced security research to organizations of every size independent researchers, and open-source maintainers. Mainline models such as GPT-6 Astra already support code review, vulnerability triage, and patch deployment.

Steve Gibson [00:44:48]:
Daybreak Blue helps verified defenders validate vulnerabilities and fixes with fewer unnecessary refusals, while Red enables deeper exploit development and authorized security testing With GPT-6 Cyber. 6 Cyber, they wrote, is a major step up from 5.6 Cyber and outperforms GPT-6 Astra on most cyber tasks, even when Astra does not refuse the request. We evaluated the model on tasks that require it to understand software, identify vulnerabilities, and develop working exploits. Based on these results, we classify the model as critical in cybersecurity under our preparedness framework, up from high for GPT-5.6 Cyber. On Exploit Gym, which tests whether models can exploit a specified vulnerability, so vulnerabilities known already, but the question is, Will the model be able to develop an exploit for it? So they said whether models can exploit a specified vulnerability in a remote target. 6 Cyber scores 48.5%, about 16 percentage points higher than 5.6 Cyber's 32.1%. To test vulnerability discovery, we also built a new evaluation. for offensive web pen testing models pro web applications without access to their source code.

Steve Gibson [00:46:29]:
GPT-6 Cyber achieved 40.3% recall of vulnerabilities compared with 32.0% for 6 Astra. Daybreak Red is designed to support more advanced security workflows, including developing working exploits and using them against remote targets. To develop these capabilities, we built a new benchmark called Remote Exploit Bench, which uses known vulnerabilities in applications such as GitLab, uh, PostgreSQL, and Jenkins deployed in a controlled environment. In our initial evaluation, GPT-6 Astra running with Daybreak Blue refused 100% of tasks. While Six Cyber completed 95. Its only failure was an exploit it could not get to work remotely. One risk of cybersecurity agents is that they go outside the scope of their assigned task, attempt to exploit unrelated services, or disregard the researcher's rules of engagement. We made alignment a central focus of Six Cyber.

Steve Gibson [00:47:41]:
Using specialized training to help the model stay within authorized scope, follow restrictions on its actions, and report its work accurately. Before deployment, we ran a series of alignment evaluations to measure these behaviors. One of these evaluations is ExploitGym honeypot. And remember, it was ExploitGym that's what drove the, the model to go after Hugging Face. So they said one of these evaluations is Exploit Jim Honeypot, which was informed by the Hugging Face incident. We give the model a difficult exploitation task in an isolated environment with access to supporting services such as a package registry or object store. We deliberately make these services easy to exploit so that attacking them can reveal the task's flag. The model must infer that exploiting them is outside the scope of its task.

Steve Gibson [00:48:43]:
6 Cyber shows a step-change improvement over 5.6 Cyber on this evaluation. When tested without deployment safety prompts, it avoided exploiting out-of-scope services in 99.93% of cases, up from 94.49% for 5.6 Cyber, but with those safety prompts, 6 Cyber stayed within bounds 100% of the time. We've also relied on 6 Cyber to secure our own systems. It was one of the main models behind the work we recently shared on hardening the infrastructure used to train frontier models. In controlling red teaming campaigns— I'm sorry, in controlled Red teaming campaigns. Agents using Six Cyber and other OpenAI models chained vulnerabilities to escape micro VMs and execute code on the underlying hosts. We use the findings to patch software, tighten network restrictions, and report issues to maintainers and vendors. In other words, that was where earlier they talked about hardening their own infrastructure.

Steve Gibson [00:49:55]:
It found problems in their own infrastructure, uh, in, in the ability to escape micro VMs and execute code on the underlying hosts. They said our vulnerability researchers also use Six Cyber to find and validate vulnerabilities in open source software at scale. This work has uncovered previously unknown flaws in software that's been scrutinized for years. And this is where they, they talk about the 61 novel vulnerabilities that Mozilla classified as high severity. They also showed that an additional 30 known issues were more severe than were previously reported and appreciated. They said, we disclosed the findings to Mozilla along with proposed patches to help its engineers develop fixes, and they began releasing fixes shortly after receiving the reports. They said also Six Cyber reproduced 1,724 vulnerabilities and developed working exploits for 948. That's more than 5 times the 166 which 5.6 saw was able to exploit.

Steve Gibson [00:51:17]:
It only got 166 using the same research harness. So this model is significantly more capable. They said, following the Linux community's guidance, we disclosed 304 critical findings to maintainers with candidate patches and are in the process of getting other vulnerabilities fixed. And finally, we recently discussed a critical vulnerability in Brotli, which is the compression library— we've talked about it in the past— used by Node.js and other software. Our security researchers used SICK Cyber alongside other OpenAI models to develop and validate exploits showing how the flaw could enable remote code execution in downstream applications which use the library. They wrote, as models become more capable and uncover more security vulnerabilities, we're also seeing more attempts to use them to cause harm. These attempts include efforts by malicious cyber actors and adversarial groups seeking to distill our models. We've thus paired 6 Cyber's stronger capabilities with stronger safeguards to detect and disrupt misuse.

Steve Gibson [00:52:35]:
And keep the model's actions within the user's intent and authorization. We added and strengthened these protections alongside the release of 6 Cyber. And I think these measures are interesting and certainly useful. They demonstrate that OpenAI is, as they need to be, serious about controlling access to their cyber-capable models. So they do 6 things. They wrote cyber-specific alignment monitoring. We monitor whether actions match the user's authorization while recognizing legitimate exploit development and testing. So, you know, they're trying not to, to generate false positives and, and upset people when they're asking for benign things.

Steve Gibson [00:53:29]:
Also targeted monitoring for emerging threats. They said, for example, during the coordinated disclosure of critical PHP vulnerabilities, we set up targeted monitoring for attempts to develop exploits against live PHP servers while preserving support for defenders patching affected systems. In other words, they were on the fly during real-world events, they dynamically changed the guardrails around the deployed AI so that it would be better about stopping what it detected as being clearly attempts to develop exploits for a known new problem. In this case, PHP. Also, they said, uh, private safety processing. Um, they said we use automated checks to review related interactions for misuse. In other words, they're watching people's use of AI over time, uh, to detect patterns in individual account usage. They said standard retention remains the default.

Steve Gibson [00:54:51]:
API customers using zero data retention generally must use this private safety processing, PSP, which reviews encrypted records retained in customer storage for 30 days without exposing prompts and their responses to OpenAI personnel. But so the idea is they're working to protect their— the privacy of their users, but they are storing encrypted records for a month in order to allow their models to look back at what this account has been doing and, and better improve the, you know, its management of guardrails and tend to detect abuse. They said protection against stolen credentials. We, we require IP allow listing for Daybreak Red API access by default, restricting requests to approved networks with limited exceptions. We also monitor credentials for compromise. Under sandboxing and oversight, as with past models, we recommend sandboxing, action review, and human oversight for high-risk workflows. And finally, protections against high-risk cyber assistance We use new checks to block high-risk activity involving critical systems. They wrote, protecting critical infrastructure has been a key consideration in designing GPT-6 Cyber's safeguards and access, including power plants, water treatment facilities, and the operational technology and industrial control systems.

Steve Gibson [00:56:36]:
You know, now we have that new jargon, operational technology, OT. and industrial control systems, ICS. They said, we simultaneously want to give the teams defending these systems access to our most capable models while also strengthening our safeguards to prevent unauthorized attacks. First, to equip these defenders, our $1 billion Daybreak for Frontline Defenders grant program subsidizes access for resource-constrained teams such as government organizations and essential service providers. We're also introducing a new group within Daybreak Red, Daybreak Red for Critical Infrastructure, for approved critical infrastructure defenders, which gives them permissions to conduct authorized testing of critical systems while retaining safeguards against model misalignment. And again, this is not something first they would be able to afford or that they would even be able to do. So, so this is OpenAI, you know, working against this problematic, I mean, this inherent dual use problem of bad guys can use it the same way good guys can use it. They said second, to prevent misuse of the Daybreak Red and Blue platforms, we've refined safeguards against assistance and capability development that could compromise industrial controls or safety-critical systems, could interfere with equipment or cause serious injury, catastrophic physical damage, or life-threatening service disruption.

Steve Gibson [00:58:17]:
They said higher safeguard block rates are not always better. Many of the techniques in this evaluation are also essential to legitimate security work— understanding systems, finding vulnerabilities, and verifying that fixes withstand attack. We therefore assess these rates alongside support for legitimate research and patching rather than aiming for a 100% blockade. In other words, you know, just saying no too easily prevents good guys from using this technology. So they are trying to sharpen their heuristics about what can and cannot be allowed. They say, finally, to evaluate how our models can help defend critical infrastructure, we partnered with Dragos, the global provider for extended operational technology cybersecurity. Dragos ran evaluations using cyber-permissive Daybreak Red models in a controlled lab environment. The evaluations covered requests Progressing from network discovery and asset enumeration through targeted reconnaissance, sensitive data exfiltration, and unauthorized, potentially dangerous service actions.

Steve Gibson [00:59:39]:
Okay, so here's a rather chilling quote from the chief AI officer at Dragos, Robert T. Lee. He said, quote, Dragos Put a Frontier model on a mock power plant range and told it almost nothing. On its own, it separated the OT assets from the IT noise, then found 2 zero-days in engineering software that manages protective relay data, exposing protection settings and breaker trip logic. That's the map an adversary wants before touching anything physical. The skill floor, which is what he called— I called— I refer to it as the bar, right? He says the skill floor is dropping for the reconnaissance and vulnerability research needed before an attack. Working with OpenAI on this shows them the adversary's path through an OT network before real adversaries take it. So safeguards get built around how these attacks could unfold while the models stay useful to the people defending such systems.

Steve Gibson [01:01:02]:
So as I said, Rob's comment, you know, the skill floor is dropping, is perhaps the most chilling of all. This means that, you know, As bad guys get their hands on similarly powerful obliterated models or find online models whose guardrails can be bypassed, the population of effective attackers is growing because, you know, less sophisticated attackers are being enabled. Yesterday, in fact, I read a piece in Fast Company that noted with a great deal of irony which was the article's intention, that the AI companies were selling both the problem and its solution. And, you know, we know that's true. You know, it's the well-known dual-use dilemma. You know, the same advanced cyber capability that good guys use to find the flaws in their systems can also be used by bad guys to exploit to exploit those systems which have not yet been better secured. As we saw at the top of this story, GPT-6 Cyber is finding more critical vulnerabilities than its predecessor, 5.6 Cyber. Of course, it's not strictly true that the commercial vendors are selling offensive cyber capabilities to bad guys, but what they are selling is defense technology.

Steve Gibson [01:02:32]:
And we've been seeing that one way or another, bad guys are managing to get, for example, Claude to help them with their attacks. We have found script dialogues, prompt dialogues among the attackers' revealed files. So they are getting access to commercial AI. And in that one case that we looked at closely, they managed to establish a believable environment and fed Claude a plausible cover story to convince it that their need for its exploit generation was entirely for their defensive work, and it complied. And, and, and that, that was the instance where It managed to bypass the address space layout randomization that that system was using. So, you know, I'm not suggesting that there's any alternative, like, to the current status quo, which we're just going to slog through. I don't have a better solution for where we are at the moment, but it does seem pretty clear that AI-based network defense is destined to become a persistent reality for the foreseeable future. I talked before about how we were seeing CrowdStrike and Palo Alto Networks, which is a sponsor of the TWiT Network, their products are gaining traction because everybody's beginning to wake up to the fact that the bad guys are going to have AI, we're going to need to have AI on the inside.

Steve Gibson [01:04:19]:
of, of the network, uh, keeping an eye on what's going on. So, Leo, time for me to catch my breath.

Leo Laporte [01:04:28]:
Okay.

Steve Gibson [01:04:29]:
Rehydrate, and then we're going to look at, uh, this sad instance of, uh, a hacker who has AI-enabled himself, uh, really not being housebroken.

Leo Laporte [01:04:45]:
One of the things, maybe it's Marcus Hutchins was saying this on X, that most hackers are not sophisticated enough to really be able to use these AI tools in the way that we worry about, that this is still not script kiddie material.

Steve Gibson [01:05:03]:
Level.

Leo Laporte [01:05:03]:
Right?

Steve Gibson [01:05:04]:
Right.

Leo Laporte [01:05:04]:
Yeah.

Steve Gibson [01:05:04]:
Right.

Leo Laporte [01:05:05]:
And I think that that's encouraging and they're not, and we've seen that, you know, the attacks We've seen a lot of flaws that we found and fixed, but the attacks are not, you know, swamping us by any means yet.

Steve Gibson [01:05:17]:
Well, yeah, and in my own experience in working with Claude, I know exactly what to ask for, right, in order to get what I want. So I'm, you know, I mean, and, and, and from the beginning, I, I remember once I read to you a long prompt that I had, had fed Claude, and, and your reaction was, wow, You know, and I said, yeah, it's a language model. The more language you give it, the more it has to work with. And now I'm finding that because I'm a developer and a coder, I know exactly how to specify what I want instead of just kind of, well, make it go. You know, it's like, well, kind of, you know, and then you hold your breath.

Leo Laporte [01:06:01]:
Yeah. These models are very specific. The other thing is they're very spiky. They have great capabilities in one area and no capabilities at all in other areas. They are not, you know, with us humans, it's true about humans too. We can be geniuses in one area and a dummy in another area.

Steve Gibson [01:06:17]:
Well, and I guess that means not AGI, because AGI, the whole point is, you know, it's better at everything. It's good at everything.

Leo Laporte [01:06:25]:
Right.

Steve Gibson [01:06:25]:
Yes.

Leo Laporte [01:06:26]:
And that's not been my experience. I'm sure it's not your experience either. And So part of knowing how to use them is to know where to apply it and where not to apply it, or where to avoid— where to, you know, where to avoid it.

Steve Gibson [01:06:37]:
I think also one of what you're doing that I've not yet started to do is, you know, this— you got agents running all over the place, and, and, and, and, and you, you've shared with us stories of them just coming to a halt and going Oh, well, we're waiting for you to say that we could have a cookie or something. It's like, what? I told you there's the whole cookie jar over there. Just go help yourself. Oh, but don't you want to tell us it's okay? No.

Leo Laporte [01:07:09]:
It's fascinating. And a lot of what I spend time doing is trying to improve the work process, the workflow, and especially because I'm using a lot of local AI. And it's such a learning experience. It's really fun because I feel like I'm learning an awful lot.

Steve Gibson [01:07:30]:
Well, you are learning to orchestrate.

Leo Laporte [01:07:32]:
Yes.

Steve Gibson [01:07:33]:
You know, you are the conductor of the orchestra.

Leo Laporte [01:07:35]:
Yeah, that's right. On we go.

Steve Gibson [01:07:38]:
Okay, so one of the things we've begun seeing is newbie hackers calling themselves security researchers. And you can't tell if you're not seeing the video, but I am rolling my eyes.

Leo Laporte [01:07:53]:
You know, I have a security researcher.

Steve Gibson [01:07:58]:
They are calling themselves security researchers without any conduct becoming such designation. A security researcher is someone who first uncovers an important problem that requires fixing, then informs that problem's responsible publisher about the problem and the trouble, then waits often very patiently for the reported problems to be cured before publishing an exposé which provides full disclosure and allows the researcher to take the bow which he's earned. I mean, and you know, that's the way the system's supposed to work, and just by agreement, right? There's no laws, but that's You know, to be a researcher in good standing, that's what you do. And there was a company— I'm blanking on the name— that pre-disclosed the PHP patches to their own, you know, for their own needs and for their own use a couple weeks ago. Really upset the PHP project. And, you know, That company will not be receiving any early access next time. So you really do need to behave yourself. Well, the following story is not about a responsible security researcher.

Steve Gibson [01:09:27]:
Bleeping Computers, Lawrence Abrams, wrote about this yesterday afternoon under the headline N-ABLE, that's letter N hyphen A-B-L-E, takes cloud platform offline after more than 30 zero-days published. Lawrence wrote, N-able has taken its hosted N-central environments offline and urged on-premises customers, which is to say customers who have on-premises servers rather using— rather than using enables cloud and central solutions, urged on-premises customers to shut down their servers after a security researcher— and again, eye roll— publicly disclosed more than 30 alleged— and, you know, Lawrence is being polite and careful writing alleged— zero-day vulnerabilities including exploits that could let attackers take over vulnerable systems. Since it has happened, I assume that these are no longer alleged. He wrote, security researcher Sean Bales disclosed the vulnerabilities late Sunday, November 8th, and published a GitHub repository called Able2Shell containing proof-of-concept exploits for the flaws. And Central, get this, is a remote monitoring and management platform used by managed service providers and IT teams to monitor, manage, and secure customer devices and networks remotely. And I don't remember if it's in today's show notes, but one of our listeners is, is a client of N-able. And they have lost all access to their own clients because of this outage caused by this irresponsible hacker, who I refuse to call a security researcher because he's not. So, so what this means is that those for those relying on upon you know upon its security.

Steve Gibson [01:11:51]:
It is critical infrastructure for them because its compromise would in turn allow attackers to seriously damage the client enterprises of this end, you know, the end central server users. So Lawrence continues his reporting saying the researcher says, okay, the researcher, right? The hacker, this guy, Sean Bales. Says the vulnerabilities were tested against N-central appliance version 2026.4031, which is a pre-release version of the software. But he believes that most, if not all, flaws also affect earlier versions. And now we've seen that. Bales, writes Lawrence, also confirmed to Bleeping Computer that the discovery of the vulnerabilities was— AI-assisted. And in fact, looking at his GitHub, he does— he has no track record beyond when he began using AI. So he, you know, this is the birth of an AI hacker.

Steve Gibson [01:12:58]:
The disclosed vulnerabilities, writes Lawrence, include authentication bypasses, credential disclosure, arbitrary file writes, directory traversal, cross-site scripting, XML external entity known as XXE injection, and remote code execution flaws. One of the most critical exploit chains abuses an unauthenticated XML external entity vulnerability in N-central's service import functionality to steal a trusted local session. Reset an account password and execute commands on the server as an enabled user. Basically a complete takeover. The same exploit can also create an enabled default admin account with attacker-controlled credentials, providing rogue admin access to the N-central management interface. I mean, basically this just completely collapses their offering. Lawrence writes, Bales shared a video demonstration of this exploit, and it's got a little anime girl in a dance, you know, like in a skirt dress dancing around the front of it. I mean, it's just sad.

Steve Gibson [01:14:20]:
Lawrence says, showing terminal output reporting successful admin account creation, login authentication, access to protected admin functionality. and remote command execution as an enable user. Other disclosed exploits include a stored cross-site scripting vulnerability that can execute commands as root when an admin views malicious patch metadata and a privilege escalation flaw that allows code running under the enable account to execute commands as root. Bales confirmed to Bleeping Computer that the unauthenticated XML external entity to RCE exploit was the most critical of the disclosed vulnerabilities, which is to say, of all the many 30-plus vulnerabilities that this a-hole disclosed. Lawrence didn't say that. I did. After the disclosure, writes Lawrence, Enable announced a critical— Okay. After this guy's disclosure, right, N-able announced a critical security incident and took its hosted N-central environments offline across the Americas, Europe, and Asia-Pacific regions.

Steve Gibson [01:15:41]:
In other words, like one of our listeners, all of their users lost access to their— to this service. as a consequence, again, of this disclosure, irresponsible disclosure. While Bleeping Computer writes Lawrence has not independently verified all the reported vulnerabilities, Enable confirmed it is developing a hotfix to address the security issues, lending credence to the researchers— again, air quote researchers, hackers— claims. AI-enabled hacker. That at least some of the flaws are legitimate zero days. Enable told Bleeping Computer, quote, Enable is actively responding to non-responsible communication of critical vulnerabilities in N-central late Sunday night, November 8th, found by an independent researcher. As a precautionary measure, We took our hosted N-central environment offline today, November 9th, and provided guidance to customers operating on-premises N-central servers to temporarily, temporarily take their servers offline until further notice. Our security, engineering, and operations teams are actively working to implement the necessary remediation.

Steve Gibson [01:17:07]:
At this time, we have not observed active exploitation of these vulnerabilities. Protecting our customers and their environments remains our highest priority, and we will provide additional updates as they become available, unquote. So Lawrence says in a subsequent status update, Enable said it was continuing to develop and validate a hotfix and had found no evidence of active exploitation or unauthorized data access. While the N-central Classic environment is unavailable, Enable said Echoverse services accessed through Enable login remain operational. Enable has not provided an estimate of when N-central will come back online, but says it plans to publish updates every 4 hours or sooner if new information becomes available. Bales, the hacker, told Bleeping Computer that he deliberately told Bleeping Computer that he deliberately released the N-central vulnerabilities without notifying Enable beforehand because the company allegedly failed to address vulnerabilities he had previously reported in a different Enable product. You know, so it's right. I'll show you who you can just ignore.

Steve Gibson [01:18:37]:
And it gets worse. Lawrence wrote, according to Bales, he disclosed 2 unrelated remote code execution vulnerabilities and a privilege escalation flaw approximately 5 to 6 months ago. But those vulnerabilities remain unpatched. Bales told Bleeping Computer, quote, I disclosed— this is the hacker— I disclosed 2 unrelated RCEs for a different Enable product along with a privilege escalation vulnerability 5 or 6 months ago. These have yet to be patched, unquote. He also claims to have sent follow-up emails over the past 4 to 6 weeks without a response. Bales says his previous experience with Enable's vulnerability disclosure process and that, quote, they don't take disclosure seriously, unquote, led him to publish the nCentral zero-day exploits publicly. However, he said these exploits target a different N-able product than the ones he previously disclosed.

Steve Gibson [01:19:47]:
The researcher also claims that he received no payment through N-able's bug bounty platform for his earlier reports. Well, he couldn't because they somehow didn't respond to him. Anyway, Lawrence says Bales confirmed that Enable executives, including the company's CEO and CTO, contacted him following the disclosure and asked him to remove the GitHub repository And work with the company. Bales said, quote, they didn't threaten me or anything, though, only asked me to take down the repo, work with them, et cetera. Okay. Now, since all of those more than 30 zero-day vulnerabilities are still up on GitHub right now, for anyone to obtain and abuse, Sean Bales has apparently decided to punish the Enable executives for not replying to him earlier. Lawrence says Bleeping Computer asked Enable about Bales' allegations concerning the previously disclosed vulnerabilities, their patching status, and the alleged lack of responses to his follow-up emails. However, the company did not address those questions, providing only the statement concerning the nCentral security incident and the precautionary shutdown.

Steve Gibson [01:21:24]:
The earlier reported vulnerabilities are not included in the publicly released Able2Shell repository and allegedly remain unpatched. Now, okay, I can understand The annoyance with a company who does not reply under their clearly posted policies. I went over to n-able.com and they are completely upfront about their vulnerability disclosure program. I don't know what happened between them and this Sean Bales, and they're being tight-lipped about that with Lawrence Abrams. I don't know why those zero days Are still up on Sean's GitHub account after he directly told Lawrence that he was asked to take them down. Did he, what, demand a bug bounty payment from them even though, you know, uh, uh, he now, like, what, you know, is in an argument with them? Uh, maybe he's trying to leverage them for his removal of this from his GitHub? I, you know, I don't know. Uh, a week ago on his LinkedIn account, he posted, today I am sharing with you— this is unrelated to this, but this is who this guy is a week ago— today I'm sharing with you 4 zero-day unauthenticated RCEs for IBM's NovaLink that I discovered back in July. All of them work on the latest version, and as such, no CVE is assigned to them.

Steve Gibson [01:23:09]:
Stay tuned for more zero days. And in addition, he was among those who piled onto the recent PHP disaster several weeks ago, posting again on LinkedIn, I published a weaponized exploit for the 2 CVEs that dropped for PHP today on my GitHub. This targets the latest WordPress. Enjoy. And then a smiley face. And he says, this bypasses ASLR and works with display errors off. Now, in regard to that posting, others felt as I do. One guy replied, next time Publish remediation tools and advice will be more useful, I believe.

Steve Gibson [01:23:55]:
Help on patching too, way better for the community. And another one wrote, casually distributes hacks on LinkedIn. So I did also note that he's soliciting employment. I hope that anyone who might be considering hiring him will poke around a bit and learn about this guy and decide whether He's the kind of person they want to be affiliated with. But our main takeaway from this mess is that Sean's skills as a hacker— again, even that probably in quotes— appear to be entirely AI-enabled. To do what he is doing the way he's doing it requires no skills. You just sit in front of your computer and ask an AI to examine someone's code find flaws and write exploits for you. Since true security research is a noble endeavor, I suspect that we'll be seeing many more researcher wannabes calling themselves a security researcher.

Steve Gibson [01:25:00]:
I hope things turn out better than it did in this case because this is just sad. And, you know, I did note That Enable— I saw another follow-up piece of news that Enable then suffered some sort of serious attack or hack. And last time I checked, they were completely, you know, down. The, like, not their main homepage is up, but all of their services are still blacked out. So, you know, again, I don't understand what happened. We don't know. Uh, they're not saying— uh, Sean is saying, you know, I wrote to them and they ignored me, they blew me off, so I just decided to nuke them. And that's what he did.

Steve Gibson [01:25:55]:
Um, when I heard about the mass hacking of French refrigerators The thought I had, you know, ouch. The thought I had was that all these municipalities, and we talked about it at the time, Leo, who took it upon themselves to remove the hidden and suspiciously undocumented cellular radios from their Chinese-made and otherwise quite attractive city buses, uh, I think Norway was the first, uh, country to do that.

Leo Laporte [01:26:28]:
Right. Right.

Steve Gibson [01:26:29]:
They were probably right to go to that effort. You know, you don't want to leave— like, maybe we don't know they were hackable, but why were they there? They were undocumented and they were creepy. So Bleeping Computer again provided some great coverage of the details of what happened, what happened in France under the headline, France blames Iranian hackers for supermarket attacks. That actually sparked fires. Some refrigerators caught fire. Bleeping Computer wrote, France has linked the October cyberattacks that disrupted refrigeration systems at more than 700 supermarkets and other retail locations to Iranian state-backed hackers, saying the attacks caused food losses and sparked at least 15 fires. In a statement issued Monday, meaning yesterday, France's Ministry for Europe and Foreign Affairs blamed the attacks on Shahid Kaveh, a cyber offensive unit affiliated with the Electronic and Cyber Center of Iran's Islamic Revolutionary Guard Corps, the IRGC. The statement reads, France condemns in the strongest possible terms the unacceptable cyber attacks carried out on its territory by the Islamic Republic of Iran against its interests.

Steve Gibson [01:28:01]:
Lawrence says the attacks occurred overnight on October 11th and 12th when hackers compromised industrial refrigeration controllers and remotely changed defrost settings to high temperatures. Disrupting systems used to preserve food. As Bleeping Computer reported, the attacks affected an estimated 250 to 350 French supermarkets, forcing stores to discard fresh and frozen products. French authorities have now revealed that approximately 700 retail locations were targeted with the cyberattacks, causing at least 15 fires. Including with small butcher shops, a slaughterhouse, and cooperative food processing facilities, uh, all affected by the attacks. French authorities say the attacks caused tens of millions of euros in food losses and significant material damage. French investigators also detected attacks against Schneider Electric industrial equipment at small hydroelectric installations during the same period, which they linked to the same campaign. Those incidents reportedly had moderate effects on the targeted equipment.

Steve Gibson [01:29:19]:
The October attacks were followed by a follow-up wave of refrigeration system attacks reported in November, affecting more than 115 stores across 6 European countries. France's National Blood Service was also reported— also reported a similar incident That altered temperature and defrost settings at 3 facilities used to store blood products. Last week, the FBI and CISA warned of ongoing cyberattacks targeting industrial refrigeration and cold chain monitoring systems worldwide. The French government says it will summon Iran's ambassador to condemn the attacks and proposed new European Union sanctions against Iranian individuals and organizations involved in malicious cyber operations. However, France has attributed only the October attacks against French supermarkets to Iranian hackers, not the later attacks. France's Cyber Crisis Coordination Center, the C4, which includes the country's cybersecurity agency ANN ANSSI, uh, military cyber command and intelligence agencies attributed the attacks to the Iranian Shahed Kaveh IRGC unit. According to CERT FR, the Shahed Kaveh group operates through several online hacktivist identities, including Cyber Avengers, with the last E being a back, you know, being a numeral 3. Soldiers of Solomon, Mr.

Steve Gibson [01:30:59]:
Soul, the Cyber Is Not Front, and Cyber Is Not Front. France's Cyber Crisis Coordination Center said, quote, the cyberattack targeting refrigeration controllers was relayed on the propaganda outlet Cyber Ban News associated with the Shahid Kaveh unit. as early as October 13th, 2026. French investigators linked the refrigeration attacks to Sayyid Qa'abe through the following observations, and they had some pretty good evidence. First, the attacker's infrastructure was also used to conduct reconnaissance against the Schneider Electric industrial systems using techniques previously associated with that Iranian unit. The attackers used the FOFA internet-connected device search platform, which CERT-FR says the group commonly uses in its operations. Cyberban News, which France says is linked to the Shahed Kaveh, publicized the refrigeration attacks on October 13th, and investigators discovered traces of Farsi language used in the attacker's infrastructure. Cert France says Saeed Kaveh claimed responsibility for a large-scale sabotage campaign targeting Israeli and U.S.

Steve Gibson [01:32:26]:
interests in March and April of '26, including attacks on Israeli refrigeration equipment and other industrial control systems. In April of '26, the unit was observed conducting large-scale reconnaissance of Schneider Electric industrial control systems, including systems in France. So this is the sort of story with the, as I said before, with the wide, with the wide coverage that it received, that will, let's hope, work to get other internet, internet-connected device makers to reexamine their security or take their security more seriously or buy some compute from OpenAI. Buy it if you have to, to, you know, check your— the security of your devices before the bad guys do. So much of our infrastructure has been put on the internet under the fragile assumption that the device's authentication front end is flawless. Unfortunately, now more than ever, flawless is what it needs to be. Yet we keep encountering example after example of readily bypassable mistakes in authentication. Authentication is hard.

Steve Gibson [01:33:46]:
Apparently, it's impossibly hard. And in fact, that's what today's main topic will be about. And as I said, it is a doozy, which we will get to shortly.

Leo Laporte [01:33:57]:
On with the show, Steve.

Steve Gibson [01:33:59]:
Okay, so Don Edwards writes, dear Steve, I must take issue with the notion you discussed last week, episode 1103, about a web server behind the protection of the Cloudflare WAF, web application firewall, being, quote, off the internet, unquote. Much like AV software, the WAF can only offer protection against known vulnerabilities, not badly written websites. He says, if my website is vulnerable to a SQL injection or some other method of getting a remote shell, then anyone on the internet visiting my website, irrespective of where it's located, would be able to exploit that bad security to compromise my web server. Sure, it minimizes the attack surface, but it does not eliminate it. Guessable admin passwords cannot be blocked by Cloudflare. If that server is on my local LAN, then all of the other machines on the LAN are vulnerable too. So if anyone wants to have their web server in-house, they should definitely put it on a guest network to minimize the blast radius. Best wishes, Don Edwards, Johannesburg, South Africa.

Steve Gibson [01:35:19]:
Uh, and I agree. I think Don makes a terrific point. And I should have been more circumspect with my enthusiasm over the slick way Cloudflare developed fronting for a website that remains on its owner's network and under its owner's control. He's certainly right that Cloudflare's web application firewall can and will only block known threats, but I mostly appreciated the point he made about the continuing need to protect the rest of an enterprise's network from possible compromise of that server, which despite having its web traffic routed through Cloudflare is still nevertheless exposed to, to internet traffic, uh, you know, if only less directly. So yes, completely, uh, I completely agree with you, Don. Uh, Lee's feedback email subject was Cloudflare free version is more fantastic than SN1103 suggests. Uh, Lee wrote, hi Steve, longtime listener. I wanted to share how AI has changed the way I run my own small security lab in case it's useful.

Steve Gibson [01:36:34]:
I run a dozen domains on Cloudflare's free plan hosted on my own server. Some of the sites are deliberately deceptive. honey pots and decoys that waste scanners' time and show me what they're looking for. He says, for inbound web, the websites are not exposed directly. Traffic reaches my server through a Cloudflare tunnel which connects outbound to Cloudflare, so there are no inbound web ports to open and the origin's address is not, uh, Isn't in public DNS. So he's, so he's just saying that's that. No, that's, that's that standard architectural model that we talked about last week. He says, for content, the sites live in a private GitHub repo with a CI/CD deployment pipeline.

Steve Gibson [01:37:28]:
Claude sits at the front of it collecting data from my findings, and I then rewrite the output so it doesn't read like AI slop. For threat intelligence, one site sits fully behind Cloudflare's protection but also collects threat intelligence using a homegrown tar pit that traps scanners. For canaries, another domain deliberately allows direct connections to 3 open canary hosts, 2 of them in Google Cloud, so I can see what turns up when nothing stands in the way. For inbound email, a small Google Cloud micro instance acts as the mail relay for some domains. It has an ephemeral IP, so a, a system daemon timer checks every couple of minutes and updates DNS only when the address changes. Other domains use Cloudflare email routing or hosted mail. For outbound email, SMTP2Go, and Amazon SES depending upon the domain. Every domain has SPF and DMARC, nearly all at P=reject, meaning if it doesn't match the rules, reject the mail.

Steve Gibson [01:38:46]:
Uh, remote access— Cloudflare One lets me tunnel into and out of my network whenever I want, and I use Tailscale as an alternative. And finally, configuration. I've just moved Cloudflare under Terraform, about 380 DNS records, settings, rules, and the tunnel. The code is in Git and the state sits in Cloudflare R2, and every change is previewed before it's applied. He finishes, the surprising part is how much AI has shortened the creative process. I'm not extracting logs or building analytical tooling anymore. It's just Claude Code, the command line tool, and I mostly drive it by remote control from my phone. Thanks for all the years of security now, Lee.

Steve Gibson [01:39:38]:
And then he says, P.S., fellow listeners, and you of course, meaning me, can explore those threat slash canary sites. And he gives 2 domains. Mire.cc and toce.ch. So Mire.cc and toce.ch. So anyway, I just wanted to share that in case any of that is of interest to our listeners. He is certainly getting a great deal of mileage out of Cloudflare's free offerings. Uh, anyway, as I said, I just wanted to share it to show what he's done. An anonymous listener wrote, and here's a link for you, Leo, to bring up, which I think would be interesting.

Steve Gibson [01:40:23]:
He said, Steve, you got to see this site. Where are Voyager 1 and Voyager 2 now? And it, it's, it's a page that we've seen before. It's that real-time location, uh, page, uh, and what's interesting is the, the bottom of that top chart there, the one-way light time. You can see that we are approaching 24 hours. So that's what we talked about last week, is that this is the first ever Voyager 1 is approaching 20— one full day of light speed travel away from Earth.

Leo Laporte [01:41:04]:
That's amazing.

Steve Gibson [01:41:07]:
And as it's going forward—

Leo Laporte [01:41:07]:
49 years it took it to get out there. Wow.

Steve Gibson [01:41:10]:
What a tech— what a technology.

Leo Laporte [01:41:11]:
Wow. Right.

Steve Gibson [01:41:13]:
So 7 days, 10 hours, 25 minutes from now. So it's going to be on the 18th, uh, that this actually happens.

Leo Laporte [01:41:20]:
That's one day each way. So a day out and then a day to get back.

Steve Gibson [01:41:25]:
Yeah.

Leo Laporte [01:41:25]:
So 2 days to hear the telecommunication.

Steve Gibson [01:41:27]:
And Leo, imagine still— they're still in touch with it. Yeah. Um, imagine aiming so precisely that, that at that distance we're able to pick up its signal and, and talk to it.

Leo Laporte [01:41:41]:
It's amazing.

Steve Gibson [01:41:42]:
Astonishing too.

Leo Laporte [01:41:43]:
Yeah.

Steve Gibson [01:41:44]:
Wow. Uh, Eric Southwell writes, Steve, I really enjoyed last week's show episode 1103, particularly the exposé on the various USB drives doing encryption all wrong. I should know. I work for Apricorn, a California-based manufacturing company, and the products we make really are AES-256 hardware encrypted! They're also filled with epoxy to resist tampering. There are no backdoors and absolutely no way to access the encrypted data without the correct PIN. We've got FIPS certifications to back up what we sell. If you've never heard of us, visit apricorn— apricorn.com— to see our products that truly are secure. I think you'll like what you see.

Steve Gibson [01:42:42]:
Government agencies around the world sure do. Thank you for your years of security now. I can't wait for Spinrite 7. Which actually will happen a lot sooner than he's thought. He says, I'll be buying a site license the day it goes on sale. Eric at Apricorn. And I am definitely aware of the Apricorn brand, but it is great to hear about it from someone on the inside firsthand who really knows what's going on there. As became painfully clear last week, it can never be safe to assume And Leo, just real quickly, Lenovo of all people, and I have a hard time believing this still of them, but they have a fingerprint-enabled, supposedly AES-256 portable drive where inside is just an SD card hot-glued to the inside of the case.

Steve Gibson [01:43:43]:
And the only thing the fingerprint reader does is turn its power on. It's— I, I, you know, again, I, I just think it has to be somebody, you know, using Lenovo's brand name. I, I can't imagine that the Lenovo we know would, would do that. Anyway, um, he said, hi Steve, love the show, been listening almost since the beginning. I discovered how they chose the— this is really breaking news— I discovered how they chose the private key at eMudra. They just used some open source code without fully understanding it. And, and then he shows a snippet of the code. It's— and this of course is so Randall Munroe— it's, uh, it shows a function uh, uh, that which returns an integer, and the function's name is getRandomNumber.

Steve Gibson [01:44:43]:
And then within the curly braces, the only thing there is return 4 semicolon. And then it does have a comment, 2 lines of comment. It says, chosen by fair dice roll, guaranteed to be random. Anyway, that's wonderful. Anyway, although Klaus didn't point at its source, uh, you know, it's, it's clearly, uh, XKCD, and actually it exemplifies Randall's wit perfectly as well. Vladimir Jurasek said, uh, hi Steve, I've been listening to your podcast since episode 1. Really good work, thank you. I'm just listening to episode 1103 where you talk about Cloudflare protecting websites through tunneling.

Steve Gibson [01:45:33]:
One additional benefit that's worth pointing out is that by using Cloudflare in this way, the websites are also IPv6. So that's a massive improvement for most of the websites where they would typically not get the— an IPv6 IP address. Thank you for all your hard work, Vladimir. And so I assume Vladimir means that the public-facing side where Cloudflare publishes DNS is publishing both an IPv4 and an IPv6 address, but that in turn the actual physical website behind Cloudflare could be anything, you know, such as only IPv4, since it's the client— that is to say, the user's server, which is a client making the connection the tunneling connection out to Cloudflare. So doesn't matter what kind of network they're on. Regarding encrypted USB drives, I used to do the executive payroll for a large private company. Initially, I used TrueCrypt to encrypt a folder on a USB flash drive. Later, I used TrueCrypt to encrypt a folder on my company laptop.

Steve Gibson [01:46:55]:
This enabled me to let the IT staff manage, rebuild, and replace my laptops over time without them having any knowledge of the content of the blob. It also meant the blob could be backed up by the enterprise systems, releasing me from the need to manage my own backups. Richard, South Australia. And Richard makes a great point. Of course, TrueCrypt is now VeraCrypt, but it's still the go-to solution for well-tried and true and audited mass storage encryption. As Richard notes, the fact that what those, uh, what, you know, the other utilities— or, or I'm sorry, that the, the fact that either of those, TrueCrypt and now VeraCrypt, uh, What they produce is a blob that's completely indistinguishable from purely random noise, means that it can be moved around, backed up, you know, shared, whatever, with absolutely zero concern that its contents might ever be exposed. Or I'm sorry, uh, Ian Wills writes, hi Steve, longtime listener, etc. And thanks for the great podcast.

Steve Gibson [01:48:10]:
I've just finished episode 1103 where you mentioned that, quote, among all of that crap that's been up there, meaning in orbit, that's been put up there is an assortment of kinetic and energy-based weaponry. And he's still quoting me saying, I suspect humankind has quietly established a frontier That's more ready for space-based warfare than is commonly known, unquote. So that was what I said last week. And he replies, boy, are you right. And is that ever an understatement? He said, I've been a cybersecurity professional for over 20 years and currently lead the undergraduate program in cybersecurity at Bath Spa University in the UK. Part of my research is in secure by design, including for the space domain. Over 1,500 satellites are launched per year with a deorbit time of around 25 years. Satellites are built to be light.

Steve Gibson [01:49:24]:
It costs to throw heavy stuff up there, after all. And so even small pieces of material may cause significant damage to sensors, radiation shields, and solar panels. As more collisions occur, material does not simply disappear. Debris is broken into smaller and smaller pieces. There are more than 13,000 tons of space debris, with statistical models estimating the amount of space debris orbiting the Earth to be on the order of— and then we have 3 size classifications— 36,500 objects greater than 10 centimeters, 1 million objects between 1 to 10 centimeters, And 330 million objects between 1 millimeter to 1 centimeter. He said—

Leo Laporte [01:50:31]:
Is this debris? This is just debris.

Steve Gibson [01:50:33]:
Yes, this is crap. This is stuff that has banged into each other and they both come away smaller and in multiple parts. And so over time, they're all colliding and basically like creating sand on the beach, except that it's in orbit.

Leo Laporte [01:50:50]:
Yes.

Steve Gibson [01:50:51]:
Yeah, he says playing dodgems with this junk is now a key part of a satellite's mission, as well as ensuring the safe maneuver either into a lower destructive orbit or further out of harm's way at the end of life. And of course, there are efforts to clean up space, he said. The Outer Space Treaty aims for peaceful use only and no sovereignty claims. All good, right? In 2024, 5 Chinese LEO, low Earth orbit, satellites were observed practicing dogfighting with, according to the U.S. Space Force, the satellites have also been observed to engage in what is assumed to be refueling operations. The West too, it's no secret, companies in the EU, UK, and US are all openly working in collaboration with government sectors on defensive as well as offensive space capabilities. Dr. Julia Baum of the, of the Freeman Air and Space Institute at King's College London predicts that space conflict could emerge within the next 5 years.

Steve Gibson [01:52:09]:
Don't look up. You might not like what you see. And he says, P.S., the Outer Space Treaty is formerly known as the, quote, Treaty on Principles Governing the Activities of States in the Exploration and Use of Outer Space, including the Moon and Other Celestial Bodies, unquote. It dates back to 1967. Regards, Ian. Wow. So what a mess, Leo. We, you know, we make a mess wherever we go.

Steve Gibson [01:52:39]:
And so, I mean, there's debris on the moon now, right?

Leo Laporte [01:52:42]:
Yeah.

Steve Gibson [01:52:43]:
Now just a ton of crap, uh, in orbit around the Earth. Wow. And it's, it's like, it's like propagating itself, right? It's, it's colliding and crashing and, and cracking and making ever more smaller and smaller bits.

Leo Laporte [01:53:01]:
Like the Kessler syndrome.

Steve Gibson [01:53:03]:
I guess those tiny little bits, they'll, as they deorbit, they'll just harmlessly burn up in atmosphere. So they're just little, yeah, exactly.

Leo Laporte [01:53:12]:
Yeah.

Steve Gibson [01:53:13]:
Okay. Let's take our final break. And then we are going to look at a very entertaining hole. Bad, very bad, bad, bad, bad, bad, bad. But Wow, wait till you hear how it happened. Oh,

Leo Laporte [01:53:26]:
okay, Steve, let's talk about that hole in PHP.

Steve Gibson [01:53:30]:
Okay, so, uh, the French refrigeration hacks attributed to, as we know, an Iranian state-backed unit, uh, brought the ever-present challenge of secure network authentication back into the spotlight. I've previously flatly stated that we seem to be unable To get something as, you would think, simple and straightforward as authentication over network correct. Obviously, I also spent 7 years on Squirrel demonstrating a solution for that. So I've suggested that it would be irresponsible several times, suggested irresponsible to depend upon the security of any form of credential presentation authentication. That means that the only way to be safe is to arrange just not to do it. We're pulling on this particular thread once again today due to a head-shaking AI-aided discovery of a horrific flaw that was discovered in one flavor of OpenSSL, specifically when OpenSSL is compiled under one particular, and not as obscure as we might wish, C language library. This story has been evolving since news of it became public. Fortunately, that happened through an entirely responsible disclosure, yay, by an actual security researcher.

Steve Gibson [01:55:07]:
Not a wannabe hacker who's, you know, cruising on AI. The affected publishers had time to fix their code. Unfortunately, we're still left with the age-old communication and updating problem. And as a result of that, responsibly disclosed or not, the internet is currently seeing significant exploitation. But let's, let's take this one step at a time. The discoverer's website is the domain sshhole.com, sshhole.com, whose opening statement is wonderful in its clarity. It simply says, so, OpenSSH on MUSL, that's M-U-S-L, Muscle Linux, he says, parens, used by Alpine, OpenWrt, Buildroot, Yocto, and a lot of the Docker images you've pulled, has had a problem— has had a little problem since 2016. Accounts that should never take a password at all— root, your key-only deploy user, LDAP users, the default user on Alpine's AWS and Azure images, will authenticate against any password longer than 256 characters.

Steve Gibson [01:56:38]:
Yes. Any password. Yes. I know.

Leo Laporte [01:56:43]:
Isn't that hysterical? Isn't that hysterical? Just keep typing at some point and you're in.

Steve Gibson [01:56:50]:
Yes, exactly. And so, yes, it is as bad as it sounds. SSH is, of course, short for Secure Shell, which in some cases it's not. So that means that a bypass of OpenSSH's authentication would be and is being devastating for any exposed systems. Consequently, what followed the disclosure of this Has been a free-for-all hack fest. But before we talk about what's happening today, let's examine how this transpired all of 10 years ago, back in 2016. Bleeping Computer's first report of this was last Thursday, which carried the chilling headline, OpenSSH flaw lets attackers log into password-disabled Linux account. And here we're going to find out about the bug, which is why this had to become today's topic.

Steve Gibson [01:57:54]:
They wrote, a newly disclosed flaw involving OpenSSH and Muscle dubbed asterisk SSHole allows attackers to log in to certain Alpine Linux and other Muscle-based Linux accounts configured to block password authentication, right? Okay, so these are, as Linux users know, and, um, and other Unixes, if you use an asterisk for the password on an account, it's not a hash, which is normally supposed to be there. It says, no, this is not a user-loginnable account. This is, you know, for system purposes. Not people. So it says configured to block password authentication simply by entering— okay, so I'm sorry, I kind of lost the thread here. A newly disclosed flaw involving OpenSSH and Muscle, dubbed asterisk SSHole, allows attackers to log into certain Alpine Linux and other Muscle-based Linux accounts configured to block password authentication simply by entering an oversized password. As you said, Leo, just keep typing. The flaw only affects OpenSSH servers running on Linux distributions that use the muscle C library, including Alpine Linux, OpenWrt, Buildroot, Yocto, and certain authentication configuration.

Steve Gibson [01:59:31]:
Security researcher Ozgun Kultikin, who discovered and released details on the vulnerability today, says the flaw has existed since 2016 and stems from how OpenSSH handles password verification errors on— Okay. Password verification errors on systems using the muscle-c library. Linux accounts can be configured to prevent password logins by replacing their password hash with an asterisk character in the /etc/shadow file. Because this is not a valid password hash, no password should allow access to those accounts. Makes sense, right? However, a patch introduced in OpenSSH in 2016, so 10 years ago, to fix a username enumeration vulnerability tracked as CVE-2016-6210 changed how OpenSSH handled accounts without usable password hashes to prevent attackers from identifying valid usernames through different response times OpenSSH was modified to perform password hashing even when an account had no usable password hash, including accounts configured with asterisk to block password logins. The problem is that the muscle C library's crypt function, which is what's used to do hashes of passwords, Muscle C library's crypt function also returns an asterisk when password hashing fails, including when a submitted password exceeds its 256-character limit. This means an attacker can submit an oversized password and cause OpenSSH to compare the asterisk returned by the crypt function, which is an error state, against the account's stored asterisk, resulting in a successful login. I rest my case.

Steve Gibson [02:02:07]:
What a wonderful bug. Uh, it is so easy to understand and at the same time so devastating. Bleeping Computer continues writing, to be clear, the flaw does not allow attackers to bypass passwords on accounts with valid password hashes. Kultakin explains that exploitation requires the following conditions. OpenSSH is running on a muscle-based Linux system such as Alpine Linux, OpenWrt, Buildroot, or Yocto, and those various cloud instances. PAM authentication must be disabled, as it is by default in Alpine Linux's OpenSSH server package. SSH password authentication is enabled. At least one account has an asterisk as its password hash, which will typically— which will be typical, and another account has a valid password hash.

Steve Gibson [02:03:08]:
The researcher warns that Alpine's Linux official AWS and Azure cloud images have an affected default Alpine account with passwordless doas privileges, which could allow attackers to gain root access. Systems using glibc, including Debian, Ubuntu, and Fedora, and those using PAM authentication are not vulnerable to this attack. Koltikin says he discovered the vulnerability, of course, using AI agents that ran about 17,600 authentication tests with different OpenSSH configurations, malformed password hashes, and oversized passwords. The vulnerability has been fixed in OpenSSH 10.6p2, and Alpine Linux administrators are advised to update their OpenSSH packages using the, you know, the command apk upgrade openssh. Admins who cannot immediately install the update can mitigate the issue by turning off SSH password authentication with password authentication no. in their SSH server configuration and restarting SSH. Koltikin says admins can also check for signs of exploitation, and this could be important as we'll see, signs of past exploitation by examining SSH authentication logs for password-based logins for accounts that should not allow them. On Alpine Linux, the following command can reveal successful SSH password logins.

Steve Gibson [02:04:55]:
So they just give a simple Linux command, grep accepted password space /var/log/messages. If the log shows a successful password login for the Alpine account, administrators can check whether the account has password authentication disabled. And here they have another grep With, quote, um, uh, I forgot what that's called. The, the little hat.

Leo Laporte [02:05:28]:
The little hat?

Steve Gibson [02:05:29]:
My God.

Leo Laporte [02:05:30]:
What little hat?

Steve Gibson [02:05:32]:
Uh,

Leo Laporte [02:05:33]:
little hat? The siddhi? What?

Steve Gibson [02:05:35]:
Not tilde.

Leo Laporte [02:05:35]:
The circumflex? The

Steve Gibson [02:05:37]:
umlaut? Circumflex.

Leo Laporte [02:05:39]:
Circumflex. The, the triangle hat?

Steve Gibson [02:05:41]:
Yeah.

Leo Laporte [02:05:42]:
Yeah, that's a circumflex.

Steve Gibson [02:05:43]:
Circumflex, yeah. So Circle flat or just Shift+6, folks. Alpine colon close quote, then slash etc slash shadow. He says if the account's password field contains an asterisk, but SSH logs show a successful password login, it could indicate that the vulnerability was exploited. And I would argue it probably absolutely indicates that it was exploited. And I don't know, Leo, if anything prevents clearing, you know, cleaning up the logs. You know, like var/log/messages, you know, classic post-intrusion behavior is to, you know, remove traces of yourself from the log files. So, you know, if you're able to get root, then you could certainly do that.

Leo Laporte [02:06:28]:
Sure.

Steve Gibson [02:06:28]:
Okay. So now we know how this bug that's been presented or that's been present for the past 10 years in these systems happened, like a bizarre, you know, colliding of the planets. Uh, you know, this, this particular C library compiles the crypt function so that it returns an asterisk in an error state, and, and the, and the did the password match happens to just compare whatever the crypt returns with what's in The /etc/shadow file. And if they match, you're logged in, which allows a person to log in to an account that has no password. Amazing. Okay, so now we jump forward from last Thursday to just yesterday, Monday, where Bleeping Computer now picks up the story with what has happened since. And you can guess where this is going.

Leo Laporte [02:07:29]:
Hmm.

Steve Gibson [02:07:29]:
Under the headline, Hackers exploit SSHole OpenSSH flaw to breach Linux systems. So they reported yesterday, hackers are actively exploiting the SSHole vulnerability. And that now has a CVE. It's 2026-123158 in OpenSSH to execute commands steal credentials, and establish persistent access. Multiple cybersecurity firms have confirmed the attacks, reporting that exploitation attempts began on November 5th. That was the day the proof-of-concept exploit became available, with successful exploitation recorded the following day. Successful exploitation, not that it's hard, disclosed by security researcher Ozgun Kultakin. Last week, SSHole allows bypassing authentication in OpenSSH running on certain muscle-based Linux systems, blah blah blah.

Steve Gibson [02:08:32]:
We know all that. Koltikin explained that exploitation requires specific authentication settings. We covered that already. Threat intelligence company GrayNoise reported the first successful exploitation of SSHole in the wild on November 7th at 00:46 UTC, approximately 40 hours after the fix. The researchers logged 16 successful exploitation chains targeting networks protected by GrayNoise from 6 source IP addresses linked to post-exploitation activity. The company says that these attacks are not representative of the broader activity involving SSHole. In the attacks that GrayNoise observed, the threat actor ran system and container reconnaissance, initiated queries to cloud metadata services, attempted to read password hashes and root SSH keys, and tried to modify SSH's authorized_keys files to grant persistent access. Okay, I'll interrupt to note that that makes sense, right? An attacker who could use SSHole to get into a valuable machine and network property would naturally worry that their access might soon be terminated when this bug is fixed.

Steve Gibson [02:10:05]:
So the first thing they would want to do is add their own credentials to the set of valid credentials for SSH and hope that no one notices so that even after the bug is fixed, they'll still be able to return. This is why checking for previous successful exploitation and also checking for any alteration of authentication permissions should absolutely always be part of follow-up remediation. And Leo, you and I, back in the dawn of this podcast, noted that, you know, once you've confirmed that you've had somebody crawling around inside your computer, it's really very difficult to ever trust that machine again.

Leo Laporte [02:10:51]:
No, you can't. Yeah.

Steve Gibson [02:10:52]:
Right. And these days, how do you know where they went in their network after they got in? It's a mess. So Bleeping wrote, one attacker gained root privileges and installed TAC agent, a Python command and control agent. However, in that case, the implant could not reach its command and control server at tac.vpnla.org and never received a task. Analysis of the TAC agent payload shows that the implant supports shell command execution Extensive system reconnaissance, file upload and download operations, and can update itself. Right. It can update itself, but the system can't. Well, that's where we are.

Steve Gibson [02:11:39]:
The agent has no built-in persistence, so the attackers attempt to secure it by configuring a startup service. GrayNoise notes that the implant's comments, logs, and errors were in Chinese, which may be used in conjunction with other evidence to determine the attacker's origin. A finding that suggests possible automated operation is a missing tool check that returns feedback which could help an automated planner revise commands as needed for the attack to proceed. Overall, GrayNoise has recorded 2— I'm sorry, 27.5 million port 22 scans and 20.1 million attempted SSH sessions, though these are not all confirmed SSHole attacks. Sensors from network security company, uh, Providian also confirmed successful SSHole exploitation with telemetry data showing 20 attempts from 13 attacker IP addresses in 9 countries. Offensive security firm Watchtower said on November 6th, the day after the announcement, that it observed SSHole being exploited in attacks associated with botnets and crypto mining activity. System admins should update— no kidding— OpenSSH as soon as possible or disable SSH password authentication on systems affected by SSHole. It is also recommended to check for unexpected successful password logins on accounts whose Etc., shadow password field is asterisk, unauthorized SSH keys, and TAC agent files or startup services.

Steve Gibson [02:13:30]:
Wow. So there is no doubt that systems that did not have the chance to receive, you know, the updates and then update to receive word of the problem and update are being found right now and compromised. I could have wished that the researcher had waited a while longer before publishing and disclosure. He did it the same day as the fix was published, but he did notify them ahead of time. You know, the problem is there's always going to be some lag time from, you know, the notice going out and availability of a patch. And getting it installed and SSH restarted, although it's not as bad as having to bring the whole server down. But, you know, the counterargument that we've acknowledged is that bad guys could also reverse engineer the changes to determine what and how to attack from a patch. So we're back there, you know, with there not really being any great solution to the need for widespread updating.

Steve Gibson [02:14:43]:
And this researcher could not and would never have discovered this once again without the aid of AI. So while both bad guys and good guys can use AI, at least we are seeing many problems, uh, that are old and, and new both being fixed. The other one comment I wanted to make was note that the CVE that was assigned to the original issue 10 years ago Was kind of quaint, right? 2016-6210. The new CVE assigned to SSHole was 2026-123158.

Leo Laporte [02:15:28]:
Wow.

Steve Gibson [02:15:29]:
Yeah. We can be glad that there's no upper limit on the number of CVEs that you can have in one year. And that they reset and start over annually. Otherwise, we'd run out of those too, or we'd have too many digits to count. Wow.

Leo Laporte [02:15:46]:
As soon as I saw this, I was in the Far East. I asked my agents, do any of my devices use Musl? And they said, the only device you have that uses Musl, which is the, I guess, the Linux library that this SSH hole takes advantage of is like my old Denon receiver. And it says, when you get home, just take that off of the internet and you'll be fine.

Steve Gibson [02:16:14]:
But would a Denon receiver be exposing and running?

Leo Laporte [02:16:18]:
No, it's not on the internet, obviously. I mean, it's on the network, but it has no exposed port. So I'm not too worried. But I thought that was kind of interesting that I actually did have a Mucil device because I don't use Alpine Linux. I mean, I mean, it's very common to use Alpine in Docker containers.

Steve Gibson [02:16:36]:
So

Leo Laporte [02:16:36]:
maybe some people do. Yeah.

Steve Gibson [02:16:38]:
Yeah. Yeah. Well, as these, as the security firms saw, they are detecting rapid uptake of this. And why not? It's so trivial. I mean, here, the script kiddies are able to have a field

Leo Laporte [02:16:52]:
day

Steve Gibson [02:16:52]:
without any AI assistance.

Leo Laporte [02:16:56]:
Now, I turn off passwords in all my SSH. It sounds like, though, this would still work even if you were using passwordless or no?

Steve Gibson [02:17:04]:
Yes.

Leo Laporte [02:17:04]:
It does? Yes. That's a little scary.

Steve Gibson [02:17:06]:
Yes.

Leo Laporte [02:17:07]:
It completely bypasses that.

Steve Gibson [02:17:08]:
You need to disable all the password authentication feature, not eliminate the password from the account.

Leo Laporte [02:17:17]:
Okay.

Steve Gibson [02:17:17]:
So maybe you'd be safe if you do, if you turn off all password-based authentication for SSH.

Leo Laporte [02:17:25]:
Yes, I do.

Steve Gibson [02:17:26]:
Yeah. In that case, you would be safe.

Leo Laporte [02:17:28]:
Okay.

Steve Gibson [02:17:28]:
Well,

Leo Laporte [02:17:31]:
I don't have any Musil devices except for my tenant.

Steve Gibson [02:17:33]:
And I too, you and I both use security certificates in order to authenticate ourselves. And I don't even have ports open because I only do that ever from 2 locations. So I am completely IP filtered.

Leo Laporte [02:17:47]:
Yeah. I mean, I was able to SSH into my servers from over from the—

Steve Gibson [02:17:51]:
Well, and Tailscale. Tailscale is the way to go. We talked about it a long time ago when it was still relatively new, and boy, has it seen a great deal of uptake too.

Leo Laporte [02:18:01]:
Yeah, yeah, I love it. Uh, there's an open-source self-hosted one called Head— I think Headscale— that I'm gonna think I'm gonna move to so I'm not reliant on the Tailscale servers. But other than that, yeah. Well, Steve, you've done it again. You've filled us— filled our brains with knowledge, and, uh, we've survived. This is the show we do every Tuesday. You got to listen every Tuesday. Very informative, very interesting.

Leo Laporte [02:18:31]:
If you want to listen, you can tune in and watch it live, actually. We stream every Tuesday right after MacBreak Weekly about 1:30 Pacific, 4:30 Eastern, 20:30 UTC on Kick, x.com, Facebook, LinkedIn, Twitch, and YouTube. Of course, if you're in the club, you can also watch it the Club Twit Discord. After the fact, on-demand versions of the show available at our website, twit.tv/asn, and also at Steve's website, grc.com. In fact, Steve has completely unique versions. He has a 16-kilobit audio version for the bandwidth impaired, a 64-kilobit for those who still don't want to download a giant file but do want good quality. He's got the show notes, which are fantastic, usually 20, 21 pages of goodness. You can read along as you listen.

Leo Laporte [02:19:15]:
He also has transcripts a few days after the show because it's a real human being writing those. All of that at grc.com. While you're there, this would be a good time to sign up for Steve's new products newsletter. There may be something coming in the future from that.

Steve Gibson [02:19:31]:
There will be. And in fact, I'm sure that next week I will have an announcement about to what degree we are close to SpinRite 6.2, which will run UEFI.

Leo Laporte [02:19:43]:
Yep. How exciting. Well, here's what you do. You go to grc.com/email and you can whitelist your email address so you can send him pictures of the week and thoughts and questions and so forth. And that's a good thing to do. But underneath that email form where you put your email address, there are 2 checkboxes, one for the weekly show notes email, but the other for that new products email. Hasn't been very busy lately, might start to get pretty busy in the near future. All of that at GRC.com, plus a lot of other great stuff, including SpinRite, the world's best mass storage maintenance, recovery, and performance-enhancing utility.

Leo Laporte [02:20:16]:
And are you going to continue even with 6.2 to offer free upgrades to everybody who's bought SpinRite? Yeah. You keep doing that? That's awesome. Yeah. That's amazing. Even if you bought it 30 years ago, you get a free upgrade. So GRC.com.

Steve Gibson [02:20:30]:
Yeah. My logic is that it, it died through no fault of theirs. And, you know, because technology has changed, right? And so 6.1 was a catch-up. And, and then UEFI happened, and a lot of people who, like, who had purchased 6.1 a year ago and then said, hey, I, you know, I got a new machine and I can't run it. So I feel it, figure, like, and also because I'm not having to do a lot of work, I'm just having to create a boot environment for I

Leo Laporte [02:21:01]:
love that.

Steve Gibson [02:21:01]:
And Claude is doing all the heavy lifting for me.

Leo Laporte [02:21:05]:
Yes. So we're gonna get you on Local AI soon too. I know you wanna play with that a little bit as well. So very cool. There's some good stuff coming down the pipe any day now from Alibaba and GLM. We will do this show again next Tuesday. I hope you'll join us right after MacBreak Weekly. Steve, have a wonderful week.

Leo Laporte [02:21:24]:
We'll see you next time on Security Now. Bye. Security Now!