CVE-2026-106102: Quasar Framework: Stored/Reflected XSS via unescaped SSR meta tag rendering in getHead()

## Vulnerability Details **File**: `ui/src/utils/meta/Meta.js` — actually `ui/src/plugins/meta/Meta.js` (lines 149-176: `getAttr()` and `getHead()`) **Sink**: `injectServerMeta()` (same file) → `ctx.headTags += getHead(data)`, interpolated verbatim into the raw HTTP response `<head>` by the production SSR template (`app-vite/templates/entry/ssr-prod-webserver.js` + `app-vite/lib/plugins/vite.html.js`) **Entry point**: the public `useMeta()` composable (`ui/src/composables/use-meta/use-meta.js`) — the single documented way apps set page title/meta/link/script tags ### Root Cause `getHead()` is Quasar's SSR-only serializer that turns the meta/link/script/title data collected from every `useMeta()` call into a literal HTML string, using plain template-literal interpolation with **zero HTML-entity escaping and zero attribute-quote escaping**: ```js function getAttr(seed) { return att => { const val = seed[att] return att + (val !== true && val !== void 0 ? `="${val}"` : '') } } function getHead(meta) { let output = '' if (meta.title) { output += `<title>${meta.title}</title>` } ... } ``` Contrast this with the client-side equivalent, `apply()` (same file, used only in the browser post-hydration), which builds the same tags via `document.createElement(...)` + `tag.setAttribute(att, val)` — the browser DOM API automatically escapes attribute values, so **the client-side path is not vulnerable**. `getHead()` is a separate, parallel implementation for the SSR case that never received the same protection. Any string containing `</title>`, `"`, or `>` in a `title`, `meta.*.content`, `link.*.href`, or any other attribute value passed to `useMeta()` breaks out of its intended HTML context and injects arbitrary markup — including a live `<script>` tag — directly into the raw HTML response sent to every visitor. ### Attack Scenario 1. A Quasar SSR application renders dynamic page metadata via the standard, documented `useMeta()` pattern — e.g. `useMeta(() => ({ title: post.title, meta: { description: { name: 'description', content: post.excerpt } } }))` for a blog/CMS/product page. 2. An attacker who can influence that underlying text (submit a blog post/comment, set their own profile display name, control a field in an integrated CMS/API) sets it to `My Post</title><script>alert(document.cookie)</script>`. 3. On every SSR render of that page — for every visitor — `getHead()` emits this payload unescaped directly into the `<head>` of the raw HTML response. 4. The victim's browser parses the HTML top-to-bottom; the injected `<script>` executes immediately, before hydration, with full access to `document.cookie` and the DOM. ### Impact - **Type**: CWE-79 Cross-Site Scripting - **Auth required**: No (attacker only needs to influence any text that reaches `useMeta()` — an extremely common pattern, e.g. blog titles, product names, user display names) - **Consequence**: Full client-side script execution in the victim site's origin — session/cookie theft, credential phishing overlays, account takeover, defacement. Unlike a typical XSS bug requiring a specific unusual injection point, this affects the single most common `useMeta()` use case (rendering any dynamic title/description), so it can be triggered even by ordinary content containing `&`, `<`, or `"` without malicious intent, in addition to being trivially exploitable deliberately. ### Vulnerable Code (`ui/src/plugins/meta/Meta.js` lines 149-176) ```js function getAttr(seed) { return att => { const val = seed[att] return att + (val !== true && val !== void 0 ? `="${val}"` : '') } } function getHead(meta) { let output = '' if (meta.title) { output += `<title>${meta.title}</title>` } ;['meta', 'link', 'script'].forEach(type => { const metaType = meta[type] for (const att in metaType) { const attrs = Object.keys(metaType[att]) .filter(item => item !== 'innerHTML') .map(getAttr(metaType[att])) output += `<${type} ${attrs.join(' ')} data-qmeta="${att}">` if (type === 'script') { output += (metaType[att].innerHTML || '') + '</script>' } } }) return output } ``` ### Recommended Fix ```js function escapeHtml(val) { return String(val) .replaceAll('&', '&amp;') .replaceAll('<', '&lt;') .replaceAll('>', '&gt;') .replaceAll('"', '&quot;') } function getAttr(seed) { return att => { const val = seed[att] return att + (val !== true && val !== void 0 ? `="${escapeHtml(val)}"` : '') } } function getHead(meta) { let output = '' if (meta.title) { output += `<title>${escapeHtml(meta.title)}</title>` } // ... rest unchanged, script innerHTML intentionally left raw (JSON-LD use case) } ``` ### Verification Confirmed end-to-end on v2.21.1 via a local Node.js HTTP lab harness that imports the real, unmodified `Meta.js` source and reproduces the exact `useMeta()` → `injectServerMeta()` call sequence a real SSR app performs, reached via actual `curl` requests (not just isolated function calls): 1. `POST /submit` with `{"title":"My Post</title><script>alert(document.cookie)</script>","description":"\"><script>alert(document.domain)</script>"}` 2. `GET /render/1` returned a raw HTTP response whose `<head>` contained: `<title>My Post</title><script>alert(document.cookie)</script></title><meta name="description" content=""><script>alert(document.domain)</script>" data-qmeta="description">` 3. Verified via `grep`: 0 occurrences of `&lt;` (nothing was escaped), 1 occurrence of a literal, unescaped `<script>alert(...)</script>` tag in the actual HTTP response body. A fix branch (`fix/xss-meta-tag-escaping`) is ready with the minimal patch above (adds an `escapeHtml()` helper used in `getAttr()`/`getHead()`); re-running the same PoC against the patched code shows the payload fully HTML-entity-encoded (`&lt;script&gt;...`) with no live `<script>` tag, while normal titles containing `&` still render correctly (`&amp;`).