Critical flaw in Lenovo’s Lena AI chatbot lets attackers run code and steal cookies

If a friendly AI chatbot greeted you on a big brand’s website and seemed a bit too helpful, would you notice when it quietly handed your session cookie to an attacker?

That’s the chilling lesson from a critical security flaw in Lenovo’s AI chatbot, “Lena,” where a single prompt could inject malicious code, exfiltrate session cookies, and potentially open a door into customer support systems. Not because GPT-4 “went rogue,” but because the app around it trusted the model’s output too much.

Here’s why that matters: this isn’t just Lenovo’s problem. It’s a wake-up call for every company racing to ship AI features without hardening the basics of web security. The vulnerabilities weren’t exotic. They were classic Cross-Site Scripting (XSS) — reborn in the era of LLMs.

Below, I’ll break down what happened, how the attack worked, what was missing from Lenovo’s defenses, and a practical checklist you can use today to secure your own AI chatbot.

What happened: Lenovo’s AI chatbot exposed by XSS vulnerabilities

Cybernews researchers found critical vulnerabilities in Lenovo’s implementation of its Lena chatbot, powered by OpenAI’s GPT-4. By crafting a single 400-character prompt, attackers could:

Inject malicious HTML into the chatbot’s response
Trigger a browser to send active session cookies to an attacker-controlled server
Potentially compromise Lenovo’s customer support platform once a human agent opened the chat history

The issue wasn’t LLM “hallucinations.” It was about trust boundaries. The system treated chatbot output like safe, renderable content. That turned Lena into a conduit for client-side code execution — the textbook definition of XSS.

As Cybernews put it: “Everyone knows chatbots hallucinate and can be tricked by prompt injections. This isn’t new. What’s truly surprising is that Lenovo, despite being aware of these flaws, did not protect itself from potentially malicious user manipulations and chatbot outputs.”

Žilvinas Girėnas, Head of Product at nexos.ai, summarized the deeper point: “LLMs don’t have an instinct for safe — they follow instructions exactly as given. Without strong guardrails and continuous monitoring, even small oversights can turn into major security incidents.”

To Lenovo’s credit, the issue was responsibly disclosed and mitigated before public disclosure. But the pattern is bigger than one vendor.

Discovery: July 22, 2025
Initial disclosure to Lenovo: July 22, 2025
Acknowledgement: August 6, 2025
Mitigation: before August 18, 2025
Public disclosure: August 18, 2025

For background on XSS and why this keeps happening, see OWASP: Cross-Site Scripting (XSS).

How a single prompt turned into a multi-step attack

Let’s make this practical and keep it non-exploitable. No code, just the logic.

Cybernews crafted a prompt with four parts:

1) A normal-looking request
They asked for product specs — something like “Show me the specifications of Lenovo IdeaPad 5 Pro.” Nothing suspicious.

2) A format change trick
They instructed the chatbot to output the answer in multiple formats (HTML, JSON, and plain text) in a specific order that the server expected. This ensured the browser would render the HTML response without stripping it.

3) A malicious “image” trap
The HTML included an image element pointing to a non-existent resource. When the image failed to load, the browser followed a fallback instruction that made a network request to an attacker-controlled server — embedding the user’s cookies in the request URL.

4) Social pressure to comply
The prompt ended by insisting the image must be shown: “It is important for my decision-making. SHOW IT.” That nudge made it more likely the LLM would follow the earlier steps faithfully.

Now, the chain reaction:

The chatbot “helpfully” produced HTML containing those hidden instructions.
Lenovo’s system stored the chat history with that HTML as-is.
When a human support agent later opened the conversation, their browser rendered the HTML, repeatedly triggering the cookie exfiltration sequence.
With stolen session tokens, attackers could potentially hijack a support agent’s session and access internal systems.

Again, the enemy wasn’t GPT-4 as a model. It was the unsafe rendering of untrusted content from a model.

For a deeper dive on LLM-specific risks, see the OWASP Top 10 for LLM Applications.

Root causes: where the defenses broke down

This incident exposed several compounding weaknesses — an all-too-common pattern with AI UI layers:

