Getting a CVE Without Shipping Slop

This issue: my first two CVEs. I used Claude Code and Ghidra MCP to get them. And I did it without sending a bunch of time wasting crap to ASUS.

Last time I wrote about pointing that setup at kernel drivers on my gaming laptop. At the time, most of the results were still in vendor limbo. Some were rejected. Some were waiting. Some looked real but did not have CVEs yet.

Two of the ASUS reports crossed the line.
CVE-2026-3508 is an out-of-bounds read in AsusWmiAcpi.sys.
CVE-2026-6737 is an exposed IOCTL / access-control issue in AsusPTPFilter.sys.

One is a size validation bug, and sometimes DoS. The other is a driver with bad permissions.

I was interested in BYOVD and finding some drivers I could use at my day job. I was also curious about what drivers I had on my gaming laptop.

I didn’t have a way to quickly pick a driver to investigate so I created a tool called cthaeh that would rank them based on my criteria. Also I didn’t want to waste time on drivers I knew would have already been covered like any from Microsoft.

I don’t have that much experience reverse engineering drivers so that’s where Ghidra MCP comes to into play. It allowed me to instrument Ghidra using Claude Code.

Claude did a lot of the reversing support and PoC drafting. It’s a helluva lot faster to have Claude generate the C than to type it out yourself. But I know how to read C. And this is one of the important things about not shipping slop. You have to know what correct looks like.

You have to force the model to prove out the bug with a working PoC.

The finding was only real once it can be proven with a PoC and I understood what was happening. No guessing or trusting Claude.

That last part is where most of the sloperators fail. They get excited and trust the model.

The model wants to tell a pretty story. It wants to hype and will hype you up if you aren’t careful.

You have to keep pulling it back.

The first public ASUS CVE from this work is CVE-2026-3508. A medium bug.

The driver was AsusWmiAcpi.sys, part of ASUS System Control Interface. The tested vulnerable driver was version 2.1.68.0, included in asussci2.inf version 3.1.57.0.

The interesting IOCTL was:

The driver accepted a small METHOD_BUFFERED IOCTL input. Inside that input was another size field, InBufferSize. The driver checked that the claimed size fit in its destination buffer. That part was fine.

It did not check that the caller had actually sent that much input.

For METHOD_BUFFERED, Windows gives the driver a SystemBuffer sized like this:

So, the PoC used a tiny request:

That gives the driver a 12-byte system buffer. The first 8 bytes are the method ID and the claimed input size. Only 4 bytes of real caller data remain after that.

The driver still copied 0x400 bytes from SystemBuffer + 8.

The caller sent 12 bytes, claimed there were 1024 bytes of payload, and the driver trusted the claim while reading from kernel memory past the valid input buffer.

ASUS published it as an out-of-bounds read with CVSS 4.0 score 6.8 Medium.

You can crash a box with it, sometimes.

The second one was CVE-2026-6737 in AsusPTPFilter.sys, the ASUS Precision Touchpad Filter driver.

This was the same driver from issue #2. I had to withhold details then.

It wasn't clear what was happening in the first "PoC" that got spit out from Claude.

A standard user being able to open device objects was cool, but if every IOCTL bounced, I had a weak report at best. So I fed the results back to Claude and had it dig into why the handlers were rejecting the calls. I had to question what it was testing and tell it to rework its PoC.

The next PoC got further.

The root cause was that the driver created named device objects with IoCreateDevice and did not supply an explicit SDDL/device security descriptor. Windows applied default permissions that let a standard local interactive user open those objects. The safer pattern would be IoCreateDeviceSecure or WdmlibIoCreateDeviceSecure with an administrator-only DACL, or equivalent access checks in IRP_MJ_CREATE.

The reachable device names were:

The PoC demonstrated IOCTL reachability:

ASUS published it as an exposed IOCTL with insufficient access control. They described it as follows.

The fixed version is AsusPTPFilter 16.0.0.46 or later, delivered through Windows Update.

ASUS scored it Low at CVSS 4.0 score 2.0.

Did you know you could get a CVE for a low? Neither did I.

Rule one: validate the bug with a fucking PoC.

Only report what you can prove.

Rule two: admit to yourself when you don't know wtf is happening.

The model will happily gaslight you. You may not recognize it if you can’t catch false assumptions.

Rule three: edit the crappy AI report or write your own without it.

AI is fucking verbose and it’s easy to recognize.

My full writeups for these bugs are on GitHub.

If you want to know how to set this up to find your own bugs with LLMs then go read issue two.

That is it for issue #5.

If you found this useful, forward it to someone who would actually read it.

Got questions, corrections, or want to argue? Hit reply. I read everything.

— Jeff