Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The @quasar/ssl-certificate development utility caches a combined PEM containing a generated private key and certificate without explicitly restricting its filesystem permissions. On systems with a typical process umask, the PEM can be readable by other local users. A local attacker with filesystem access could copy and reuse the private key to impersonate a development TLS endpoint in an environment that trusts the certificate. The generated certificate was also unnecessarily CA-capable and included broad key usages beyond its localhost HTTPS purpose. Its IPv6 loopback entry was encoded as a DNS name rather than an IP subject alternative name. The remediation writes and repairs the cached PEM with owner-only permissions on supported platforms, generates a non-CA server-auth leaf certificate with constrained key usage, corrects the IPv6 loopback SAN, and bases cache expiry on content modification time so permission metadata changes cannot extend the certificate lifetime. This issue…
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The error page that Quasar CLI shows when an SSR or SSG render throws in development serializes every variable in process.env, every request header and every cookie into the HTTP response, and the dev server binds 0.0.0.0 by default. Any host that can reach the port therefore gets the developer's cloud keys, registry tokens and database URLs from a single unauthenticated GET. The same page embeds that data inside a <script element behind a replaceAll('</script', ...) guard that is ASCII-case-sensitive and requires a literal , so </SCRIPT, </script and </script/ all escape the element and give script execution in the dev server's origin. Details renderSSRError() builds the page by splicing a JSON blob into a prebuilt bundle (utils/render-ssr-error/src/index.js): before and after are the two halves of the compiled error-page UI, split inside a <script type="module" element, so data is emitted as a JS object literal in raw script text. The data itself comes from…
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Several @quasar/app-vite SSR and SSG renderer paths interpolate ssrContext.nonce directly into quoted HTML attributes. An application that derives or overrides the nonce using untrusted 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 directly affected because they do not contain HTML attribute delimiters. Exploitation requires an application to place attacker-controlled or otherwise unsafe data in ssrContext.nonce. The remediation centralizes nonce handling across development SSR/SSG, production SSR, production SSG, critical CSS, store-state scripts, and Vue Devtools. It validates the value as a non-empty base64/base64url CSP nonce and HTML-encodes the attribute value before rendering.
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
During an SSG build, page definitions returned by `getSsgPages()` can provide custom `dir` and `filename` values. The builder joined those values to `build.distDir` and wrote the generated page without verifying that the final destination remained inside the distribution directory. Details A page definition containing parent-directory traversal could cause the build to create a new HTML file outside `build.distDir`. An existing symlink below the distribution directory could also redirect a generated file or newly created directories outside the output tree. Quasar application configuration and SSG page definitions are trusted input by default, so this is not normally a remote file-write primitive. The issue becomes relevant when an application derives SSG page definitions from external or otherwise untrusted content, or when build configuration is compromised. Existing files are protected by the SSG renderer's no-overwrite behavior, but new files and directories can be…
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
@quasar/app-vite recursively removes build.distDir before producing build artifacts. The configured path was made absolute, but it was not checked before removal. A configuration mistake could therefore target the project root, user home directory, a filesystem root, or another directory outside the project. Details The build command and mode builders passed the resolved output directory directly to fs-extra recursive removal. Existing symlink ancestors were not resolved before deletion either, so a path that appeared to be inside the project could operate on a directory outside it. quasar.config is trusted application code, and no attacker-controlled input reaches build.distDir by default. This issue is primarily destructive-build safety hardening. It can become a security boundary when build configuration is generated or influenced by less-trusted automation. Impact Running a normal Quasar build with an unsafe build.distDir can delete data accessible to the build user…
Recommended action: Upgrade to 3.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.