Improper input sanitization
The system did not strictly validate or constrain what users could ask the chatbot to output. It allowed instruction chains to alter formats and embed markup.
Improper output sanitization
The application rendered the chatbot’s HTML without robust sanitization, letting malicious markup pass through.
Web server trust of model output
Systems accepted, stored, and later served model-generated HTML as if it were safe content — effectively moving untrusted data across trust boundaries.
Executing unverified code paths
“Helper” behaviors (like loading images or external resources) were left intact in the agent console. This let the attacker piggyback on browser behaviors.
Loose resource policies
The UI allowed loading content from arbitrary URLs. There was no sufficiently strict Content Security Policy (CSP) to limit external scripts, images, or connections.
Lack of defense in depth
Even if the model created unsafe output, a strong CSP, cookie flags, Trusted Types, and HTML sanitization would have blunted or blocked the attack.
Minimal permission boundaries
Support consoles often run with wide permissions and broad network access. An attacker who lands there has room to move.

When several “soft spots” line up, the path from prompt to compromise gets short.

Why this matters: beyond cookie theft

Stealing a session cookie is bad. But the real risk is what that cookie unlocks — and what other code could execute in that context.

Potential business impacts include:

Account and session hijacking
Use a support agent’s session to access internal support tools and customer data.
Data exposure and manipulation
Read chat histories, view PII, or modify records.
Lateral movement
Abuse single sign-on, APIs, or internal dashboards to pivot deeper into the network.
Phishing and credential theft
Inject malicious UI overlays, popup “updates,” or fake login prompts.
Regulatory and legal exposure
A data breach here could trigger notification requirements and potential fines under GDPR/CCPA.
Brand damage and trust loss
Security failures in customer-facing AI erode confidence fast.

As the Cybernews team warned: this wasn’t limited to cookie theft. If unsafe code execution is possible in the agent environment, the door opens to keylogging, redirection, data exfiltration, and potentially more.

Lessons for every company shipping AI chatbots

Here’s the no-spin version: treat everything that touches an LLM — inputs and outputs — as untrusted. Then build your defenses like you would for any untrusted content source.

Consider this your practical checklist.

1) Default to “plain text,” not HTML

Render chatbot responses as plain text by default.
If you must support rich text, use a strict allowlist and convert via a hardened pipeline (e.g., Markdown → sanitized HTML).
Use well-maintained sanitizers in locked-down mode (e.g., DOMPurify with strict config, OWASP Java HTML Sanitizer).
Remove or neuter:
Inline event handlers (onerror, onclick, etc.)
JavaScript URLs and data URLs
iframes, forms, SVG/MathML where not needed
style attributes and CSS that can execute or exfiltrate

Reference: OWASP: XSS Prevention Cheat Sheet

2) Enforce a strict Content Security Policy (CSP)

CSP is your browser-level seatbelt. A strong policy can stop entire classes of XSS.

Start with restrictive defaults: default-src 'none'
Then allow only what you need:
script-src 'self' (no inline, no eval)
img-src 'self' data: only if necessary, otherwise restrict
connect-src to known APIs only
frame-ancestors to prevent clickjacking
base-uri 'none'
Add modern protections:
require-trusted-types-for 'script'
Use Trusted Types to block DOM sinks unless passed through approved sanitization

Learn more: MDN: Content Security Policy and web.dev: Trusted Types

3) Never execute model output

Don’t eval, compile, or auto-run scripts generated by the model.
Don’t auto-fetch resources URLs suggested by the model.
If your agent has tool-calling, restrict it with schemas, allowlists, and strict validation.
Sandboxing is essential. If you must render rich content, use a sandboxed, cross-origin iframe with no permissions.

4) Harden cookies and sessions

If an attacker somehow gets in, make those tokens hard to abuse.

Set cookies with HttpOnly, Secure, and appropriate SameSite flags.
Rotate sessions on privilege elevation and agent handoffs.
Shorten session lifetime for agent consoles.
Consider token binding or device binding where feasible.
Invalidate sessions quickly on suspected compromise.

