HTML Injection vulnerability in check-code pages using dangerouslySetInnerHTML

[lyzno1]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

main

Cloud or Self Hosted

Cloud

Steps to reproduce

1. Navigate to any check-code page with malicious email parameter:

   http://localhost:3000/signin/check-code?email=test@example.com<script>alert('XSS')</script>
   

2. Observe the page rendering behavior

Expected Behavior

The email address should be displayed as plain text with HTML tags visible as literal characters:

We send a verification code to test@example.com<script>alert('XSS')</script>

✔️ Expected Behavior

The email address should be displayed as plain text with HTML tags visible as literal characters:

We send a verification code to test@example.com<script>alert('XSS')</script>

❌ Actual Behavior

Code-level vulnerability exists: The application uses dangerouslySetInnerHTML with unvalidated user input from URL parameters:

<span dangerouslySetInnerHTML={{ __html: t('login.checkCode.tips', { email }) as string }}></span>

Where email comes directly from:

const email = decodeURIComponent(searchParams.get('email') as string)

[dosubot]

This is a confirmed XSS vulnerability: the check-code pages use dangerouslySetInnerHTML to render a translation string with the email parameter directly from the URL, without any sanitization or escaping. This allows attackers to inject arbitrary HTML or JavaScript via the email query parameter, which will be executed in the browser context (console check-code page, webapp-signin check-code page, reset-password check-code page).

To fix this, avoid passing user input to dangerouslySetInnerHTML. Instead, render the email as a plain text node, or escape the email value before interpolation. For example, split the translation string so only the static HTML is rendered with dangerouslySetInnerHTML, and insert the email as a child node, or use a library like he to escape HTML entities in the email before rendering. This will prevent any injected HTML or scripts from being executed.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[lyzno1]

Hi @crazywoola, I noticed that the related issue was assigned to someone else after I opened this PR.

Just wanted to check — is there anything in the PR that needs to be improved, or is this the kind of issue that’s typically handled by core maintainers?

Happy to revise or assist in any way. Thanks!

[crazywoola]

Hi @crazywoola, I noticed that the related issue was assigned to someone else after I opened this PR.

Just wanted to check — is there anything in the PR that needs to be improved, or is this the kind of issue that’s typically handled by core maintainers?

Happy to revise or assist in any way. Thanks!

@douxc is our team member, this one needs to be reviewed by him.