The Vulnerability Is Real. Now Prove Your Organization Can Handle It.

Let’s say it’s Tuesday morning.

Maybe even this Tuesday.

8:07 a.m. Your phone rings.

Nothing is wrong at the plant. At least, nothing anyone can see.

The water is running. The operators are mid-shift, coffee going cold beside the HMI screens, working through the same morning checks they ran yesterday and the day before. No alarms. No ransom note splashed across a workstation. No reporter on line two, no frantic text from the mayor’s office.

By every visible measure, this is the most ordinary Tuesday you’ve had all year.

Then the voice on the other end says one sentence.

“We need to know whether this vulnerability exists anywhere in your environment.”

Okay. What vulnerability?

They give you a name that sounds like a license plate. CVE-2026-5194.

Never heard of it? Fair enough. Most people haven’t.

It lives in something called wolfSSL, which probably doesn’t help either, so let me translate. wolfSSL is a small, efficient cryptographic library: a chunk of code device makers build into their products so those devices can confirm who they’re talking to and keep the conversation private. It was built for tight spaces like embedded systems, IoT devices, and the little computers hiding inside bigger machines. Anthropic says it’s used by billions of devices worldwide.

The flaw sat in the part of that code that checks whether a digital certificate is genuine. Under the right conditions, an attacker could forge a certificate and the device would accept it as real. Picture a bouncer who checks every ID, every night, and still waves the perfect fake right through the door.

wolfSSL rated it critical. A fix shipped in April.

So we found the problem. There’s a fix. Patch it.

Right?

Not so fast.

Before anybody can fix anything, somebody has to answer a much simpler question.

Do we have it?

And just like that, Tuesday morning gets interesting.

Rewind to May

If you’ve been following this Rabbit Hole, you already know who found it.

Anthropic’s researchers caught the wolfSSL flaw using Claude Mythos Preview, the frontier model at the center of Project Glasswing. Glasswing is the program Anthropic built to put that model in the hands of trusted defenders first, so they could harden the world’s most important software before comparable capabilities become easy for attackers to get.

On May 22, Anthropic published its first update on the program and used wolfSSL as one of its examples. The bigger numbers came with it: roughly 50 partners, about a month of work, and more than ten thousand high- or critical-severity vulnerabilities found. Several partners said their rate of finding bugs had jumped more than tenfold.

Eleven days later, Anthropic announced it was opening Glasswing to roughly 150 more organizations in more than 15 countries, most of them providing critical infrastructure to many others. It even named the industries its first group had been missing.

Power. Healthcare. Communications.

Water.

That’s the headline people remember. AI can find vulnerabilities at a scale we’ve never seen.

It wasn’t the line that kept me up at night, though. This was: Anthropic wrote that software security used to be limited by how quickly defenders could find vulnerabilities, and that now it’s limited by how quickly they “can verify, disclose, and patch” what AI uncovers.

A little further down sat a detail I still can’t shake. Some open-source maintainers, the people who actually write the fixes, asked Anthropic to slow down its disclosures. They needed more time to build patches.

The people fixing the problems asked the people finding them to please ease up.

That isn’t really a story about AI. It’s a story about what happens after AI does its job.

And it sent me straight back to the utility.

8:31 a.m. | KNOW

So, back to Tuesday. The fix exists. The question is simple.

“Do we use wolfSSL?”

Nobody in the room knows.

“Is it in SCADA?”

Maybe.

“Could it be embedded in a device? A PLC, a radio, a gateway?”

Possibly.

“What about the remote-access equipment?”

We’d have to check.

“Which vendor would know?”

Good question.

“Which version are we running?”

Another good question.

“Who can tell us?”

And there it is. Six questions in, and we haven’t touched the vulnerability. We don’t even know whether we’re vulnerable.

This is where it stopped being a cybersecurity story for me, because nobody in that room is incompetent. IT knows its systems. Operations knows the plant better than anyone alive. The SCADA integrator knows one piece of the control environment and the MSP knows another. The equipment vendor knows its own box, cybersecurity understands the flaw, and leadership feels the full weight of being responsible for a community’s water. Every one of them can be doing excellent work, and the organization can still be stuck on a question a child could ask.

Do we have this?

To be precise, I’m not saying CVE-2026-5194 has been found inside a water treatment plant, and I’m not saying your utility runs wolfSSL. I haven’t seen evidence of either. The uncomfortable question is whether yours could tell you either way.

