Summary
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:
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
- 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. - 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>. - On every SSR render of that page, for every visitor,
getHead()emits this payload unescaped directly into the<head>of the raw HTML response. - The victim's browser parses the HTML top-to-bottom; the injected
<script>executes immediately, before hydration, with full access todocument.cookieand the DOM.
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
}
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):
POST /submitwith{"title":"My Post</title><script>alert(document.cookie)</script>","description":"\"><script>alert(document.domain)</script>"}GET /render/1returned 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">- 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 (&).
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.
Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.
CVE-2026-106102 has a CVSS score of 10.0 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.22.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
function escapeHtml(val) {
return String(val)
.replaceAll('&', '&')
.replaceAll('<', '<')
.replaceAll('>', '>')
.replaceAll('"', '"')
}
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)
}
Frequently Asked Questions
- What is CVE-2026-106102? CVE-2026-106102 is a critical-severity cross-site scripting (XSS) vulnerability in quasar (npm), affecting versions < 2.22.0. It is fixed in 2.22.0. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
- How severe is CVE-2026-106102? CVE-2026-106102 has a CVSS score of 10.0 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of quasar are affected by CVE-2026-106102? quasar (npm) versions < 2.22.0 is affected.
- Is there a fix for CVE-2026-106102? Yes. CVE-2026-106102 is fixed in 2.22.0. Upgrade to this version or later.
- Is CVE-2026-106102 exploitable, and should I be worried? Whether CVE-2026-106102 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-106102 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-106102? Upgrade
quasarto 2.22.0 or later.