This week’s research is mostly about how AI changes the economics of vulnerability research by taking on the grunt work, exploring more paths and making it cheaper to keep digging long after the first bug has been found.

Quentin Kaiser documents an experiment using an AI agent to reverse engineer a Netgear cable modem, identify vulnerabilities and develop working exploits against a live embedded target. The agent handled a significant amount of analysis and exploration, but only after Quentin had prepared the environment with hardware access, Ghidra integration, debugging support and target-specific guidance.

The cost of entry into embedded vulnerability research can feel particularly high. Before meaningful research can begin, you may need to obtain the right hardware, extract the firmware, identify an unfamiliar architecture, connect to serial interfaces and build or adapt your debugging environment. This still requires specialised knowledge and remains difficult to automate away.

A large part of embedded research is repetitive and error-prone rather than especially creative. Researchers spend time rebuilding and flashing firmware, waiting for devices to reboot, reconnecting debugging sessions, collecting logs and running the same sequence after every change. An agent that can manage these processes, maintain the current state and perform the grunt work consistently can make a significant difference, even before it contributes anything novel to the vulnerability research itself.

AI does not need to eliminate the hardware or expertise required to begin embedded research to change its economics. Reducing the cost of everything that comes after the initial setup may be enough to make more devices worth investigating and allow researchers to spend more time on the decisions that still require human judgment. AI Assisted Vulnerability Research on Embedded Targets | QTNKSR.

This is a great example of the distance between finding a bug and understanding its real impact. A broken prefix comparison in Vinyl Cache’s HTTP/2 pseudo-header handling was first missed by one Claude subagent, then identified by another but dismissed as a recoverable denial of service. Further investigation found a way to avoid the crash and turn the same primitive into HTTP request smuggling, allowing requests and credentials to be captured across reused backend connections.

It is also a useful way to think about wp2shell. Someone could have stopped at the array desynchronisation, classified it as an authorization bypass and moved on. Instead, deeper investigation connected it to cache poisoning, temporary administrator context and eventually remote code execution.

This is where agents may change vulnerability research. Once a suspicious primitive has been found, they make it much cheaper to repeatedly ask what else can be done with it, explore alternative execution paths and test increasingly ambitious exploit chains. The important advantage may not be finding the first bug. It may be making it economical to keep digging after a human researcher might reasonably have stopped. MAD Bugs: My Cousin Vinyl (CVE-2026-50052).

This write-up demonstrates an attack chain in which an indirect prompt injection inside a spreadsheet causes an LLM-powered CLI tool to emit a specially crafted ANSI escape sequence. The model does not execute a command or call a tool. It simply produces text, which macOS Terminal interprets and turns into a DNS request containing stolen data.

The interesting part is the transition between components. The application sees model output as text, while the terminal interprets part of it as a control sequence. This matters because agent security often focuses on tool calls and command execution, but raw model output can itself become dangerous when passed to another component.

The specific Terminal behaviour has been fixed, but the broader lesson remains: model output is untrusted data and must be handled safely for the context in which it is rendered. From Indirect Prompt Injection to DNS Exfiltration in macOS Terminal.

BugBunny provides a detailed reconstruction of wp2shell, the WordPress core chain that combines REST batch-route confusion with SQL injection to reach unauthenticated remote code execution. The fascinating part is how far the final impact is from either individual bug. A missing entry in one of several parallel arrays causes requests to be dispatched using the wrong handler. The SQL injection is then turned into control flow through WordPress’s object cache, oEmbed logic, temporary Customizer administrator context and a nested REST request.

Someone could easily have stopped at the desynchronisation issue, classified it as an authorization bypass and moved on. Instead, the research kept digging until a seemingly limited primitive became remote code execution. Like the Vinyl Cache research above, it shows why the first identified impact is not always the real impact.

The complexity of the final exploit also makes me wonder whether a single human researcher would have built the entire chain on their own. None of the individual steps is necessarily impossible, but connecting them requires an extraordinary level of persistence and internal knowledge of WordPress. You need to understand several distant subsystems, recognise how they can influence one another and continue exploring long after the original bug already appears reportable.

This may be one of the biggest ways agents change vulnerability research. They can repeatedly explore new paths, inspect unfamiliar subsystems and test increasingly unlikely hypotheses at very little additional cost. The result may not simply be more bugs, but exploit chains that would previously have required several specialists or an unreasonable amount of time from one researcher.

The write-up is excellent, although it should more clearly credit Adam Kues at Searchlight Cyber, who originally disclosed wp2shell. We also published our detailed breakdown, indicators of compromise for defenders and hands-on lab for PentesterLab PRO users. How Two WordPress Core Bugs Chained into Pre-Auth RCE.

I got to meet some of the Sentry team at BSides Porto, and they are doing genuinely interesting work around AI security. This guide looks at Special Token Injection, where attacker-controlled input reaches the model as reserved tokens used to delimit roles, messages or tool calls.

Instead of merely persuading the model using malicious natural language, the attack targets the serialization and tokenization layer. User input may consequently be interpreted as a system message or function call. This matters because many AI security reviews focus almost entirely on prompts and model behaviour. A proper assessment also needs to inspect the chat template, tokenizer configuration, inference pipeline and the code that turns model output into actions.

It is another parser differential, except the disagreement is between the application, the prompt template and the model’s control-token protocol. Special Token Injection (STI) Attack Guide.