Quasar Framework vulnerabilities

Quasar Framework before 2.22.0 has a vulnerability in the SSR-only getHead() serializer that fails to properly encode values supplied via useMeta(). An attacker who can influence dynamic page metadata can inject executable HTML markup before hydration. The client-side path is not affected because it uses DOM APIs that encode attributes.

Quasar Framework is a framework for building high-performance Vue.js user interfaces. From 3.1.0 until 3.3.0, @quasar/app-vite SSG page definitions returned by getSsgPages() could supply dir and filename values that were joined to build.distDir without verifying the final destination. Parent traversal or an existing symlink below the distribution directory could create new HTML files or directories outside the output tree with the build user's permissions.

In Quasar Framework from 1.0.0 to 3.3.0, @quasar/app-vite recursively removed the resolved build.distDir before building without rejecting the project root, user home directory, filesystem roots, or symlink-resolved external directories. An unsafe trusted configuration can delete data writable by the build user before compilation begins. No attacker-controlled input reaches build.distDir by default, so exploitation requires compromised or less-trusted automation or a mistaken configuration. Fixed in 3.3.0.

Quasar Framework prior to 3.3.0, in several @quasar/app-vite SSR and SSG rendering paths, interpolates ssrContext.nonce directly into quoted HTML attributes. An application that derives or overrides this value with attacker-controlled data can allow a quote to terminate the nonce attribute and inject additional attributes or markup into generated HTML. Cryptographically generated base64 or base64url nonces are not affected because they lack HTML attribute delimiters. The issue is fixed in version 3.3.0.

Quasar Framework prior to @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0: renderSSRError() in utils/render-ssr-error/src/index.js used diagnostic data from utils/render-ssr-error/src/env.js to serialize process.env, request headers, and cookies into the HTTP page returned by serve.devError(), while the development server listened on all interfaces by default. Any network-adjacent client that reaches an SSR or SSG render failure through this development-only error path can obtain shell environment secrets. The renderer escaped only one exact lowercase script closing-tag spelling, so case variants and valid closing-tag delimiter variants could terminate the script element and inject markup. The issue is fixed in @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0.

Quasar Framework prior to @quasar/ssl-certificate 2.1.0, @quasar/cli 5.0.4, and @quasar/app-vite 3.3.0 caches a combined private key and certificate PEM without explicitly applying owner-only filesystem permissions. Another local user able to read the cache can copy the key and impersonate a development TLS endpoint in an environment that trusts the certificate. The generated certificate was also CA-capable, carried unnecessarily broad key usages, and encoded the IPv6 loopback address as a DNS subject alternative name.

Quasar Framework prior to 2.23.3 passes an unbounded User-Agent request header to getMatch() in Platform.parseSSR(), whose browser-detection expressions combined greedy captures with repeated unbounded scans, causing super-linear backtracking and blocking the Node.js event loop. A crafted unauthenticated request can delay every other SSR request. SPA, PWA, Electron, Cordova, Capacitor, browser-extension, and static-site-generation targets are not affected.

Quasar Framework prior to @quasar/icongenie 6.1.1 allows path traversal in the icongenie generate --profile command. Folder and name values from a user-supplied profile are not constrained to the Quasar project directory, allowing parent-directory traversal. A developer running a crafted profile can cause generated image content to be written or overwritten at any path writable by that user, potentially modifying shell startup files, build scripts, or other executable configuration.

In Quasar Framework prior to 2.32.2, the openURL() utility trusted window.SafariViewController whenever that global existed in an iOS environment. Attacker-controlled HTML rendered by components such as QEditor can create a named SafariViewController element, causing browser named-property resolution to replace the expected native bridge object. A later openURL() call then invokes isAvailable() on the element, throws a TypeError, and disrupts external navigation, login redirects, payment redirects, and other URL-opening workflows.

Quasar Framework prior to 2.22.0 contains a vulnerability in the public extend() utility in ui/src/utils/extend/extend.js that recursively copied attacker-controlled object keys during extend(true, target, source) deep merges without rejecting an own __proto__ property. The merge could descend into the prototype object and write attacker-controlled properties to Object.prototype in the same JavaScript process. Applications that passed user-controlled or partially user-controlled objects to extend() could experience logic bypass, unsafe default-option injection, denial of service, or other application-specific impact when polluted properties were later consumed. This issue is fixed in version 2.22.0.