How the CVEs Were Discovered: A Methodical Approach to Finding Vulnerabilities

In my last blog I covered the four Windows client CVEs HiveForce Labs contributed to October 2026's record Patch Tuesday: what they are, what they lead to, and how to protect yourself. A lot of people then asked me the same question: how did you actually find them? This post is my answer.

So why OpenSSH for Windows in the first place? Honestly, curiosity. It ships with Windows, it sits on machines in almost every organization, and I use it myself every single day. Something that common and that trusted made me wonder: who is actually checking the Windows-specific parts of it?

Why method matters more than luck

It is tempting to think vulnerability research runs on flashes of genius. In my experience it runs on a method. Modern targets have a huge attack surface, and if you go in without a plan you can hunt for weeks and come out with nothing.

If you work in a SOC, this will sound familiar. Hypothesis-based threat hunting starts with an idea, like "an attacker may be abusing this tool", and then goes looking for evidence that proves or disproves it. Hypothesis-based vulnerability hunting works the same way. You start with a simple idea about how a program might be too trusting, like "this download tool probably believes whatever file names the server sends it" or "this archive tool probably assumes every archive is harmless". Then you go and prove it or kill it. Just like in threat hunting, it beats wandering around hoping something jumps out at you.

A targeted approach changes that. You decide where to look, you decide what kind of mistake you are hunting for, and you have a repeatable way to prove or kill each idea quickly. That last part matters most. Most ideas are wrong, and the faster you find out, the faster you get to the one that is right.

Bug or vulnerability?

“Not every bug is a vulnerability, and learning to tell them apart saves a lot of time.”

A bug is code doing the wrong thing. A vulnerability is a bug an attacker can reach and use to get something they should not have, like running code, writing files, reading data or knocking over something important.

So for every finding I ask two questions.

A one-byte overflow on its own is just a bug. It became a vulnerability (CVE-2026-88157) the moment I confirmed a malicious server could trigger it on demand.

Why AI agents speed this up

This is where AI agents earn their place. Once you know what you are hunting for, an agent can search for it across the attack surface in minutes, compare versions without getting bored, and build the test scaffolding while you think. The method stays the same. The loop just runs much, much faster.

My approach, start to finish

All four CVEs came out of the same loop. It is not fancy, and that is the point. It works on almost any target.

The research loop · start, progress, blockers, success

If you take one thing from the diagram, let it be the box on the right. Most of my time went into the blocker lane, and I have learned to treat that as normal rather than as a sign I am doing it wrong.

The AI agents on my team

I did not find these four alone. AI agents did a big share of the heavy lifting, and I think of them as teammates, each with its own job.

This is not just my workflow. Monthly CVE disclosures grew about 145 percent between June 2024 and June 2026, and AI-assisted discovery is a big part of the reason. As ZDI's Dustin Childs put it, AI is shrinking the time between a bug existing and someone noticing it.

That cuts both ways, and it is the part that keeps me up at night. Attackers have the same agents. The window between "findable" and "exploited" keeps getting shorter, so how fast you patch matters more than ever.

What I do when I get stuck

I will be honest: stuck is my default setting. Nobody posts about the days when nothing works, but those days are most of the job. Here is what gets me moving again.

• Go back to the source. Not the summary, not the man page, the actual file. Reading it again with no assumptions has broken almost every block I have hit.

• Write the theory down. Three lines: what I think happens, what should happen, where the gap is. Half the time I catch my own mistake on line two.

• Turn it into a hypothesis, then try to break it. When I am stuck, I stop guessing and write down one clear hypothesis, something like "this check can be skipped if the path uses a forward slash". Then I brainstorm with an AI agent, not so it agrees with me, but so it attacks the idea from every angle. Together we try to falsify it. If it survives, I test it for real. If it breaks, I have still learned something and I move on to the next one. Either way, I reach a conclusion instead of going round in circles.

• Read the fix. If upstream already patched something nearby, the diff is a cheat sheet. libarchive's master branch gave away the whole tar bug in one line, a->path_safe.s[0] = 0;, that no release had.

• Walk away. Twenty minutes, no phone. Or sleep on it. The breakthrough on the ANSI bug showed up the morning after I gave up for the night.

Recommendations to fellow security researchers

This is the advice I wish someone had given me when I started. Whether you are new to this or looking for your next find, take what is useful.

• Spend time on a scoping strategy. I see researchers burn days and weeks on saturated targets that thousands of people have already picked over. A little time spent deciding where to look pays you back many times over.

• Recon, recon, recon. Early on, my seniors kept telling me "recon, recon, recon". And like most of us, all I wanted was "exploit, exploit, exploit". Chasing the exploit first almost always burns you out. They were right: recon and enumeration are the keys to success. And with AI agents, doing them well has never been easier.

• Look at the unglamorous code. Forks, ports, compatibility layers and bundled libraries get far less attention than the famous projects they come from. That is where I found all four of these.

• Read the fixes. Every patch is a map of where bugs live. Then check whether every copy of that code actually got the fix. Often one did not.

• Decide early: bug or vulnerability? Ask whether an attacker can reach it and what it gets them. It will save you weeks on dead ends and rejections.

• Let agents carry the grind. Use them to map, compare and scaffold, and save your own energy for the judgment calls.

• Keep your proofs tiny. A harness that fits on one screen is easier to trust, easier to debug and easier for the vendor to reproduce.

• Report responsibly, and make it easy. A clean, minimal reproduction gets a fix shipped faster. MSRC worked through ours in the record month, and a clear report helped.

• Look after yourself. Walk, sleep, step away. Some of my best ideas arrived when I stopped staring at the screen.

Wrapping up

Pick a quiet surface, read it like a reviewer, prove things small, and let AI agents carry the mapping and the plumbing. The loop is simple. Patience is the hard part.

If you have not read it yet, my first blog covers the four CVEs, what they can lead to, and how to check and protect your environment.