GHSA-pq96-jpmf-w254

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:

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)

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

function escapeHtml(val) {
  return String(val)
    .replaceAll('&', '&')
    .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 < (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 (<script>...) with no live <script> tag, while normal titles containing & still render correctly (&).