In Part IV, I introduced the five words beneath WaterReady:

KNOW → ORGANIZE → IMPROVE → PROVE → MAINTAIN

Simple words. Tuesday morning makes them heavy. Start with the first one.

Of course you know your environment. You have an asset list. You know what you bought, who your vendors are, and which systems keep the plant running. But that isn’t what Tuesday is asking. Tuesday wants to know what’s running inside those systems. Which firmware. Which software libraries, which versions, which dependencies. Which remote connections, and which systems quietly lean on other systems to work.

Could you answer that today?

Could you answer it before lunch?

For part of that answer, there’s a document worth knowing about: a software bill of materials, or SBOM. Think of it as an ingredients label for software. It can tell you which software components and dependencies were built into a product. Which raises a question worth bringing to your next staff meeting: has anyone ever asked your vendors for one?

And this is where wolfSSL turns out to be a perfect teacher. wolfSSL fixed its code in April. But a utility doesn’t usually run wolfSSL the way it runs Microsoft Office. If it’s in your environment at all, it could be buried inside a device or another product you know by a completely different name. And in that case, the fix doesn’t reach you until that product’s maker builds it into new firmware or an update and gets it to you. Anthropic itself has warned about this gap: the long lag between a flaw being found, a patch being written, and that patch actually landing on the equipment people depend on.

So “there’s a fix” and “your equipment is fixed” are two very different sentences. Sometimes they’re months apart. Sometimes the second one never arrives at all.

If you can’t establish whether the flaw lives in your environment, you aren’t at remediation yet.

You’re still at KNOW.

10:15 a.m. | ORGANIZE

Say the answer comes back by mid-morning.

Yes. Somewhere inside a system that matters, the vulnerable component exists.

Now we patch. Right?

Maybe. But first somebody has to own the decision, and that’s usually the moment a room goes quiet.

Who owns it? Cybersecurity? Operations? IT? The utility director? The general manager? The vendor, the integrator, the MSP?

Who has the authority to say, out loud, “We are making this change”? Who has to be consulted first? Who understands what happens to treatment if this system goes down, and who understands what happens if it stays exposed? Who does the work? Who can stop it? And if the utility decides to wait, whose name sits next to that risk?

I’d run a simple experiment. I’d pull five people aside, one at a time, and ask each of them those exact questions.

Would they give me the same answers?

That’s ORGANIZE. Not boxes on an org chart, but authority, ownership, escalation, and a decision path everyone already knows, so nobody is inventing it for the first time at 10:15 on a Tuesday with a critical CVE written on the whiteboard.

1:40 p.m. | IMPROVE

The decision lands on a desk, and now the real weighing begins. The cybersecurity answer may be obvious. The operational answer rarely is.

Does the system need to come offline? Can it? What process does it support, and what else depends on it? Does the vendor even have patched firmware yet, and will they support it on your configuration? Will the software sitting on top keep working? Does your contract let you make the change, or does the integrator have to? Has anyone tested it? Is there a backup, and has anybody actually restored from that backup, ever? What happens if the fix fails halfway through? What happens if you wait?

There’s a line from Part IV I keep coming back to. A technically correct fix can still become an operationally wrong decision.

The plant doesn’t pause because cybersecurity found the answer. Water still has to be treated. Chemical feeds still have to run. Operators still carry their responsibilities, and the families at the end of the pipe never stop turning on the tap. Someone has to decide whether the cyber risk of waiting outweighs the operational risk of acting.

The CVE can’t make that call. It has never seen your plant.

Sometimes IMPROVE doesn’t even mean patching. If the vendor hasn’t shipped a fix, improving means shrinking the danger while you wait: tightening who and what can reach that device, cutting connections it doesn’t need, and watching it more closely than you did yesterday. Anthropic’s own guidance to network defenders points the same direction, toward basic controls that keep protecting you even when a patch is late.

But let’s say this one goes well. The vendor has firmware. The integrator is available. Operations finds a safe window. Cybersecurity defines exactly what has to change. The backup is confirmed. The work happens, and everything comes back up. No alarms. No disruption.

Everybody exhales.

Done. Right?

Not yet.

Six Months Later | PROVE

Fast-forward to spring. A conference room with bad coffee. On the table sits a cyber insurance renewal questionnaire. Or maybe it’s an auditor, or a state regulator, or a new board member who read about AI-found vulnerabilities over the weekend. The question is polite, and it’s devastating.

“Can you show me?”

