deepseek-ai/DeepSeek-V3

Fork 0

mirror of https://github.com/deepseek-ai/DeepSeek-V3.git synced 2026-11-05 00:47:48 +00:00

[GH-ISSUE #1334] [CRITICAL BUG] "NON-SANDBOXED" XSS Web Vulnerability on chat.deepseek.com ==> 1 Click Account Takeover #878

New issue

Open

opened 2026-10-26 21:31:33 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

2026-10-26 21:31:33 +00:00

Owner

Originally created by @0xLuxieL on GitHub (May 19, 2026).
Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-V3/issues/1334

Hello DeepSeek Team,

(Note: I realize this repository is for the DeepSeek-V3 model, but I am opening this issue to urgently reach the internal security/web team regarding a critical vulnerability on the main chat interface).

I am writing to notify you that I have reported a severe vulnerability affecting the chat.deepseek.com web frontend.

The vulnerability allows for a 1-click Account Takeover (ATO) via Cross-Site Scripting (XSS) in shared chat links. Importantly, the XSS reflection is not sandboxed by any means—it executes directly within the origin context of https://chat.deepseek.com/. and exfiltrates authenticated user sessions enabling the account takeover.

I have already sent the full technical write-up, including a weaponized Proof-of-Concept and a video demonstration for 1 Click ATO, directly to both security@deepseek.com and service@deepseek.com.

Date Sent: May 15, 2026

Since this is a critical issue that is currently exploitable in production, I want to ensure the report did not get lost in a spam filter.

Could a maintainer please ping the internal web/security team to check their inbox and reply to my email to confirm receipt?

(For obvious security reasons, I am keeping this issue thread clean and will not share the payload, attack vector, or any technical details publicly.)

Thank you for your time and assistance!

Originally created by @0xLuxieL on GitHub (May 19, 2026). Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-V3/issues/1334 Hello DeepSeek Team, *(Note: I realize this repository is for the DeepSeek-V3 model, but I am opening this issue to urgently reach the internal security/web team regarding a critical vulnerability on the main chat interface).* I am writing to notify you that I have reported a severe vulnerability affecting the **chat.deepseek.com** web frontend. <img width="1915" height="992" alt="Image" src="https://github.com/user-attachments/assets/ad8f55c3-be26-4ccb-826e-d4b501b8f931" /> The vulnerability allows for a 1-click Account Takeover (ATO) via Cross-Site Scripting (XSS) in shared chat links. Importantly, the XSS reflection is **not sandboxed by any means**—it executes directly within the origin context of `https://chat.deepseek.com/`. and exfiltrates authenticated user sessions enabling the account takeover. I have already sent the full technical write-up, including a weaponized Proof-of-Concept and a video demonstration for 1 Click ATO, directly to both **security@deepseek.com** and **service@deepseek.com**. * **Date Sent:** May 15, 2026 Since this is a critical issue that is currently exploitable in production, I want to ensure the report did not get lost in a spam filter. Could a maintainer please ping the internal web/security team to check their inbox and reply to my email to confirm receipt? *(For obvious security reasons, I am keeping this issue thread clean and will not share the payload, attack vector, or any technical details publicly.)* Thank you for your time and assistance!

bsakaguchi commented

2026-10-26 21:31:34 +00:00

Author

Owner

@darkemil2000-arch commented on GitHub (May 19, 2026):

Поддержите идею #1328

@darkemil2000-arch commented on GitHub (May 19, 2026): Поддержите идею #1328

bsakaguchi commented

2026-10-26 21:31:34 +00:00

Author

Owner

@0xLuxieL commented on GitHub (Jun 3, 2026):

https://github.com/user-attachments/assets/fe3344c7-fc9e-4966-9bbc-85dcbf406f0d

@0xLuxieL commented on GitHub (Jun 3, 2026): https://github.com/user-attachments/assets/fe3344c7-fc9e-4966-9bbc-85dcbf406f0d

bsakaguchi commented

2026-10-26 21:31:34 +00:00

Author

Owner

@qingkong66 commented on GitHub (Jun 4, 2026):

@0xLuxieL Thanks for adding the PoC video.

This is already recorded in the community digest and has been sent to security@deepseek.com. No further details should be discussed here publicly.

We're tracking this for the June summary and will continue to push for an official response.

@qingkong66 commented on GitHub (Jun 4, 2026): @0xLuxieL Thanks for adding the PoC video. This is already recorded in the community digest and has been sent to security@deepseek.com. No further details should be discussed here publicly. We're tracking this for the June summary and will continue to push for an official response.

bsakaguchi commented

2026-10-26 21:31:34 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 8, 2026):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

