Skip to content

[DevTools] Fix XSS in standalone onError via innerHTML#36431

Open
tomohiro86 wants to merge 1 commit intofacebook:mainfrom
tomohiro86:fix/devtools-standalone-xss
Open

[DevTools] Fix XSS in standalone onError via innerHTML#36431
tomohiro86 wants to merge 1 commit intofacebook:mainfrom
tomohiro86:fix/devtools-standalone-xss

Conversation

@tomohiro86
Copy link
Copy Markdown

@tomohiro86 tomohiro86 commented May 7, 2026

Summary

In packages/react-devtools-core/src/standalone.js, the onError function was interpolating a server error message string directly into an innerHTML template literal:

node.innerHTML = `
  <div class="box-content">
    ${message}
  </div>
`;

If the message string contained HTML (e.g. <img src=x onerror="...">) it would be parsed and executed by the browser.

This PR fixes it by setting the static HTML structure first, then assigning the message via textContent, which the browser treats as plain text and never interprets as markup.

node.innerHTML = `
  <div class="box">
    <div class="box-header">Unknown error</div>
    <div class="box-content"></div>
  </div>
`;
const contentNode = node.querySelector('.box-content');
if (contentNode !== null) {
  contentNode.textContent = message;
}

The message value comes from Node.js http.Server / net.Server error events (server.on('error', ...)). These are normally OS/network-level error strings and not directly attacker-controlled, so real-world exploitability is limited. Nevertheless the code structure allowed HTML injection and the fix is straightforward.

How did you test this change?

Manually verified that a normal server error (e.g. EACCES) still renders the error message as plain text in the standalone DevTools shell. No automated tests exist for this UI path in react-devtools-core.

Use textContent instead of template literal interpolation when
rendering error messages in the standalone DevTools shell to
prevent potential XSS from unescaped error message strings.
@meta-cla
Copy link
Copy Markdown

meta-cla Bot commented May 7, 2026

Hi @tomohiro86!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

@meta-cla
Copy link
Copy Markdown

meta-cla Bot commented May 7, 2026

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

@meta-cla meta-cla Bot added the CLA Signed label May 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant