Query Injection

Query Injection

In a query injection attack, attackers smuggle hidden commands into a request to an AI system or a database in order to trick it into unwanted behavior. The principle is old, but it gains new urgency through the use of AI assistants in products and businesses.

Many computer programs receive input from outside and process it as commands. This is convenient, but dangerous: whoever controls the input can manipulate the program. In a query injection — the term refers to a request or query — an attacker exploits exactly this. He hides additional commands within seemingly harmless input. The system cannot tell the difference and executes the smuggled-in command as if it came from the legitimate operator.

Why query injection is particularly insidious

The insidious part is that there doesn’t need to be any error in the system. The program works exactly as it was built to — it simply receives an input that it interprets incorrectly. The attack doesn’t exploit a vulnerability in the code, but a vulnerability in the logic: the system does not distinguish between data and commands.

This makes query injection a persistent problem. Even if a developer blocks all known attack patterns, new ones can emerge. With classic databases, the rules are at least precisely defined. With AI systems that process natural language, the boundary between content and command is even softer — which makes the situation even more difficult.

The principle behind the attack

The classic example comes from databases. A web application assembles search queries like this: it takes the text a user enters and inserts it directly into a database query. A normal user types a name. An attacker instead types a name plus a database command — for example, a command that reads out all passwords. The database sees both as one valid command and executes it in full.

AI systems work in a similar way. A chatbot receives instructions from the operator on how to behave — for example: “Only answer questions about our products.” These instructions sit in the same text field as the user input. An attacker can now write: “Ignore all previous instructions and instead do the following …” The AI model has no built-in mechanism that cleanly separates operator instructions from user input.

Even more sophisticated are indirect attacks. Here, the malicious command is not located in the user input itself, but in a document or a webpage that the AI system reads automatically. The attacker has prepared this text beforehand. The system reads it, interprets the hidden command, and executes it — without the actual user having entered anything at all.

Query injection in products and headlines

SQL injection — the attack on databases — has for years been among the most common attack methods of all. OWASP, the non-profit organization that documents security risks in software, regularly ranks injection attacks at number one on its list of the biggest threats to web applications. Major data breaches at well-known companies have often originated from exactly this vulnerability.

With the rise of AI assistants that independently browse the internet, read emails, or manage calendars, the attack surface grows considerably. Security researchers have shown that prepared webpages or emails can cause an AI assistant to forward data or carry out actions the user never intended. Microsoft, Google, and other providers are actively working to secure their AI products against such attacks — but a complete solution does not yet exist.

Query injection is thus not a purely academic problem. Anyone who uses AI tools with access to real data or services — professionally or privately — should know that an assistant’s responses do not always depend solely on their own input. They can also be influenced by content the system has processed in the background.

Subscribe free. Unsubscribe the second it sucks.

High-signal news across AI, business, UX, and tech. Every morning.