svelte-devtools

Summary Svelte DevTools injects a MAIN-world content script (courier.js, built from src/client/core.js) into every page (, document_start, world: "MAIN"). This script -- and a second, dynamically-injected ISOLATED-world relay in background.js -- bridge page/hook state to the DevTools panel purely via window.postMessage({source: 'svelte-devtools', ...}), gated only by event.source === window and a constant string marker. Because the MAIN-world script shares the exact JS realm as the inspected page, any JavaScript running in the top-level page can call window.postMessage directly and impersonate the extension's real component-tree hook -- no browser-authoritative signal is checked, only a publicly-known string shipped in the extension's own source. One forgeable message type, bridge::courier/node->add, is accepted panel-side with zero validation of any field in payload.node (including its id), stored into app.nodes, and rendered as a tree entry. When the developer clicks that fake node and interacts with any editable property, the panel builds a JS source string containing the unescaped node.id and passes it to chrome.devtools.inspectedWindow.eval(): uuid is never escaped (unlike value, which IS correctly escaped), so a single quote in a forged id breaks out and appends arbitrary JS, executed via the DevTools eval sink -- bypassing the inspected page's own CSP. Root cause and : only proves same-window delivery, not extension origin. (bridge::courier/node->add) does no validation on payload.node. : Only value is escaped. The receiving sink silently no-ops on an unmatched id (no throw), so trailing injected statements execute normally. Proof of concept Isolated re-run of the exact vulnerable string-building logic and the exact real no-throw sink semantics, standalone in Node: Output: Full attack outline (traced through real source, not driven in a live browser): 1. Developer opens DevTools with the Svelte panel on an attacker/compromised page. 2. Page JS: . 3. Relayed unmodified through background.js -> panel -> app.nodes[forgedId] = forgedNode, rendered as a real-looking tree entry. 4. Developer clicks the fake component and blurs any editable property field (no actual edit required -- onchange fires on blur regardless). 5. inject() builds the malicious eval string and inspectedWindow.eval() executes attacker JS in the inspected page, bypassing page CSP. Impact An attacker page (or any page with a pre-existing JS-execution bug) can plant fake entries into the component tree shown to a developer with this extension's DevTools panel open on that tab, and with one click+blur achieve arbitrary JS execution in the inspected page's MAIN-world context, bypassing that page's CSP. Realistic targets: security researchers/bug hunters who open DevTools with this extension while triaging untrusted pages. Areas checked clean No {@html}/innerHTML/outerHTML anywhere in src/. Cross-frame forgery is blocked (no all_frames:true, event.source check correctly rejects iframe-relayed messages). Extension-side port handshake correctly checks sender.id/sender.url. No other eval(/new Function( usage in src/. Suggested fix 1. Don't trust a public string constant as the sole auth for the page->extension leg -- validate every field of payload.node against an expected shape. 2. Never string-interpolate uuid/keys into the inspectedWindow.eval() source; JSON.stringify() them, or avoid building a source string entirely. 3. Consider deriving id server-side rather than trusting a claimed component id. Disclosure note No SECURITY.md, no bounty program. Repo appears largely unmaintained (last master commit 2024-11-01), so filing publicly rather than chasing a private contact for a dormant project. This report and PoC were produced with AI assistance (Claude, Anthropic). All findings are traced to and quoted from the actual repository source, and the eval-string breakout was independently re-run in an isolated Node.js environment against the extracted vulnerable logic. No live browser/DevTools session was used for the full click-through chain -- confirm end-to-end by loading the unpacked extension, opening DevTools on a test page, and running the PoC window.postMessage call from that page's console.

Thanks for the work on svelte-devtools! I’m evaluating it for a project using Svelte 5, and I noticed the current README lists support for Svelte ^4.0.0 only. I had a couple questions: Is this project still actively maintained? Is Svelte 5 support planned (especially for runes-based apps)? If so, is there a rough roadmap or milestone for compatibility?

Added display of unsupported Svelte version message in dev tools. Also implemented Svelte version detection per browser tab, fixing an unrelated bug where the Svelte logo style would change across different browser windows based on the active tab. Closes https://github.com/sveltejs/svelte-devtools/issues/242