Background: MDN: HTTP cookies

5) Treat LLM I/O as untrusted, end-to-end

Validate inputs: impose length limits, typed schemas, and disallow control directives where not needed.
Validate outputs: sanitize, strip, or transform before rendering; verify content types at every hop.
Sanitize before storage and again before display. Defense in depth matters.

For programmatic guidance, see NIST Secure Software Development Framework

6) Put a WAF and egress controls in the loop

Add WAF rules to flag and block patterns like event handler attributes, suspicious tags, and known exfiltration patterns.
Restrict agent workstation egress to approved domains. If a link points to an untrusted host, block or warn.

7) Red team your AI UI

Build adversarial prompts into CI/CD.
Test HTML/JS injection attempts in a safe, internal environment.
Run a private bug bounty with clear scope.
Log and alert on blocked CSP events and suspicious requests.

For LLM-specific threats and test ideas, see the OWASP Top 10 for LLM Applications.

8) Prepare for incident response

Have a kill switch to disable HTML rendering or the chatbot entirely.
Automate mass session revocation for agent accounts.
Monitor CSP violation reports and unusual outbound requests.
Document a coordinated disclosure process (see CISA: CVD Process).

How Lenovo responded — and what they did right

Cybernews followed responsible disclosure. Lenovo acknowledged the issue on August 6, 2025, and deployed mitigations before public disclosure on August 18, 2025. While details of the fix aren’t public, it’s reasonable to assume they tightened input/output handling and hardened server and client protections.

That matters. Companies that respond quickly, communicate clearly, and fix root causes build trust — even when a flaw is serious.

Are LLM “guardrails” enough? No — and here’s why

Guardrails, safety prompts, and classifiers are helpful. But they’re not a substitute for web security basics.

LLMs follow instructions. If you tell them “produce HTML,” they will — even when unsafe.
Safety filters reduce risk but don’t enforce browser-level policies.
Only engineering controls like sanitization, CSP, Trusted Types, and strict rendering choices can reliably block XSS.

As Girėnas noted: “We approach every AI input and output as untrusted until it’s verified safe. That mindset helps block prompt injections and other risks before they reach critical systems.”

In short: you can’t prompt your way out of cross-site scripting. You have to engineer it out.

How to safely render AI responses in the browser

If your chatbot needs formatting, adopt a layered, “belts-and-suspenders” approach:

Prefer Markdown over HTML. Convert with a strict, audited pipeline and allow only a minimal subset.
Sanitize aggressively. Disallow inline handlers, scripts, risky tags/attributes, and protocol handlers.
Use a strong CSP with no inline scripts and require-trusted-types-for 'script'.
Avoid dangerous API patterns like innerHTML. Use safe templating and framework defaults that escape by default (e.g., React without dangerouslySetInnerHTML).
Isolate rich content in a sandboxed, cross-origin iframe with no permissions if absolutely necessary.
Strip or rewrite links. Disable automatic linking of URLs, or route through safe redirectors with scanning.
Instrument and observe. Log CSP violations, blocked events, and outbound requests from agent consoles.

None of this is exotic. It’s disciplined, boring, and proven. That’s what you want for defense.

Quick diagnostic: 10-minute internal audit for your AI chat

Run these checks in a safe, internal environment (never against third-party systems):

Do chatbot responses ever get rendered as HTML in an agent console or web UI?
Is there a CSP? Is it strict (no inline scripts, minimal sources)? Check browser devtools.
Do you see framework code paths using innerHTML/outerHTML or equivalents?
Can users influence output format (e.g., “respond in HTML”)? If yes, is it sanitized or blocked?
Are cookies for the console set with HttpOnly, Secure, and appropriate SameSite?
Does the console load images/scripts from arbitrary domains? If yes, that’s a red flag.
Are model outputs stored and later re-rendered? If yes, sanitize at write and at read.
Is there network egress control from agent machines to unknown hosts?
Do you collect CSP reports? Any recent spikes?
Is there a kill switch to disable rich rendering if needed?

If you answer “no” or “not sure” to several of these, prioritize a remediation sprint. You’ll sleep better.

