Quasar
Monthly
Cross-site scripting in @quasar/app-vite (Quasar Framework) SSR and SSG rendering paths prior to 3.3.0 allows HTML attribute and markup injection when an application derives or overrides ssrContext.nonce from attacker-controllable data instead of relying on Quasar's default cryptographically generated base64/base64url nonce. The flaw is exploitable remotely and unauthenticated in the sense that no privileges are required on the server side (CVSS PR:N), but it is inert under default configuration: a quote character must survive into the nonce value, and the poisoned server-rendered page must then be loaded by a victim, so exploitability is contingent on the application's own nonce handling (independent assessment rates it AV:N/AC:H and requires user interaction). There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the issue is fixed in version 3.3.0.
Quasar Framework's development-only SSR/SSG error handler (@quasar/render-ssr-error before 2.2.4 and @quasar/app-vite before 3.3.0) serializes the developer's shell environment variables, request headers, and cookies into the HTML error page produced by serve.devError(), and because the dev server listens on all interfaces by default, any network-adjacent client that can provoke a render failure can read those secrets without authentication. The same page escaped only the exact lowercase '</script>' spelling, so case variants or alternate closing-tag delimiters reflected in diagnostic data can terminate the script element and inject markup; for that injected code to execute in a browser it must accompany the developer's own request, which is why user interaction and high attack complexity apply. The issue is fixed in @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0 (commit 61c2bd8, advisory GHSA-r5mf-4r5x-q78f); no public exploit identified at time of analysis, and production SSR builds are unaffected - this is a developer-workstation-scoped risk rather than a broad production threat.
Insecure file permissions in Quasar's development TLS certificate utility (@quasar/ssl-certificate before 2.1.0, shipped via @quasar/cli before 5.0.4 and @quasar/app-vite before 3.3.0) let another local, unprivileged user on the same host read the cached combined private key and certificate PEM and then impersonate the developer's localhost HTTPS endpoint in any environment that trusts that certificate. The flaw is a local, low-privilege information-disclosure and impersonation issue (CWE-732) rather than a remotely exploitable critical condition: it only matters on multi-user, non-Windows machines (shared workstations, CI/build servers, container hosts) where at least one other local account exists and the generated dev certificate is actually trusted. Additional weaknesses compound the exposure - the generated certificate was CA-capable, carried unnecessary key usages, and encoded the IPv6 loopback address as a DNS SAN - but the practical impact remains bounded by the local-attacker prerequisite; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV) for this CVE. Vendor-released fixes are available in @quasar/ssl-certificate 2.1.0, @quasar/cli 5.0.4 and @quasar/app-vite 3.3.0.
Unauthenticated remote attackers can stall server-side rendering in Quasar Framework versions prior to 2.23.3 by sending a crafted User-Agent header that triggers catastrophic regex backtracking in Platform.parseSSR(). Because Platform is an auto-installed plugin, the header is parsed before routing on every SSR request, so a single malformed request keeps the Node.js event loop busy and delays or blocks all other SSR traffic - an availability-only impact (CVSS 4.0 base 8.7; our assessment CVSS 3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Only SSR targets are exposed; SPA, PWA, Electron, Cordova, Capacitor, browser-extension, and static-site-generation builds never feed an attacker-controlled header into this path. No public exploit identified at time of analysis, and no CISA KEV listing or EPSS score was provided in the source data.
Path traversal in @quasar/icongenie versions before 6.1.1 lets a crafted profile cause the icongenie generate --profile command to write generated image content to any path writable by the invoking developer, enabling overwrite of shell startup files, build scripts, or other executable configuration. Exploitation requires the developer to run the command against an attacker-supplied profile (UI:R) and gives no direct remote access; no public exploit code identified at time of analysis, and the issue is fixed in 6.1.1.
Server-side cross-site scripting in Quasar Framework's SSR meta plugin (versions prior to 2.22.0) allows remote attackers who can influence dynamic page metadata - such as a post title, product name, excerpt, or display name - to inject executable markup into the server-rendered HTML before hydration. The flaw is in the getHead() serializer, which interpolates values supplied through useMeta() into title, meta, link, and script tags without HTML text or quoted-attribute encoding, while the client-side apply() path is unaffected because it relies on DOM APIs that encode attributes. Exploitation requires the target application to run Quasar in SSR mode and to feed attacker-influenceable data into useMeta() without prior sanitization, and a victim must load the affected page for the injected script to run; no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and the 10.0 CVSS base score overstates the universal real-world risk given these preconditions. The issue is fixed in version 2.22.0.
The @quasar/app-vite build tooling (versions 1.0.0 through pre-3.3.0) recursively deletes the resolved build.distDir path before compilation without validating that the target is a safe location, so a dangerous distDir setting - a filesystem root, the user's home directory, the project root, or a symlink resolving outside the project - can cause destructive deletion of data writable by the build user. Authentication and interaction are constrained: per the assessed vectors (CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:A and CVSS:3.1/AV:L/AC:H/PR:H/UI:R) this requires local, high-privileged access and deliberate build invocation, and no attacker-controlled input reaches build.distDir by default, so exploitation depends on compromised or less-trusted automation influencing the build configuration or a developer authoring a mistaken configuration. This is a low-to-medium real-world risk that should NOT be treated as an urgent priority; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the impact is bounded to availability (data loss), with no confidentiality or integrity impact in the assessed vector.
On iOS builds of Quasar Framework (all versions prior to 2.32.2), the openURL() utility can be tricked into invoking attacker-controlled page content instead of the native SafariViewController bridge, breaking external navigation, login redirects, and payment redirects with a thrown TypeError. The trigger requires an app built for iOS (Cordova/Capacitor where Platform.is.ios is true) plus a QEditor, QSelect, or QChatMessage configured to render untrusted HTML that can define an element named 'SafariViewController'; a legitimate user must then attempt a URL-opening action. Impact is limited to denial of the URL-opening function (CVSS 3.1, AV:N/AC:H/PR:N/UI:R, C:N/I:N/A:L) and the bug is fixed in 2.32.2; no public exploit code or confirmed active exploitation was identified at time of analysis.
Cross-site scripting in @quasar/app-vite (Quasar Framework) SSR and SSG rendering paths prior to 3.3.0 allows HTML attribute and markup injection when an application derives or overrides ssrContext.nonce from attacker-controllable data instead of relying on Quasar's default cryptographically generated base64/base64url nonce. The flaw is exploitable remotely and unauthenticated in the sense that no privileges are required on the server side (CVSS PR:N), but it is inert under default configuration: a quote character must survive into the nonce value, and the poisoned server-rendered page must then be loaded by a victim, so exploitability is contingent on the application's own nonce handling (independent assessment rates it AV:N/AC:H and requires user interaction). There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the issue is fixed in version 3.3.0.
Quasar Framework's development-only SSR/SSG error handler (@quasar/render-ssr-error before 2.2.4 and @quasar/app-vite before 3.3.0) serializes the developer's shell environment variables, request headers, and cookies into the HTML error page produced by serve.devError(), and because the dev server listens on all interfaces by default, any network-adjacent client that can provoke a render failure can read those secrets without authentication. The same page escaped only the exact lowercase '</script>' spelling, so case variants or alternate closing-tag delimiters reflected in diagnostic data can terminate the script element and inject markup; for that injected code to execute in a browser it must accompany the developer's own request, which is why user interaction and high attack complexity apply. The issue is fixed in @quasar/render-ssr-error 2.2.4 and @quasar/app-vite 3.3.0 (commit 61c2bd8, advisory GHSA-r5mf-4r5x-q78f); no public exploit identified at time of analysis, and production SSR builds are unaffected - this is a developer-workstation-scoped risk rather than a broad production threat.
Insecure file permissions in Quasar's development TLS certificate utility (@quasar/ssl-certificate before 2.1.0, shipped via @quasar/cli before 5.0.4 and @quasar/app-vite before 3.3.0) let another local, unprivileged user on the same host read the cached combined private key and certificate PEM and then impersonate the developer's localhost HTTPS endpoint in any environment that trusts that certificate. The flaw is a local, low-privilege information-disclosure and impersonation issue (CWE-732) rather than a remotely exploitable critical condition: it only matters on multi-user, non-Windows machines (shared workstations, CI/build servers, container hosts) where at least one other local account exists and the generated dev certificate is actually trusted. Additional weaknesses compound the exposure - the generated certificate was CA-capable, carried unnecessary key usages, and encoded the IPv6 loopback address as a DNS SAN - but the practical impact remains bounded by the local-attacker prerequisite; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV) for this CVE. Vendor-released fixes are available in @quasar/ssl-certificate 2.1.0, @quasar/cli 5.0.4 and @quasar/app-vite 3.3.0.
Unauthenticated remote attackers can stall server-side rendering in Quasar Framework versions prior to 2.23.3 by sending a crafted User-Agent header that triggers catastrophic regex backtracking in Platform.parseSSR(). Because Platform is an auto-installed plugin, the header is parsed before routing on every SSR request, so a single malformed request keeps the Node.js event loop busy and delays or blocks all other SSR traffic - an availability-only impact (CVSS 4.0 base 8.7; our assessment CVSS 3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Only SSR targets are exposed; SPA, PWA, Electron, Cordova, Capacitor, browser-extension, and static-site-generation builds never feed an attacker-controlled header into this path. No public exploit identified at time of analysis, and no CISA KEV listing or EPSS score was provided in the source data.
Path traversal in @quasar/icongenie versions before 6.1.1 lets a crafted profile cause the icongenie generate --profile command to write generated image content to any path writable by the invoking developer, enabling overwrite of shell startup files, build scripts, or other executable configuration. Exploitation requires the developer to run the command against an attacker-supplied profile (UI:R) and gives no direct remote access; no public exploit code identified at time of analysis, and the issue is fixed in 6.1.1.
Server-side cross-site scripting in Quasar Framework's SSR meta plugin (versions prior to 2.22.0) allows remote attackers who can influence dynamic page metadata - such as a post title, product name, excerpt, or display name - to inject executable markup into the server-rendered HTML before hydration. The flaw is in the getHead() serializer, which interpolates values supplied through useMeta() into title, meta, link, and script tags without HTML text or quoted-attribute encoding, while the client-side apply() path is unaffected because it relies on DOM APIs that encode attributes. Exploitation requires the target application to run Quasar in SSR mode and to feed attacker-influenceable data into useMeta() without prior sanitization, and a victim must load the affected page for the injected script to run; no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and the 10.0 CVSS base score overstates the universal real-world risk given these preconditions. The issue is fixed in version 2.22.0.
The @quasar/app-vite build tooling (versions 1.0.0 through pre-3.3.0) recursively deletes the resolved build.distDir path before compilation without validating that the target is a safe location, so a dangerous distDir setting - a filesystem root, the user's home directory, the project root, or a symlink resolving outside the project - can cause destructive deletion of data writable by the build user. Authentication and interaction are constrained: per the assessed vectors (CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:A and CVSS:3.1/AV:L/AC:H/PR:H/UI:R) this requires local, high-privileged access and deliberate build invocation, and no attacker-controlled input reaches build.distDir by default, so exploitation depends on compromised or less-trusted automation influencing the build configuration or a developer authoring a mistaken configuration. This is a low-to-medium real-world risk that should NOT be treated as an urgent priority; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the impact is bounded to availability (data loss), with no confidentiality or integrity impact in the assessed vector.
On iOS builds of Quasar Framework (all versions prior to 2.32.2), the openURL() utility can be tricked into invoking attacker-controlled page content instead of the native SafariViewController bridge, breaking external navigation, login redirects, and payment redirects with a thrown TypeError. The trigger requires an app built for iOS (Cordova/Capacitor where Platform.is.ios is true) plus a QEditor, QSelect, or QChatMessage configured to render untrusted HTML that can define an element named 'SafariViewController'; a legitimate user must then attempt a URL-opening action. Impact is limited to denial of the URL-opening function (CVSS 3.1, AV:N/AC:H/PR:N/UI:R, C:N/I:N/A:L) and the bug is fixed in 2.32.2; no public exploit code or confirmed active exploitation was identified at time of analysis.