Two perfect tens, and neither is an AI bug

Two advisories scored a perfect ten this week. Both are in an enterprise product sold as an AI platform. One is SQL injection. The other is code injection. Their weakness classes were catalogued before most of the industry had heard the phrase large language model.

That is the story, and it cuts against the way this subject is usually written up. The interesting question is not what new attacks AI invented. It is how much of the new surface is carrying very old bugs.

The worst two are ordinary

Unauthenticated arbitrary SQL against the instance database. Unauthenticated arbitrary code execution on the platform. Strip the product name and these are findings you could have written in 2005, and the remediation advice would be identical: parameterise the query, stop evaluating attacker-influenced strings.

The AI label is not the vulnerability. It is the reason the code exists, and the reason it shipped quickly. A new product line is a new codebase, a new set of endpoints and a new deadline, and those three things have always produced this.

One of them genuinely is new

Then there is the agent framework where remote code execution arrives through prompt injection. Its Python and shell tools take arguments the model produced and hand them, unsanitised, to execution sinks:

exec()
runpy.run_path()
subprocess.run()

The attacker never touches those calls. They write something into a web page or a document, the agent reads it as part of doing its job, and the model obligingly produces the argument. The input is laundered through the model, which is precisely what makes it hard to filter: by the time the string reaches the sink it was generated by your own trusted component.

This one is not an old bug in a new place. The trust boundary genuinely moved, and it now runs between the model and the tools it can call.

And one that is both at once

The most instructive entry is the IDE whose agent mode could write outside the workspace. The weakness class is path traversal, which is thoroughly ancient. What is new is where the path came from: the model supplied it, and the containment check that would have caught a user-supplied path was never applied to a model-supplied one.

That is the bridge between the two halves of this list. The bug class is old. The reason nobody validated the input is that it arrived from a component the code considered part of itself.

It has reached the browser

A shipping mobile browser from Microsoft now carries a prompt-injection identifier of its own. The score is modest and the impact is spoofing rather than compromise, so this is not the alarming part. The alarming part is the category: prompt injection is no longer confined to somebody's agent framework on GitHub. It is in software with hundreds of millions of installs, and it will be assessed by teams who have never had to reason about it.

What to actually do

• Review the AI product like any other web application first. The worst findings this week would have been caught by an ordinary appsec pass, not by anything agent-specific.
• Then add the one new boundary. Treat model output as untrusted input to every tool it can reach, especially anything that executes, writes files or makes requests.
• Apply your existing validation to model-supplied values. Path containment, allowlists and canonicalisation usually exist already and are simply not wired to that source.
• Check where your agent tooling stores provider keys. At least one project this week wrote them to disk in cleartext under a predictable name.