Cred Relay Issue #5 Jun 16, 2026 • 4 min read 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-3508is an out-of-bounds read inAsusWmiAcpi.sys.CVE-2026-6737is an exposed IOCTL / access-control issue inAsusPTPFilter.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 calledcthaehthat 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: