App Vite
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.
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.
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.
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.