Findings report (PDF): KBS-findings-report-2026-11-03.pdf · view on GitHub
One of the things that genuinely keeps me up at night is thinking about just how powerful AI can be when you actually know how to use it.
Take bug bounty, for example. It's incredibly exciting when you realize what you can accomplish with a swarm of geniuses at your disposal. The possibilities are pretty much endless. You just have to know which questions to ask, and how to ask them.
Over the past week, I've managed to find and disclose multiple bugs. The frustrating part? Apparently, everyone else in this space is just as capable of finding them. Five of my properly documented disclosures had already been reported by someone else just before I submitted mine.
What can I say? I'm really good at being just a little bit late.
But that's part of the game. With bug bounty, finding something is only half the battle. You have to stay in scope, understand each vendor's specific rules, reproduce the issue, and document everything properly. Finding a potential vulnerability and submitting a report that actually holds up are two very different things.
These haven't been publicly disclosed yet, but here's a look at some of what I've been working on:
Vercel – SSRF through Next.js
ImageResponseusing attacker-controlled image URLs. The bundled@vercel/og1.0.1 protection could be bypassed through DNS resolution and redirect hops.Marriott – Subdomain takeover through a dangling Heroku CNAME on
spametrics.marriott.com.Teamup – Unauthenticated exposure of commenter email addresses on shared events.
Socket.dev – Supply-chain parser bypass resulting in silent dependency-checking failures across npm, Rust, and Ruby.
Patchstack – Insecure Direct Object Reference (IDOR) vulnerability in
mstore-apiversions up to and including 4.22.1.
Here's something I've come to realize: there is an enormous amount of opportunity in this space. Maybe not necessarily when it comes to being the first person to responsibly disclose something, but certainly when it comes to finding things that need fixing.
A lot of software is far less secure than people assume. And while the person who gets the first valid disclosure usually gets the reward, that doesn't mean they're the only person who found the issue. It's becoming increasingly obvious that multiple people can independently discover the same vulnerabilities, and AI is making that process significantly easier.
Those five findings could easily represent weeks of traditional testing. With the right approach, I've been able to take that entire process from discovery through validation and documentation and compress it into hours.
Now, don't get me wrong. It's not as simple as opening ChatGPT and asking it to find vulnerabilities. It'll often refuse requests that sound like security exploitation, even when you're working entirely within the context of authorized testing and responsible disclosure.
You still need to understand what you're doing, know how to direct the tools, validate their findings, and distinguish an actual vulnerability from something that just looks interesting.
After getting a little discouraged by the fact that my work wasn't going to be rewarded simply because someone else got there first (and, let's be honest, some of these people are probably running fully automated pipelines), I decided to change my approach.
Instead of competing exclusively over the same popular targets, I started looking elsewhere.
I began using AI to identify commonly used libraries and software packages that hadn't received updates in a while.
The reasoning is pretty straightforward: countless applications and systems are built on top of these dependencies. If a commonly used library has a vulnerability, there's a good chance that vulnerability could affect a much larger number of applications relying on it.
It's not necessarily the most lucrative avenue when it comes to traditional bug bounty rewards, but I thought it was worth exploring.
I haven't finished checking whether all of these findings have already been publicly reported, but I've started putting together a list of reproducible issues affecting commonly used libraries and software, including current versions.
Some of these are particularly interesting, including potential remote code execution (RCE) issues, which can fall into the critical severity category depending on their impact and exploitability.
And that's really what makes this whole thing so interesting to me.
We're reaching a point where one person, with the right knowledge and the right AI tools, can investigate an absolutely staggering amount of software.
I don't think we've even scratched the surface of what's possible yet.