A support bot that took instructions a little too literally

Lenovo runs a customer-support chatbot called Lena. It is built on GPT-4, sits on Lenovo's website, and is there to answer the usual stream of questions about laptops, warranties, and driver downloads. It is also, like most large language models, eager to please. That eagerness is the whole story here.

In July 2025, researchers at Cybernews discovered that Lena would accept a single, roughly 400-character message and convert it into a working cross-site scripting (XSS) attack. They reported the issue on July 22, 2025. Lenovo confirmed it on August 6 and had a fix in place by August 18. There is no public evidence anyone exploited this against real users. This is a documented hazard and a near-miss, not a known breach. But it is a near-miss worth dissecting, because it shows a new way an old bug can sneak past defenses that should have caught it.

What the prompt actually did

Cross-site scripting is one of the oldest categories of web vulnerability. The short version: an attacker gets malicious code to run inside someone else's browser session, usually by smuggling it into a page that the victim's browser then trusts and executes. The standard defense is input and output sanitization - you strip or neutralize anything that looks like active markup before it gets rendered. Web developers have been fighting this fight for two decades.

The clever, and slightly grim, part of the Lena incident is that the payload did not arrive looking like an attack. It arrived as a conversation. According to Cybernews and the reporting that followed, the malicious prompt had several parts stitched together. It opened with a normal-sounding product question, the kind Lena handles all day. Then it told the bot how to format its answer - convert the response into HTML, and while you are at it, include a specific piece of markup. That markup was an image tag pointing at a URL that did not exist. Attached to the image tag was an instruction for what the browser should do when the image inevitably failed to load: make a network request to an attacker-controlled server, and attach the viewer's cookie data to that request.

This is a well-worn XSS pattern. An image that cannot load triggers an error handler, and the error handler is where you hide the code that ships the victim's secrets off-site. What made this version notable is that the attacker never had to defeat Lenovo's input sanitization directly. They asked the AI to produce the dangerous markup. The model, doing exactly what it was told, generated HTML containing the payload. That HTML was then stored and rendered as part of the chat - and stored XSS is the more dangerous flavor, because it sits there waiting for the next person to view the conversation rather than firing once for a single tricked victim.

As Cybernews put it, people-pleasing remains the unsolved problem that haunts large language models. The bot was not hacked in any traditional sense. It was persuaded.

The victim was the support agent, not the customer

Here is the detail that elevates this from "cute trick" to "you should patch this immediately." The injected HTML didn't threaten the attacker's own browser, which would be pointless. It threatened whoever opened the conversation later.

When a customer's chat gets escalated, a human Lenovo support agent opens it in their own console to read the history and respond. At that moment, the stored payload executed in the agent's browser, inside the agent's authenticated session. The failed image fired its error handler, and the agent's active session cookies were sent to the attacker's server.

Session cookies are the keys that say "this browser is already logged in." Steal a valid one and you can often impersonate that session without ever knowing a password. The reporting describes the downstream possibilities plainly: an attacker holding a support agent's session could read other customers' chats, both live and historical, and potentially pivot further. ITPro and SC Media both noted that the chain could escalate toward running system commands, installing a backdoor, and lateral movement across Lenovo's internal network. None of that was demonstrated as having happened to real people; it is the described blast radius if someone had weaponized the flaw before the patch.

So the structure of the attack is worth restating because it is genuinely nasty: a customer-facing input field, open to anyone on the internet, was wired to a tool (the AI) that could generate arbitrary HTML, which was then stored and rendered in front of a privileged internal user. The trust boundary ran exactly backwards. The least-trusted person in the system could hand instructions to a component that the most-trusted person's browser would later execute.

Why normal defenses missed it

Plenty of web frameworks would have stopped a raw <img onerror=...> typed directly into a form field. Sanitizers are built to recognize that shape. The reason this slipped through is that the markup was not typed into a field that anyone thought to sanitize. It was generated on the fly by a trusted internal component - the company's own AI - and then trusted on the way out.

This is the recurring lesson in the whole genre of AI-assistant vulnerabilities. Teams treat the model's output as if it were first-party content, because the model is theirs. But a model that takes free-text input from the public is, in security terms, just another channel for untrusted input. Whatever a stranger can talk the model into saying becomes, functionally, input the stranger supplied. If you would sanitize a comment box, you have to sanitize the model's output too, because the model is now the comment box wearing a name tag.

The fix Lenovo deployed addresses this specific prompt. The broader pattern - generative output rendered as trusted HTML in a privileged context - is not something one patch retires. Any chatbot allowed to emit formatted markup needs its output treated as hostile until proven otherwise: escape it, strip active elements, and never render AI-produced HTML in a session that holds credentials you would not hand to a random web visitor.

The graveyard lesson

Lena belongs here not because it caused a known disaster, but because it shows how cheaply one could have happened. No malware, no zero-day in a parser, no stolen credentials. Just a chatbot that was deployed with the enthusiasm reserved for a shiny new feature and the security review reserved for, apparently, nothing in particular.

The most quotable framing from the coverage is also the most useful: it took a single prompt. Organizations keep bolting AI onto customer-facing surfaces at a speed that outruns the unglamorous work of treating those surfaces as the untrusted attack vectors they have always been. Lena is a reminder that the model is not a magic trusted oracle. It is a very obedient stranger-facing input, and you should secure it accordingly.