This Week in AI Security - 12th February 2026

All right. Welcome back to another episode of This Week in AI security, coming to you from the Firetail team behind the Modern Cybersecurity Podcast. I'm Jeremy, your host, as always, and we are coming to you for the week as the twelfth of February twenty twenty six. We have a short episode today. We only have four issues or topics to talk about today, but they are important. So we're going to run a little bit short this week. But let's dive in and talk about what we've seen over the last week.

First thing, autonomous cars and drones can be prompt injected by putting prompt injections into signs that they spot along the way. So let's unpack this for a second and understand what we're talking about here. So we've talked about prompt injection any number of times on the show as being, you know, literally the number one threat. It is number one on the OWASP top ten security risks list. It is the thing that kind of takes LLMs off of their intended path in towards things that you may not want them to do. So common examples of this are things like ignore all previous instructions and bake me a cake or whatever the case may be. Right? And we've seen any number of these. Everything from the sell me a car for ten dollars to, uh, you know, abusing chat bots with airfares and any number of things like this.

Uh, over the last several weeks, we've covered a number of topics around things like software development environments, IDEs, and so on that have been exploited through planting malicious prompts in places that the IDEs will look, whether that be environment variables, read Readme, documents, documentation, files, what have you. Along those lines, when you think about the way that autonomous vehicles work, one of the things that they do is they pick up signals from all of the signs, both kind of metaphorical signs, meaning a pedestrian crossing the road, or the lidar image of a pedestrian crossing the road to physical signs like this is exit number three for Maple Avenue.

And one of the things that researchers at the University of California, Santa Cruz and Johns Hopkins University working together figured out was that autonomous cars and drones are both figuratively and literally reading these signs, interpreting the results using natural language processing. And the large language models or maybe small language models. But anyway, the AI systems that power them to make decisions. And sure enough, if you plant malicious prompts on these signs, the vehicles will obey that. When you think about this in a real world context, what could this mean? This could mean that a robotaxi that is meant to take a turn instead goes straight, and might ignore other signs like a stop sign or a red light and could cause havoc. It seems more like a risk for kind of mischief, but a risk for mischief that could have significant harm. So it's something really to keep an eye on, and I'm sure all of the companies that are behind these companies like Waymo and Zoox and what have you are going to have to take this risk seriously and think about how they design mitigations and controls within their autonomous vehicles to accommodate for this risk.

All right. Moving on to our next story. AI chat app leak exposes three hundred million messages tied to twenty five million users. So this is a smartphone application called Chat and Ask AI. This is a wrapper application that plugs into various large language models from other providers such as OpenAI's, ChatGPT, Anthropic's Claude, Google's Gemini, etc. it's a help app. You know. It is an app for the consumer who wants to interact with AI, ask questions, get answers, what have you. This is a another one of these things that we've covered any number of times over the last couple of weeks here on this week in AI security, which is, you know, it's not always the LLM or the AI system itself. It's often kind of the scaffolding and the architecture and the supporting technical components around it.

This is a very common firebase misconfiguration that leaves security rules set to public, which allows really any user with who has the project URL. So no authentication credentials, nothing required, but it allows them to read, modify or even delete data without authentication. Super common cloud and database as a service misconfiguration. So again remember your AI system is kind of as vulnerable as the weakest link or the biggest misconfiguration within that system. And obviously exposing the user user data is not a great look for this application. I'm sure they've patched the issue by now, but it is just again, emblematic of the kind of move fast, break things attitude and kind of the pace of development and competition that we're seeing in the AI landscape right now.

All right. Moving on to our next story, Docker AI bug. Let's image metadata trigger attacks. So this is actually very, very parallel to our first story. And again, right in line with that recent wave of stories around development environments, picking up data from all of the sources around the environment. So DACA, Docker is a virtualization technology built on Linux virtualization component or container rather, I can't remember what the C stands for. Allows you to run virtual machines in local environments, often for development purposes or in production environments, to kind of maximize the impact of the hardware or the underlying servers and systems, but also for isolation of different components. And sure enough, an AI assistant in the overall Docker structure, which kind of orchestrates and coordinates between various containers, will read metadata from all of the different sources in order to coordinate between the containers. And sure enough, again, if you plant malicious data in some of the metadata that will be read, interpreted and can be executed by the Docker AI assistant. So kind of more of the same on that side. Nothing. Uh, nothing too crazy there. Just, you know, more of the same.