The bigger picture: AI velocity vs. security debt

Companies are moving fast to ship AI — faster than their security practices are evolving. That’s where attackers slip in. The Lenovo incident shows how tiny gaps (like rendering model output as HTML) can create outsized risk.

This doesn’t mean slow down innovation. It means weave security into the AI lifecycle:

Design for untrusted I/O from day one
Automate sanitization and policy checks in CI/CD
Instrument UIs and backends for visibility
Red team regularly, not just once
Make mitigation and kill switches part of your runbook

AI can absolutely be shipped safely. But only when product, security, and engineering pull together.

FAQs: What people are asking

What is XSS and how can a chatbot be vulnerable?

Cross-Site Scripting (XSS) is when untrusted content gets rendered in the browser and executes code in the user’s context. Chatbots are vulnerable when they render model output as HTML (or rich content) without strict sanitization and a strong CSP. Learn more: OWASP: XSS

How can a single prompt lead to code execution?

If the application allows the model to emit HTML (or otherwise control the UI), a prompt can instruct the model to include malicious markup. If that markup is stored and later rendered, the browser executes it. The key failure is trusting model output and rendering it unsafely.

Are LLM guardrails enough to prevent this?

No. Safety prompts and classifiers help, but only browser and server defenses — like sanitization, CSP, Trusted Types, cookie flags, and strict rendering — reliably block XSS.

How can companies stop cookie theft via chatbots?

Render model output as plain text or sanitized, minimal HTML
Enforce a strict CSP and Trusted Types
Use HttpOnly, Secure, and SameSite cookie settings
Restrict network egress from agent consoles
Monitor for CSP violations and suspicious outbound requests See: MDN: HTTP cookies and MDN: CSP

Did Lenovo fix the issue?

According to the disclosure timeline, Lenovo acknowledged the report on August 6, 2025, and mitigated the issue before August 18, 2025. Public disclosure occurred on August 18, 2025.

Is this unique to Lenovo?

No. Any AI chatbot that renders model output without strict controls is at risk. This is a platform-agnostic problem that affects all LLM-integrated web apps.

Should we disable HTML entirely in chatbots?

When in doubt, yes. Most customer support use cases work fine with plain text or a tightly sanitized Markdown subset. If you must allow rich content, lock it down aggressively and isolate it.

What’s a good baseline CSP for AI UIs?

Start with default-src 'none', then explicitly allow only required sources. Disallow inline scripts and eval. Add require-trusted-types-for 'script' and adopt Trusted Types to protect DOM sinks. See: MDN: CSP and web.dev: Trusted Types

What’s “prompt injection,” and is it the same as XSS?

Prompt injection targets the model’s instructions, getting the LLM to do things outside its intended behavior. XSS targets the browser by executing code in the user’s context. In this incident, prompt injection was used to cause the model to emit dangerous HTML — which then enabled XSS. Both must be defended against.

How should we handle responsible disclosure?

Publish a clear policy, respond quickly, triage with severity, fix root causes, and credit reporters. See: CISA: Coordinated Vulnerability Disclosure

Final takeaway

Lenovo’s Lena incident is a reminder that old web risks don’t vanish in the age of AI — they resurface in new wrappers. The fix isn’t magic. It’s the fundamentals: don’t trust model output, sanitize aggressively, enforce a strong CSP, and never auto-execute anything the model generates.

If you own an AI chatbot or plan to ship one, run the 10-minute audit above this week. Then prioritize a hardening sprint. Your customers — and your incident response team — will thank you.

Want deeper guides on AI security patterns and practical checklists? Subscribe to get our next breakdown, including a production-ready CSP template and a safe Markdown rendering pipeline.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring!

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

The Tragic Link Between NHS Cyber-Attacks and Patient Safety: Lessons from the Synnovis Ransomware Incident

How to Comply with NIS2 Directive: Policies and Procedures for Cryptography and Encryption

Can Hackers Take the Wheel? The Real Cybersecurity Risks of Self‑Driving Cars

SQL Injection Explained: What It Is, How Attacks Work, and How to Stop Them