Show me every affected device was addressed. Show me the second site wasn’t missed. Show me the firmware actually installed, that a configuration didn’t quietly roll back after a reboot, and that the change didn’t open a new problem somewhere else. Show me who validated it, when, and where that evidence lives.

Now show me again, assuming the person who did the work left in January.

This is the moment a dangerous sentence surfaces in organizations everywhere.

“I thought we fixed that.”

The utility thought the vendor handled it. The vendor thought the integrator handled it. The integrator closed their work order. Cybersecurity closed the ticket. Operations remembers something being done, sometime last fall.

And nobody can produce the evidence.

That isn’t closure. That’s memory. Memory won’t satisfy an insurer. It won’t satisfy a regulator. And it will do you no favors in a deposition.

That’s PROVE.

The Next Tuesday | MAINTAIN

Then comes the word I think organizations underestimate most.

Tuesday morning is going to happen again. Maybe not with wolfSSL. Maybe not through Glasswing. But something else will surface: a library, a device, a credential, a remote-access pathway, a vendor dependency, a configuration nobody has touched since the day it was installed.

The names will change. So will the people. Vendors will rotate, budgets will reset, leadership will turn over, someone will install something new, and something old will stay plugged in far longer than anyone intended.

Readiness can’t depend on everybody remembering what happened last time. The organization has to be able to do this again, and again, with different people in the chairs.

That’s MAINTAIN. Fixing one vulnerability is a win. Still knowing exactly what to do when the next one shows up is the whole game.

The Test

That’s when the five words stopped looking like a framework to me.

They started looking like a test.

KNOW. Can you determine whether the risk is yours?

ORGANIZE. Do the right people know who owns the decision?

IMPROVE. Can you safely do something about it, even before the patch arrives?

PROVE. Can you demonstrate that the problem was actually closed?

MAINTAIN. Can you do it all again when the next finding lands?

Now notice what never happened in our Tuesday story. Nobody attacked the plant. No ransomware, no tampering, nothing exploded, nothing even stopped working. All that happened was this: somebody told the organization that something might be vulnerable.

That alone was enough to test every system standing behind the technology.

For years, the cybersecurity conversation has centered on finding problems. Assessments find them. Scanners, penetration testers, and auditors find them. Now AI finds them faster than most of us imagined possible, and that’s good news. We want defenders getting better at this.

But Glasswing is quietly telling us the hard question has moved. It used to be, “Can we find the vulnerability?” Now it’s, “Can the organization absorb the finding and turn it into action?”

So go ahead and ask your organization the usual questions. Do you have an incident response plan? Yes. An ERP? Yes. Assessments, vendors, an MSP, cybersecurity support? Yes, yes, yes, and yes.

Good.

Now it’s 8:07 a.m., and a critical vulnerability may be sitting inside your operational environment.

Show me what happens next. Not what the policy says should happen. What actually happens.

A plan tells you what’s supposed to happen. Readiness tells you whether your organization can make it happen.

The Thought I Couldn’t Shake

I thought that’s where this part of the Rabbit Hole ended.

I was wrong.

While I was picturing one utility wrestling with one vulnerability, something much bigger started nagging at me.

Remember those maintainers who asked for more time?

Our Tuesday was one finding. One phone call. One utility working out what it owns, who decides, how to fix it safely, and how to prove it. We got through it. Eventually.

Glasswing’s partners didn’t find one. They found more than ten thousand. And back in June, Anthropic said it expects other AI companies to have models this capable within six to twelve months, possibly released without the safeguards that keep them out of attackers’ hands.

So what happens when Tuesday doesn’t bring one finding, but fifty? What happens when machines can find weaknesses faster than utilities can investigate them, faster than vendors can ship firmware, faster than budgets can fund the fix, faster than leadership can decide what happens next?

What happens when the vulnerability is no longer the bottleneck?

Then the uncomfortable thought hit me. Maybe Part IV wasn’t quite right. Maybe AI isn’t simply moving faster than organizations can decide. Maybe we’re heading toward something much bigger than decision latency, and the entire cybersecurity equation is about to flip.

For most of the history of cyber defense, we’ve lived with one quiet assumption: there will always be more problems hiding than we can find.

What happens when that stops being true?

What happens when the machine finds them faster than we can fix them?

That’s where I’m going next.

Part VI: What Happens When Finding the Vulnerability Is No Longer the Hard Part?

I think that’s where this Rabbit Hole finally ends.

Unless what I find down there changes the question again.