@github-actions[bot] commented on GitHub (Jul 8, 2026): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

bsakaguchi commented

2026-10-26 21:31:34 +00:00

Author

Owner

@rehan243 commented on GitHub (Jul 9, 2026):

oh wow, that "NON-SANDBOXED" bit you called out is pretty bad, if it really runs in the origin context like you said, that's about as critical as it gets. I've seen this with chat apps before, where the shared link feature just spits back user input without any escaping. Honestly, it's usually a frontend render thing, but sometimes the backend is guilty too, depends if they're using something like dangerouslySetInnerHTML in React or just raw JS like

document.body.innerHTML = userInput; // don't do this

the docs for most frameworks warn against this but it keeps popping up. If you've already mailed security@deepseek.com and service@deepseek.com with the PoC, that's the right move, I've had reports slip through the cracks when the team changes mailbox filters or gets a flood of spam. Not gonna lie, took me a few tries to get other vendors to actually respond in the past, so posting here makes sense. For anyone reading who touches the code, sanitizing or escaping any user-generated content fixes most of this, something like DOMPurify or even just replacing dangerous tags before rendering:

const safeInput = DOMPurify.sanitize(userInput);
document.body.innerHTML = safeInput;

the thing is, you really can't trust any input, even if it's from "trusted" users. If this is still live, someone should yank the shared link feature down until it's patched.

@rehan243 commented on GitHub (Jul 9, 2026): oh wow, that "NON-SANDBOXED" bit you called out is pretty bad, if it really runs in the origin context like you said, that's about as critical as it gets. I've seen this with chat apps before, where the shared link feature just spits back user input without any escaping. Honestly, it's usually a frontend render thing, but sometimes the backend is guilty too, depends if they're using something like dangerouslySetInnerHTML in React or just raw JS like ```js document.body.innerHTML = userInput; // don't do this ``` the docs for most frameworks warn against this but it keeps popping up. If you've already mailed security@deepseek.com and service@deepseek.com with the PoC, that's the right move, I've had reports slip through the cracks when the team changes mailbox filters or gets a flood of spam. Not gonna lie, took me a few tries to get other vendors to actually respond in the past, so posting here makes sense. For anyone reading who touches the code, sanitizing or escaping any user-generated content fixes most of this, something like DOMPurify or even just replacing dangerous tags before rendering: ```js const safeInput = DOMPurify.sanitize(userInput); document.body.innerHTML = safeInput; ``` the thing is, you really can't trust any input, even if it's from "trusted" users. If this is still live, someone should yank the shared link feature down until it's patched.

bsakaguchi commented

2026-10-26 21:31:35 +00:00

Author

Owner

@qingkong66 commented on GitHub (Jul 10, 2026):

@rehan243

I am tracking this thread. Your assessment of the severity — and your note about the shared link feature being a likely entry point — matches what I observed when this was first reported.

I have recorded this issue in the June community summary as a critical, unpatched security report.

Your suggested fix direction (input sanitization / DOMPurify) and the temporary mitigation (pull the shared link feature until patched) are both noted.

The same dynamic — security reports going unanswered through official channels — is why this is being tracked here. Thank you for adding your read on it.

— qingkong66

@qingkong66 commented on GitHub (Jul 10, 2026): @rehan243 I am tracking this thread. Your assessment of the severity — and your note about the shared link feature being a likely entry point — matches what I observed when this was first reported. I have recorded this issue in the June community summary as a critical, unpatched security report. Your suggested fix direction (input sanitization / DOMPurify) and the temporary mitigation (pull the shared link feature until patched) are both noted. The same dynamic — security reports going unanswered through official channels — is why this is being tracked here. Thank you for adding your read on it. — qingkong66