AI agents have been a gamechanger in vulnerability discovery and can go through reverse engineered code faster than any human. Left alone they don’t stay on task, they chase the finish line, skip steps and get stuck. Finding vulnerabilities with LLMs can really feel like herding cats.
We built the Kitten process, a 12 step method, to turn that raw speed into disciplined research. Using it we found a CVSS 10.0 vulnerability chain in ASUS Control Center. A leaked encryption key, an exposed Guacamole servlet and a hardcoded root password chained into remote code execution as root. Now patched.
As a service to our clients, we periodically review their internet attack surface. During those reviews we see the usual suspects: web servers, firewalls, VPN, but also less common appliances and applications. The recent developments in LLMs have enabled us to review certain products offline in a test environment. Work that would normally take weeks can now largely be offloaded to the agent. A system like Claude Code or OpenAI Codex can independently run tools to reverse engineer a product and find vulnerabilities. This post describes our experiences with using AI to find a critical vulnerability chain in ASUS Control Center (CVSS 10.0).
We’ve been doing vulnerability research for many years and have always worked from a methodology. Most of our research has been on vulnerabilities that can eventually get unauthenticated remote code execution and can be used as an initial access vector. To mirror the methodology of finding these bugs, we designed the “Kitten process”. This process is a step-by-step plan for the agent to get the software, reverse engineer it, map the attack surface, find vulnerabilities and exploit them.
The process uses 12 steps and can be found in our skills repository on GitHub. The name was chosen to be unique and easy to refer to in a prompt. The cat was being annoying as I was working on it, so the name was born.
A few key elements:
We designed the process as a workflow the agent could follow step by step to autonomously come to an end result: something we can report to the vendor to make our clients safer. We also learned currently this is probably not realistic on such a complex task.
In early 2026, we ran the process against several software products, using a $20/month Claude Pro plan (on Opus 4.5). We found that already then, the models were quite good at mapping the attack surface and going over reverse engineered code to find vulnerabilities. If you ever looked at decompiled code (like Java classes) you know how annoying this can be as certain information was lost in the process (like variable names). Agents are not bothered by this and can go over code fast.
The agent tends to have issues following a step-by-step process. We often observed the agent looking for vulnerabilities before the attack surface was fully mapped. The agent tended to focus a lot on the end goal and was willing to sacrifice following the process to get there.
We also saw the agent getting stuck a lot. In one instance, the agent got stuck on the first step: simply trying to obtain the software. We had observed earlier it was available for download on the vendor website, but the agent was unable to get it there due to a CDN blocking automated processes. The agent got desperate and started probing the vendor demo instance, trying to scrape the JavaScript files to get a sense of the architecture. This could easily be fixed by downloading the software manually and providing it to the agent.
In another instance the agent obtained an installer but encountered serious issues extracting the actual software from it. It spent hours trying to reverse the installer, attempting to get the actual executables out of the package. It ran into all sorts of copy protection mechanisms that prevented it from achieving its goal. Simply installing the software on a test machine and providing the agent with a copy of the installation directory helped it along.
ASUS Control Center can be used to manage ASUS endpoints and servers. It can also be used to deploy software to endpoints that have its agent installed, giving it RMM-like functionality. This makes it a high-value target. Luckily, the product is not often directly exposed to the internet.
As is described in the public CVE record, the agent found a web service that could be accessed using an encryption key. This encryption key was exposed without authentication on another web endpoint.
The web service allowed for SSRF, sort of. It was an Apache Guacamole instance that could be used to make VNC, SSH or RDP connections to random hosts. The appliance itself happened to be running SSH, but it was blocked by the firewall. Connecting to localhost via Guacamole bypasses that firewall and allows an attacker to log in.
That leaves the matter of getting the right SSH credentials. Luckily (at least for the attacker), there is a hardcoded root password hash in the appliance. The password was not easy to crack, but Claude was able to create a wordlist based on other hardcoded secrets found in the source code. This wordlist could then be used to log in as root and execute a command.
The output of the SSH session is rendered as PNG frames, but we decided to just blindly execute a command that drops a web shell.
Was Claude able to find this full chain? Well, not really. It found the exposed Guacamole servlet and determined it could be accessed using the leaked encryption key but did not realize it could use it for SSH access. It got stuck for a while on finding an SSRF target to send HTTP requests to, while we feel this would be a much harder path (at least using Guacamole). With a bit of guidance we got it back on track and it was able to write a full exploit that could write a web shell and execute code as root.
That being said: We probably wouldn’t have found this chain without Claude getting the building blocks for me. LLMs have come a long way since Opus 4.5, but even in the newer models we see they needed to be supervised and steered frequently to find great bugs on hard targets.
ASUS was very receptive to our report and released a patched version. If you run ASUS Control Center, make sure to update to the latest version. Versions up to 4.0.0.2 are affected.
Most of this work was done with Claude Opus 4.5, which was released in November 2025. While Opus 4.5 couldn’t independently find the full vulnerability chain, the results were already impressive. It found all the building blocks and developed a complex exploit with limited assistance.
Recent developments have been mind-blowing. We have used the recent models from both Anthropic and OpenAI to build crazy memory corruption exploits against real-world hard targets without much user intervention. Stay tuned for more blog posts in the coming months!
Are agents capable of independently discovering vulnerabilities? Well, yes and no. While the agent does most of the heavy lifting, for all complex vulnerabilities we found, the agent needed frequent steering and supervision. This is where an operator with expert domain knowledge can make the difference between a great finding and the agent burning tokens for hours on a path that will most likely never succeed. This is especially true when reverse engineering is needed as the agent has no direct source code available.
A parallel could be drawn with developing software: anyone can use LLMs to create software, even without any knowledge of computer programming. But to use the agent to build complex software that does exactly what you want is still not easy. This is where it helps to be a programmer, even if you’re not doing much of the programming yourself.
For these new models, the Kitten process will most likely require some tweaks. These models seem quite capable given the right prompt and need less process guidance. A good place to start is the prompt Searchlight Cyber used to find the wp2shell vulnerability using GPT 5.6 (with hardly any steering). A stringent process can also sometimes hinder an agent and cause it to burn tokens at a fast rate.
We do a lot of incident response. In ransomware cases the initial access usually comes down to these three:
There is going to be a surge in incidents in the third category. Just in the last few weeks we saw PaperCut and N-able exploited with zero-day vulnerabilities. There is no public evidence these bugs were found using AI (and we will probably never know for sure), but the increase in incidents like this is noteworthy.
Zero-days are nothing new, but where ransomware groups previously exploited recently patched vulnerabilities, we’re going to see more incidents where no patch was available at the time of the attack. These models make vulnerability research accessible to a much larger group of people, and bugs will be found in products that have received limited scrutiny so far.
This means that knowing your attack surface is even more important now than it was before. It also means that you should limit this attack surface as much as possible. Things like management interfaces shouldn’t be accessible to anyone, even if they require authentication.
Also, assume breach. That internet-facing software is just a first step for an attacker. You need good detection (and response) in your network to catch attackers while they are still getting their bearings. Appliances often cannot run EDR sensors, but the attacker’s next move (onto a domain-joined system) is where you can catch them, provided you have EDR on everything that can run it. This can enable you to stop an attack regardless of how the attackers got in and hopefully before they have achieved their objectives (like stealing your data or taking your network hostage with ransomware).
You can find the SKILL.md in our skills GitHub repository.
As a Claude Code user, you can install it like this:
/plugin marketplace add eyesecurity/skills/plugin install vulnerability-research
If you prefer Codex you can use this prompt:
git clone https://github.com/eyesecurity/skills.git && read and install skills/plugins/vulnerability-research/SKILL.md
