“Beware Public Wi-Fi”: When cybersecurity advice gets confusing
Avoiding public Wi-Fi while you are out and about is easier said than done.
Here are some simple precautions that can help.
Nightmare Eclipse – Where next for bug disclosures?
A delightfully provocative discussion of zero-days, bug disclosures, and the very concept of Patch Tuesday.
If the media player above doesn’t work in your browser,
try clicking here to listen in a new browser tab.
Find TALES FROM THE SOC on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app. Or download this episode as an MP3 file and listen offline in any audio or video player.
[FX: PHONE DIALS]
[FX: PHONE RINGS, PICKS UP]
ETHEREAL VOICE. Hello, caller.
Get ready for TALES FROM THE SOC.
[FX: DRAMATIC CHORD]
DUCK. Welcome back, everybody, to TALES FROM THE SOC.
I am Paul Ducklin, joined as usual by David Emerson, CTO and Head of Operations at SolCyber.
Hello, David.
DAVID. Hey, there.
DUCK. David, let’s get straight into this, because there’s a lot of exciting and intriguing stuff to talk about.
The topic for this episode is Nightmare Eclipse – Where Next for Bug Disclosures?
DAVID. Nightmare Eclipse is not just photographing the eclipse through a colander, in which you have 700 mini-eclipses taking place in every pinhole?
DUCK. [LAUGHS] I did that, and it’s very good low-tech fun.
I wouldn’t call it a nightmare – and you’re always looking away from the sun, so there is no risk to your retina.
DAVID. Right. [LAUGHS]
DUCK. But in this case, there’s a risk to the safety of your data, the integrity of your system, and certainly risk to you if you’re a Microsoft developer, right?
DAVID. Nightmare Eclipse is a security researcher, an anonymous security researcher, who’s published, I think, 10 or so zero-days.
If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.
Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
DUCK. Yes, over five months – April, May, June, July, and August of 2026.
DAVID. Yes.
DUCK. But the reason for them doing them in batches monthly is very, very carefully chosen, isn’t it?
DAVID. Well, yes.
They’ve been coming out on the Wednesdays after Patch Tuesday!
DUCK. [LAUGHS VERY LOUDLY]
[STAGE WHISPER] I shouldn’t laugh!
DAVID. Which actually I like.
Because I always, and I mean always, really ever since the early 2000s when I started working in tech․․․ I have always thought Patch Tuesday was dumb.
It is a fiction.
And this researcher has decided to call us out on that fiction, which I think is totally rational.
DUCK. I get the point that, at least in the old days, if you were a sysadmin or an IT person, or you were in some kind of besuited management role, you kind-of liked the idea of being able to plan ahead for changes.
But we’re not talking about new versions of software; new features.
When it comes to Patch Tuesday, we’re talking about, in some cases, fixes that you have had to wait up to 30 days more for than you would have if they just came out when they were first available.
How can that be healthy?
DAVID. Yes, it’s always been stodgy.
I think maybe I was…
DUCK. [LAUGHING] Stodgy?
That’s a good word – hard to digest.
DAVID. [LAUGHS] By the time I was besuited, as you put it, it was just too late.
The reality is that it’s been stodgy in my mind for a really long time.
And I think that it would have been healthier to get the industry accustomed to regular rolling releases.
Patch Tuesday might still be a thing – like, there’s a reason to have some kind of average predictability, and maintenance windows, among a company.
But to push that as an industry, to push that as a vendor, in my mind, is just irrelevant.
It just is really silly to say, “Patch Tuesday is the day on which we will make our releases of fixes to critical functionality or vulnerability.”
DUCK. It’s almost inviting Zero-Day Wednesday, isn’t it?
DAVID. Yes, and here’s the day on which you can release your worst exploits! [LAUGHS] It is Wednesday․․․
DUCK. It seems an irony that we now have this special term out-of-band patch to describe patches that are considered so important that they do get pushed out without waiting for the next month to come round.
And those are treated as though they’re somehow amazingly special, and terribly complicated and hard to do.
And yet, when you look at a lot of very well-known and widely-used Linux distros that follow a rolling release model, that’s how they do all their patches, and the wheels very, very rarely come off.
DAVID. There probably are reasons, as I said, not to roll patches out on a rolling basis, without any particular cadence, to your infrastructure, as an individual.
But that’s your sensibility; that’s your infrastructure setting its own cadence for patching, and for upgrading, and hotfixes, and whatnot.
And I really think that that is distinct from expecting a vendor to set that cadence for an industry, which is why I think the Microsoft model is so silly, frankly.
Because patches should be rolling, in my estimation, and it should thereby force users of that software, of that ecosystem, to consider their own cadence.
For my personal computer, I do not require cadence – I will apply the patch as soon as it’s released.
For a production-critical server, maybe I’m going to wait until a non-critical time, or maybe I will read the patch and assess on an individual basis – that’s my decision to make.
That isn’t, in my estimation, an industry-level decision.
DUCK. Ah, I see what you’re saying.
You’re not suggesting that everybody should feel compelled to apply every patch within instants of it arriving.
But that they should have the choice to do so if they wish, particularly if they reach an informed decision that one particular vulnerability might expose them more than any other.
DAVID. Right.
I think that setting Patch Tuesday at an industry or at an ecosystem level, which is what Microsoft has done․․․
I don’t believe that it’s a problem if a user wants to patch only on one Tuesday a month.
That’s totally their prerogative.
I do think that it is a poor behavioral standard to say, “Patches are a monthly thing.”
That doesn’t make sense to me, and I don’t think it’s healthy in 2026.
It wasn’t healthy in 2005!
It’s not healthy in 2026 to be pretending as though patches are a monthly occasion.
DUCK. It’s possible, even if you’re supporting millions or tens of millions of customers, to work to a rolling patch model .
DAVID. Yes, I think it builds good habits.
I think it’s a practice that is healthy for everyone to be self-actualized when it comes to fixing things, and have an understanding that these things are under pressure at all times.
This would be easier if we were talking about plumbing.
There isn’t a Plumbing Rupture Tuesday once a month [LAUGHTER], where, if it’s going to happen, you can expect all the plumbing in your house to explode.
No, it’s under pressure 24/7/365, and at some point, something will rupture.
And it’s not going to be on a Tuesday, necessarily.
DUCK. It’s almost certainly going to be on a Sunday, isn’t it?
Maybe at about 15 o’clock?
DAVID. Almost certainly – that’s exactly when it’s going to be. [LAUGHS]
As much as the rupture will not happen on schedule, your prophylaxis should not be happening on schedule.
Your prophylaxis should be informed by the risk, which is exactly how you do cybersecurity, right?
DUCK. Yes.
DAVID. Your infrastructure administration practices should all be informed by risk, not by some arbitrary schedule.
Anyway, Nightmare Eclipse picks at that a bit.
DUCK. And some of these vulnerabilities were clearly designed to put Microsoft into the worst possible light, weren’t they?
Because several of them have specifically targeted Microsoft Defender.
DAVID. Defender is an inevitable target.
It has to move quickly because it itself needs to regularly keep up with vulnerabilities; it has SYSTEM [full local control], which is obviously high privilege; it’s ubiquitous.
I think pretty much every Microsoft system has Defender on it.
Even if it’s not actually active and protecting, the code is there.
So I think it’s probably a pretty good common denominator if you’re going to attack something.
DUCK. The Nightmare Eclipse story has a truly weird side to it, doesn’t it?
Because I believe the reason this all started, back in April 2026, is that Nightmare Eclipse submitted a bug report, a vulnerability, to Microsoft.
And Microsoft came back and said, “No, we’re not accepting that. You have to make a video that shows us the thing working.”
And Nightmare Eclipse said, “I’m not going to do that. I’ve given you the information.”
“If you consider the vulnerability to be non-existent until I produce a video, then clearly you will have no possible objection if I release it to everybody without the video, because then they’ll be in the same position as you.”
I believe that’s how all of this started.
Nightmare Eclipse sort-of, to be fair, threw their toys out of the cot.
DAVID. [LAUGHS]
DUCK. And Microsoft didn’t respond very well over the next couple of months, did they?
DAVID. They threatened prosecution, so everyone was throwing their toys out of the cot! [LAUGHS]
That’s just mob tactics.
I think that the community responds to it poorly because it implies that this could happen to anybody, regardless of the legitimacy of their intent in their research.
And that really is a bit of a damper!
DUCK. Yes, it is.
DAVID. If you’re a legitimate researcher, and you just want to submit something, it’s a bit of a damper if Microsoft is occasionally going to threaten you with something vague, and “in reserve” for them to prosecute you, potentially.
That’s ridiculous.
That just isn’t how the world works, in my opinion.
I mean, it is how the world works in some ways, [LAUGHS] but it is not how we should be viewing security research.
DUCK. If everybody gets the information at the same time, in what’s called full disclosure, even if it unavoidably helps the cybercrooks in some way․․․ that completely removes any suggestions of favoritism; any suggestions of manipulating the truth.
Although I see the point of not doing it, and I don’t really totally like it myself, I don’t think it’s the unspeakably evil thing that some people suggest.
Would you agree with that?
DAVID. I think that there are many, many ways to behave, and many ways to disclose a bug.
And I don’t think Microsoft is in control of either of those things.
I don’t think anyone is obligated to tell Microsoft about things that they have found.
I don’t think anyone’s obligated to alert Microsoft before publishing a bug in its software, and I don’t think anyone’s obligated to ensure that their exploits work 100%.
And Microsoft’s going to have to navigate that freedom, because that freedom could potentially open up a lot of free labor on the part of the community to help Microsoft’s products get better.
DUCK. Particularly with assistance from AI that can speed things up, right?
DAVID. Yes, absolutely.
DUCK. Even if it’s often wrong, the ill-formed bug reports that people are blaming AI for will presumably begin to dry up over time, as (A) people learn to use the tools better, (B) the tools get better, and (C) as these ill-formed bugs either get removed from the product or fixed anyway.
DAVID. Right, but I see that as a separate discussion.
It is related, but it’s a separate discussion from the main thread that we’re talking about here, which is that there are many ways to report a bug.
There are many ways to also be wrong, and Microsoft is acting as though there’s some obligation that reports be done a certain way, and that they be fully-formed in a certain way.
And if they’re not these things then Microsoft can sue․․․ none of that adds up.
It makes no sense at all.
This individual, if they wanted to, could have sold this to a criminal organization or a state, a nation state, or could have kept it for themselves.
All of those things are entirely possible.
In fact, there’s another element to this story, which I think doubles down on some of the lunacy, which is that it was originally posted on [Microsoft’s] GitHub.
They shut it down, and the individual went to GitLab.
Then GitLab shut it down, because they were aghast, and now it’s self-hosted now on Gitea, and that is just the nature of things.
This is not stoppable.
It’s more popular than ever because of the resistance to the release.
This person’s being a child, let’s be really clear: Nightmare Eclipse is being a bit of a child․․․
DUCK. Yes.
DAVID. ․․․but it’s really good that the public understand, and that Microsoft, I think, learn a lesson, that the world is a big place, and there are many ways to be like a child.
And you’re not going to stop the release of this bug by whacking the mole.
It’s going to pop up elsewhere.
You need to actually fix the fundamental problem, which is your software, not people who are children in the world.
DUCK. Particularly when you look at the trouble we’ve had with organizations trying to hide bugs, or keep them to themselves, in the past.
And the classic example is ETERNALBLUE, isn’t it?
Which was, I believe, a vulnerability, an exploit, created by the NSA.
Even if you know all the jargon yourself, Amos helps you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
They kind-of hoped no one else would find out about it, or discover it independently.
Which was true – nobody else did discover it.
But the NSA itself got breached (was it Shadow Brokers who stole it?), and then it got leaked into the wild.
And then we had the WannaCry virus, if you don’t mind.
So it’s quite clear that when everybody knows about a problem right away, for a problem that’s sitting there latent, particularly in closed-source software, that we should all benefit more than we’re thrown into risk.
DAVID. As an open-source enthusiast, I agree with you.
DUCK. You’re allowed to say “zealot,” David.
DAVID. Zealot! [LAUGHTER]
DUCK. You give money to OpenBSD․․․
DAVID. I do, I do.
DUCK. It’s not zealotry in a bad way.
It’s just the fact that you think that there’s a place for openness, so that nobody can sweep things under the carpet or put in features that people didn’t expect and didn’t want.
DAVID. Yes, openness is resilient to exactly this paradigm.
DUCK. Yes.
DAVID. So, what you’re describing doesn’t really matter to an open community as much.
Well, first off, their code is inspectable.
They’re not really expecting that sort of internal secrecy at which point, “OK, internal secrecy now releases this to the world.”
That’s where you get something like a Patch Tuesday.
Also, they’re not trying to profit, which is partly why Microsoft would have something to gain from sequestering knowledge, or from ensuring that things remain closed.
So, it’s a tough call to say that one or the other is the only way to be, but I don’t think Microsoft can be surprised that the world doesn’t care about its profit.
And that’s really the discussion here.
I think what’s happening is Microsoft is acting in a very closed-source, for-profit manner, which is understandable given who they are․․․
․․․and then simultaneously being surprised that not all of the world is interested in protecting its interests.
So I think they’re going to have to find some way to navigate those two things – making a profit, and remaining open to the possibility that the world moves differently.
I don’t necessarily think AI facilitates this discussion, in the sense that it always was a problem.
But I do think that AI adds pressure to addressing this, because things can move faster now than ever.
And the likelihood of there being a full disclosure, regardless of what Microsoft wants, is just greater every minute than it used to be.
DUCK. Would you agree that, historically, we have a precedent that shows that when somebody comes up with a new and automatic way of finding bugs at a much bigger scale than we thought of before, that we are generally able to react positively without panicking?
Based on what happened when fuzzing first became practicable at huge scale?
Even if you know all the jargon yourself, Amos helps you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
There were people at the time that panicked, but others who said, “This is great.”
“We can now use these tools ourselves, and we can actually detect whole classes of bugs, and we can look at things that have probably been copied-and-pasted or baked in across our software because of the errors of history, and we can go and fix them at scale.”
So, we won the battle last time.
Why shouldn’t we do it again?
DAVID. There’s no reason – this is very similar.
I think that is a precedent that will change how we work.
The advent of inexpensive static analysis changed how programs were shaped, and, to this day, we are now capable of writing more complicated programs without fear that they would also become a liability due to their complication.
We are capable of addressing liabilities that we have baked into any program, regardless of its level of complication.
Software quality was raised across the board as a result of the availability of static analysis, and fuzzing, cheaply.
You’ll see that with AI as well.
It may take a slightly different form, like maybe the rate at which we fix things increases, and therefore people aren’t concerned about tech debt as much, or aren’t concerned about vulnerability as much because they know they can fix it in five minutes.
That might be one form this would take.
DUCK. That would be a little bit regrettable, right?
Because if you can fix it in five minutes, why don’t you wait those five minutes and then fix it before you ship?
DAVID. Well, many reasons, but yes. [LAUGHTER]
DUCK. Many of them have dollar signs stuck onto them, I suppose?
DAVID. Yes, exactly.
All of them have dollar signs. [LAUGHTER]
It’s not that I’m proposing this be a preferred way of operating.
I’m just acknowledging that it isn’t as scary in 2026 to say, “OK, we need to add this thing now because it’s a serious problem. We overlooked it. Isn’t it scary?”
Get your agent on that – it’ll get done in 10 minutes.
The world has changed in a way that does allow you to shoot from the hip, sometimes, a little bit more than you used to be able to.
DUCK. Well, you’ve always been able to shoot from the hip.
I guess you’re less likely to get yourself in the thigh, or the shin, or the foot.
DAVID. Or if you do, you can patch it up even faster. [LAUGHTER]
DUCK. Yes, there’s always an ambulance on standby.
DAVID. Yes. [LAUGHS]
And then the other way – and this is more positive – is the volume has increased.
The volume of activity; the volume of new development; the volume of discovery of vulnerabilities; the volume of deficiency reports․․․
․․․all of these things are increasing in a way that basically robs you of the ability to do what software developers or architects 15 years ago would advocate.
Thoughtful design; planned, waterfall types of implementation – all of these things are just not going to be.
DUCK. We don’t have to be quite so, “Let’s regulate the river in a series of weirs.”
We can have rapids here and there, and it will be OK.
DAVID. Exactly.
Taking advantage of these characteristics of AI, I think, will enable us to harness it into a benefit, like we did with static analysis, or fuzzing, or any of these other changes that really raised the bar on quality across the board.
Because it increased the ability to find these things; to report these things.
And it seemed problematic at first.
It seemed like we couldn’t ever possibly address 700 memory leaks, but you actually can.
And maybe, if you can’t address 700 individual memory leaks, you can trace, through greater maturity of the toolset, their origin.
Or you can use Rust, because it doesn’t have the same problem.
There are many different influences that would cause people to adapt to the new world, but I think this is just one of those moments that we’re in.
Even if you know all the jargon yourself, Amos helps you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
DUCK. And one of the approaches that the Linux community seems to be taking, which I applaud a lot because I’ve always liked the idea of programmers who write negative kilolines (KLoCs) of code․․․ in other words, they remove stuff that is genuinely no longer necessary, or useful, or desirable in the product, rather than trying to fix it.
The Linux community has started to adopt that approach, haven’t they?
So that when AI finds a whole load of vulnerabilities in some ancient driver, they’re going, “Well, let’s just take all of that code out and no longer ship it.”
I think that’s a great solution.
But I’m starting to see, particularly on social media, people going, “How dare they?”
“What they’re doing is they’re saying, ‘Well, AI has found flaws in our product,’ so we’re going to respond by just ripping out the bits that are broken instead of fixing them.”
DAVID. I don’t think removing code is a cop-out.
I think removing code is what should be happening.
I think you don’t see it as much in for-profit for two reasons.
One, nobody ever got promotion for fixing bugs – what’s visible is new features.
And so there’s this treadmill, essentially: “Always more; always more.”
DUCK. Yes.
DAVID. No one’s going to get promoted for cutting the code base down.
DUCK. Yes, and that harks back to the 1970s, doesn’t it, when companies like IBM actually measured your productivity by how many KLoCs, kilolines, of code you produced?
It almost incentivized writing code that was inefficient, and bloated, and had features that nobody needed.
And then other people have argued that when Agile programming came along, and Kanban, and there are all these little feature stories that programmers are expected to peel off the whiteboard and go and implement․․․
․․․you wouldn’t be rewarded if you said, “I’m going to take that one off the board and put it through the shredder, and never implement it, because it’s a damnfool idea.” [LAUGHS]
It was always a question of, “Oh, that looks like an easy one – I’ll add that feature and get my brownie points.”
DAVID. Yes, exactly.
DUCK. And that’s sort-of the wrong way of looking at things, isn’t it?
DAVID. You know, [adding code all the time] isn’t exclusively the domain of for-profit companies.
Apple is famous for doing this as well – they break backward compatibility all the time.
They deprecate features all the time, not to the extent that the open source community has latitude to do so, because, of course, Apple is trying to make a profit and they’re not trying to be a chaotic ecosystem for their customers.
But Microsoft is one of the stodgiest in this regard. [LAUGHTER]
It does, I believe, hold them back, in a security sense and in a functionality sense, because they’re always trying to maintain backward compatibility, almost to a fault.
DUCK. Yes, a great example there, David, is things like NTLM [NT LAN Manager] authentication, which is known to be at grave risk of things like pass-the-hash attacks.
That’s where the password is converted into a hash, and the hash is stored and then it’s used over, and over, and over.
Even if you know all the jargon yourself, Amos helps you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
Microsoft hates people using NTLM, and they tell you, “This is deprecated – get rid of it!”
And then, in small print underneath, “Oh, by the way, in most networks, we have to be honest, probably some things will break, so it might be harder than you think.”
They’re trying to have their cake and eat it there, aren’t they?
DAVID. They absolutely are.
If you were to translate that to an open-source line of thought, open-source LAN Manager would have gone away, I don’t know, decades ago.
And if Apple ran LAN Manager, it would have gone away years ago.
Everybody is faster than Microsoft.
I really do think it’s worth calling out that there is something to be said for the mentality that things don’t always need to get more crazy and more featureful.
It is absolutely healthy to prune, when the effort [of keeping old code or adding more] would just be in excess of the benefit.
DUCK. And then you won’t have to rush out and buy a 32GB or a 64GB laptop, just to do the same sort of tasks that you did 10 years ago with 8GB or 4GB or even 2GB.
DAVID. Well, yes, the hardware burden is real.
DUCK. Yes.
DAVID. But in this context, it’s a security burden.
“Evermore” is a security burden that companies sometimes get away with, by sheer luck, for long periods of time.
But nonetheless, it is an exposure.
DUCK. David, I’m conscious of time.
This has been a fascinating discussion so far, but I’d like to finish up by asking you that if you could persuade the community at large to adopt one change into bug disclosure and response, what would that be?
DAVID. Break your mind.
Stop assuming it will happen in any particular form; stop assuming that people are going to follow any form of disclosure.
There are many ways to disclose something.
You may have an ideal way in your mind, and that’s OK, but you cannot have that to the exclusion of all other ways.
So, you should behave accordingly.
Make sure that the product that you’re developing, regardless of its profitability status, or licensing, or whatnot․․․
Make sure that it is able to adjust to the very many ways of disclosing a bug, and not only to bugs that are validated and disclosed responsibly according to your whim.
That is not the only way to be.
So I think: Break your mind, and assume that all things could potentially happen.
And you’ll probably use that as inspiration to change your ways, when it comes to adapting.
DUCK. And don’t refuse to listen to someone just because they won’t make a screencast video like you want them to. [LAUGHS]
DAVID. That’s part of acknowledging there are many ways to be!
DUCK. Yes, indeed.
Thank you, David.
It’s great to hear you talking about all sides of this problem – the social side; the environmental side; the practical side.
It isn’t something that you could just cast into law and have strict rules, because there will always be exceptions and new ways of dealing with the problem.
Perhaps we should revisit it in a future podcast, because I feel like we’ve only scratched the surface.
DAVID. Well, no doubt this is not ending anytime soon, so we’ll probably have a few more Patch Tuesdays. [LAUGHTER]
DUCK. Yes, you’re quite right.
So, thanks to everybody who tuned in and listened.
If you enjoy this podcast, please like and share, and recommend us on social media.
If you listen on a podcast feed, please leave a review, and please leave a comment.
Tell your friends, your family, your colleagues, and most especially your boss about us.
There are great things you can learn from the TALES FROM THE SOC podcast, without being forced to listen to much (or in most episodes, any) sales schpiel.
And please take a look at https://solcyber.com/blog.
I’ll put in the show notes a whole load of articles where you can trace the evolution of the Nightmare Eclipse nightmare.
Until next time, stay secure.
DAVID. Bye everyone.
[FX: CALL ENDS]
Catch up now, or subscribe to find out about new episodes as soon as they come out. Find us on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app.
Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!
Avoiding public Wi-Fi while you are out and about is easier said than done.
Here are some simple precautions that can help.
Why does it sometimes sound as though no one ever thought of using AI in cybersecurity until now?
Even if you’ve got cybersecurity covered in your own digital life, remember that friends don’t let friends get scammed!
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