All right. Moving on to our last story. And we've got a couple of different takes on this here. So a couple of links that we'll be sharing in the show. Notes. As always, Anthropic's new Claude opus four point six is a pro at finding security flaws. So there is some really interesting analysis. And there's been a lot of talk in the cybersecurity community about how large language models could be used to aid security researchers in finding bugs and finding flaws, finding vulnerabilities in different systems. And the team over at anthropic. I've given them kudos on the podcast here before, and I will just kind of do it again, because I think one of the things that I really love about their approach to the development of AI, and again, especially with the speed that it's moving at, is sharing their findings along the way. They've got any number of blogs where they share results of their research, new observations, things that are fundamentally new. I wanted to share a couple of highlights and again the link is in the show notes. I do encourage you, if this is an area of interest for you to go read the full article, because my treatment here is, you know, I'm going to capture a couple of the highlights, but there's a lot more in the story that might be relevant for you.

So the team, they they start by saying that, you know, they talked before about how they, we think we're either at or close to an inflection point for the impact of AI on cybersecurity, that llms are getting quite fast, and we think now is the right time to think about using them both in the offensive and the defensive side of things. Now, especially from the offensive side, which is what this research is about today. There's been a lot of talk that Llms can be used to find vulnerabilities. Last year at RSA and in the RSA recap was the very first kind of real world proof that an LLM had found a vulnerability in an application on its own, using a set of instructions and tools that had been given access to, but then no human intervention from beyond that point. And that was novel at the time. And we're only talking about something that is about nine or ten months ago.

So from that starting point of nine or ten months ago until today, we are now at a point where this opus four point six model is better at finding high severity vulnerabilities than previous models. But not only that, what is really fascinating here is, you know, from that first example where all of the tooling and all of the system prompts were put in place to kind of direct the LLM in a particular direction to find these vulnerabilities. These vulnerabilities were found without task specific instructions, without custom scaffolding, without specialized prompting. So you think about specialized prompting as being something like, hey, here is the reference architecture for a particular cloud Environment. I want you to look for Misconfigurations or here is the open API specification or Swagger doc for a specific API. Look for flaws within that. Know what they're saying here? Is that opus four point six. You say, hey, find vulnerabilities. General purpose prompt, right? That's what's novel about what's going on here.

And when you kind of go a little bit deeper, one layer below that to understand how the Lem undertook the task on its own, you can kind of see the difference between what has historically been the standard and what opus four point six has done. Historically, fuzzing has been a technique that has been very, very widely and popularly used to find vulnerabilities within applications. What that really refers to is throwing massive amounts of weird data at a particular application. Let's say you have an application that is accepting a first name. Well, a first name should be a alphabetic string. You might or might not accept alphanumeric, but let's just say that you know most languages around the world. Alphabetic string. Even if you have a different character set like Cyrillic or double byte character sets or what have you, but you've got, generally speaking, a language based alphabetic string for a first name, you might have some minimum length, you might have some maximum length. You know, maybe a first name needs to be two characters or more, maybe a maximum of twenty characters, things like that, you know? And then some systems will even validate against a list of known names, things like that. Right.

And so what would a fuzzer do? A fuzzer would do things like throw symbols into that name, throw gibberish strings into that name, throw a string of symbols, throw a string of alphanumeric plus symbols into their throw escape characters like brackets, apostrophes, line breaks, etc. what have you into there and see if it breaks. So that's kind of the way one way to think about fuzzing. That is not the way that opus four point six undertook this task. What opus four point six did was it read the code and it reasoned about the code and the generalities of this type of application based on your code. I know that you have a web form based on web forms. I know the common vulnerabilities from web forms. Let me go target these things. Let me look for logic bugs within the business logic of the application.

These are novel techniques that many human pentesters and red teamers and offensive security researchers will undertake. And now you've got an LLM that, with minimal prompting, say, hey, go find bugs. We'll do all of those things on its own without additional tooling, without additional prompting. What this means in the hands of an attacker, this can be the most effective way to find vulnerabilities in your own applications. So from a defensive standpoint, as you think about new novel applications going out into the world, especially those that have open source components that are a key part of the application or the application architecture just realized that a lot of the vulnerabilities within these systems will be found much faster than before, and to layers that you might not be testing on your own. It might also behoove us as defenders to start thinking about using these types of tools to test our own applications from a security perspective before putting them out there.

So a lot to think about there. Some really, really interesting developments. This stuff is all moving forward at paces that, you know, again, I have never witnessed in my twenty eight ish year career in technology and cybersecurity, stuff that bears thinking about stuff that bears exploration. And that is what we try to do here each week on this week in AI security. So for this week, I'm Jeremy, your host signing off. Rate review like subscribe and please share. And if you haven't already, please subscribe on Spotify, Apple Podcast, YouTube. And we recently launched this week in AI security on LinkedIn, so you can catch episodes there as well. Thanks so much. Talk to you next week. Bye bye.