escape is bypassable under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')."}},{"@type":"Question","name":"Which Quasar Framework versions are affected?","acceptedAnswer":{"@type":"Answer","text":"Affected versions include releases prior to 2.2.4, 3.3.0 across affected packages: @quasar/render-ssr-error, @quasar/app-vite."}},{"@type":"Question","name":"What version fixes CVE-2026-106106?","acceptedAnswer":{"@type":"Answer","text":"Upgrading to 2.2.4, 3.3.0 (or the latest patched release for your respective branch) resolves the vulnerability."}},{"@type":"Question","name":"Is @quasar/render-ssr-error affected?","acceptedAnswer":{"@type":"Answer","text":"Yes, @quasar/render-ssr-error is affected in releases prior to 2.2.4. Upgrade your dependency to 2.2.4 or later."}},{"@type":"Question","name":"Is @quasar/app-vite affected?","acceptedAnswer":{"@type":"Answer","text":"Yes, @quasar/app-vite is affected in releases prior to 3.3.0. Upgrade your dependency to 3.3.0 or later."}},{"@type":"Question","name":"What CWE is associated with CVE-2026-106106?","acceptedAnswer":{"@type":"Answer","text":"CVE-2026-106106 is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.)."}},{"@type":"Question","name":"How can I check npm dependencies for CVE-2026-106106?","acceptedAnswer":{"@type":"Answer","text":"Run the dependency tree command: 'npm ls @quasar/render-ssr-error'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved."}}]}

CVE-2026-106106: Quasar Framework SSR/SSG Dev Error Page Discloses Vulnerability

HIGH
Advisory Identifier: GHSA-r5mf-4r5x-q78f
CWE-79 CWE-497
Published
Advisory Summary

CVE-2026-106106 is a HIGH ssr/ssg dev error page discloses vulnerability (CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) affecting Quasar Framework libraries in the npm ecosystem. The issue involves ssr/ssg dev error page discloses the full shell environment and its </script> escape is bypassable. Remediation is available by upgrading affected packages to version 2.2.4, 3.3.0.

CVE-2026-106106 at a Glance

CVE Identifier CVE-2026-106106
GHSA Identifier GHSA-r5mf-4r5x-q78f
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected Product Quasar Framework
Package Ecosystem npm
Published Date
Last Updated

How to Fix CVE-2026-106106

To remediate this vulnerability, upgrade all affected Quasar Framework dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@quasar/render-ssr-error fixed: 2.2.4
npm install @quasar/render-ssr-error@2.2.4
@quasar/app-vite fixed: 3.3.0
npm install @quasar/app-vite@3.3.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @quasar/render-ssr-error

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-106106, inspect your project dependencies using npm:

npm ls @quasar/render-ssr-error

Analyze the terminal output to locate any version of Quasar Framework in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.2.4), your application is affected.

Note: The npm ls @quasar/render-ssr-error command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), where the product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. In Quasar Framework, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary 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`): ```js errorHtml: before + JSON.stringify(data).replaceAll('</script>', String.raw`<\/script>`) + after ``` `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 `utils/render-ssr-error/src/env.js`: ```js function getEnvironmentVariablesData () { return Object.keys(process.env).reduce((acc, name) => { acc[ name ] = process.env[ name ] return acc }, {}) } export function getEnv (req) { return { Request: getRequestData(req), Headers: getHeadersData(req), Cookies: getCookiesData(req), 'Shell environment variables': getEnvironmentVariablesData() } } ``` The page is served by `serve.devError({ err, req })` in `app-vite/lib/modes/ssr/ssr-devserver.js` and by the SSG equivalent, which the generated render middleware calls on any render exception. The dev server listens on every interface because `app-vite/lib/quasar-config-file.js` overrides Vite's `localhost` default: ```js } else if (!cfg.devServer.host) { cfg.devServer.host = '0.0.0.0' } ``` The escape fails because the HTML tokenizer ends script raw text on `</` followed by a case-insensitive `script` followed by any of tab, newline, form feed, space, `/` or `>`. `replaceAll` with a string pattern matches one exact spelling. `</SCRIPT>`, `</ScRiPt>`, `</script >` and `</script/>` are all untouched and all close the element. `JSON.stringify` does not escape `<` or `>`, and cookie values are additionally run through `decodeURIComponent` before being placed in the blob, so percent-encoded payloads decode into working markup. The project already implements this correctly elsewhere. `ui/src/plugins/meta/Meta.js` uses a case-insensitive pattern with no trailing `>`: ```js function protectRawText (value, tagName) { return String(value).replaceAll(new RegExp(`</${tagName}`, 'gi'), `<\\/${tagName}`) } ``` ### PoC Harness that replicates the dev server's error branch using the published `@quasar/render-ssr-error@2.2.3`, with two canary values planted in the environment: ```js import http from 'node:http' import renderSSRError from '@quasar/render-ssr-error' process.env.AWS_SECRET_ACCESS_KEY = 'CANARY_AWS_SECRET_dev_machine_9f3a1c' process.env.NPM_TOKEN = 'CANARY_npm_TOKEN_abcdef' http.createServer((req, res) => { const err = new Error('Cannot read properties of undefined (reading "x")') const { errorHeaders, errorHtml } = renderSSRError({ err, req, rootFolder: process.cwd() }) res.writeHead(500, errorHeaders) res.end(errorHtml) }).listen(3200, '0.0.0.0') ``` Disclosure needs no payload at all. A plain `GET /` returns a 957 KB page containing both canaries: ``` ENV DISCLOSURE (plain GET, no injection): 2/2 canary secrets present in the 500 page -> CANARY_AWS_SECRET_dev_machine_9f3a1c, CANARY_npm_TOKEN_abcdef ``` For the injection, the payload goes in an ordinary request header. `JSON.stringify` escapes `"` as `\"`, so the handler uses single quotes: ``` <TAG><img src=/nonexistent-image onerror='window.__QPWN=document.domain+":"+location.port'> ``` Loaded in headless Chromium: ``` POSITIVE </SCRIPT > (uppercase + space) window.__QPWN=127.0.0.1:3200 injectedImg=1 ATTACKER SCRIPT EXECUTED POSITIVE </script > (lowercase + space) window.__QPWN=127.0.0.1:3200 injectedImg=1 ATTACKER SCRIPT EXECUTED POSITIVE </script/> (lowercase + slash) window.__QPWN=127.0.0.1:3200 injectedImg=1 ATTACKER SCRIPT EXECUTED POSITIVE </ScRiPt> (mixed case) window.__QPWN=127.0.0.1:3200 injectedImg=1 ATTACKER SCRIPT EXECUTED NEG-CTRL </script> (what the filter matches) window.__QPWN=null injectedImg=0 no execution ``` The negative control is the same payload with the one spelling `replaceAll` actually matches. Nothing is injected and nothing runs, which isolates the bug to the escape rather than to the surrounding page. Confirming the injection context, a probe header comes back inside the single `<script type="module">` element: ``` ..."Headers":{"host":"127.0.0.1:3200","user-agent":"curl/8.18.0","accept":"*/*", "x-probe":"</SCRIPT ><img src=/nope onerror=\"window.__QPWN=1\">MARKEREND"},... ``` No `Content-Security-Policy` is sent with the page. ### Impact Exposure of sensitive system information, plus HTML injection into a page that carries it. This is development only, since `serve.devError` does not exist in a production build, and it requires the app's SSR render to throw. That is the routine state this page exists to display, and an attacker who can reach the port can simply poll for it. The disclosure is the substantive half and needs nothing but a TCP connection: shell environment, all request headers, all cookies, and ten lines of source around every stack frame. On a developer machine that typically means cloud credentials, npm or GitHub tokens and database connection strings. Because Quasar overrides Vite's `localhost` default with `0.0.0.0`, everyone on the same network segment or in a shared container network can ask for it. The injection is best treated as a chained issue on top of that rather than as a drive-by. A raw HTTP client can set the header but only poisons its own page. For the code to run in the developer's browser the payload has to travel with the developer's own request, which in practice means the cookie channel, since cookie values are URL-decoded and any page on a `localhost` or `127.0.0.1` origin can set a cookie that is sent to every port on that host. Cross-origin `fetch` does not work: CORS-safelisted headers forbid `<` and `>`, and browsers percent-encode them in the URL while `req.url` is never decoded. Fixing the escape alone leaves the disclosure. Serializing with something that escapes `<`, such as the `serialize-javascript` already used correctly in `app-vite/lib/modes/ssr/ssr-utils.js`, closes the injection; redacting or omitting `process.env` and cookie values closes the disclosure; defaulting `devServer.host` to `localhost` as Vite does would reduce who can ask.

CVE-2026-106106 Affected Quasar Framework Versions

2 component(s)
Fixed Versions:
2.2.43.3.0
Product / Package Ecosystem Affected Versions Fixed Version
@quasar/render-ssr-error
npm
< 2.2.4
2.2.4
@quasar/app-vite
npm
< 3.3.0
3.3.0

References

Frequently Asked Questions

What is CVE-2026-106106?
CVE-2026-106106 is a security vulnerability in Quasar Framework involving SSR/SSG dev error page discloses the full shell environment and its </script> escape is bypassable under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
Which Quasar Framework versions are affected?
Affected versions include releases prior to 2.2.4, 3.3.0 across affected packages: @quasar/render-ssr-error, @quasar/app-vite.
What version fixes CVE-2026-106106?
Upgrading to 2.2.4, 3.3.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @quasar/render-ssr-error affected?
Yes, @quasar/render-ssr-error is affected in releases prior to 2.2.4. Upgrade your dependency to 2.2.4 or later.
Is @quasar/app-vite affected?
Yes, @quasar/app-vite is affected in releases prior to 3.3.0. Upgrade your dependency to 3.3.0 or later.
What CWE is associated with CVE-2026-106106?
CVE-2026-106106 is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.).
How can I check npm dependencies for CVE-2026-106106?
Run the dependency tree command: 'npm ls @quasar/render-ssr-error'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-r5mf-4r5x-q78f",
  "modified" : "2026-10-07T16:16:12Z",
  "published" : "2026-10-07T16:16:12Z",
  "aliases" : [ "CVE-2026-106106" ],
  "summary" : "Quasar Framework: SSR/SSG dev error page discloses the full shell environment and its </script> escape is bypassable",
  "details" : "### Summary\n\nThe 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.\n\n### Details\n\n`renderSSRError()` builds the page by splicing a JSON blob into a prebuilt bundle (`utils/render-ssr-error/src/index.js`):\n\n```js\nerrorHtml:\n  before +\n  JSON.stringify(data).replaceAll('</script>', String.raw`<\\/script>`) +\n  after\n```\n\n`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 `utils/render-ssr-error/src/env.js`:\n\n```js\nfunction getEnvironmentVariablesData () {\n  return Object.keys(process.env).reduce((acc, name) => {\n    acc[ name ] = process.env[ name ]\n    return acc\n  }, {})\n}\n\nexport function getEnv (req) {\n  return {\n    Request: getRequestData(req),\n    Headers: getHeadersData(req),\n    Cookies: getCookiesData(req),\n    'Shell environment variables': getEnvironmentVariablesData()\n  }\n}\n```\n\nThe page is served by `serve.devError({ err, req })` in `app-vite/lib/modes/ssr/ssr-devserver.js` and by the SSG equivalent, which the generated render middleware calls on any render exception. The dev server listens on every interface because `app-vite/lib/quasar-config-file.js` overrides Vite's `localhost` default:\n\n```js\n} else if (!cfg.devServer.host) {\n  cfg.devServer.host = '0.0.0.0'\n}\n```\n\nThe escape fails because the HTML tokenizer ends script raw text on `</` followed by a case-insensitive `script` followed by any of tab, newline, form feed, space, `/` or `>`. `replaceAll` with a string pattern matches one exact spelling. `</SCRIPT>`, `</ScRiPt>`, `</script >` and `</script/>` are all untouched and all close the element. `JSON.stringify` does not escape `<` or `>`, and cookie values are additionally run through `decodeURIComponent` before being placed in the blob, so percent-encoded payloads decode into working markup.\n\nThe project already implements this correctly elsewhere. `ui/src/plugins/meta/Meta.js` uses a case-insensitive pattern with no trailing `>`:\n\n```js\nfunction protectRawText (value, tagName) {\n  return String(value).replaceAll(new RegExp(`</${tagName}`, 'gi'), `<\\\\/${tagName}`)\n}\n```\n\n### PoC\n\nHarness that replicates the dev server's error branch using the published `@quasar/render-ssr-error@2.2.3`, with two canary values planted in the environment:\n\n```js\nimport http from 'node:http'\nimport renderSSRError from '@quasar/render-ssr-error'\n\nprocess.env.AWS_SECRET_ACCESS_KEY = 'CANARY_AWS_SECRET_dev_machine_9f3a1c'\nprocess.env.NPM_TOKEN = 'CANARY_npm_TOKEN_abcdef'\n\nhttp.createServer((req, res) => {\n  const err = new Error('Cannot read properties of undefined (reading \"x\")')\n  const { errorHeaders, errorHtml } = renderSSRError({ err, req, rootFolder: process.cwd() })\n  res.writeHead(500, errorHeaders)\n  res.end(errorHtml)\n}).listen(3200, '0.0.0.0')\n```\n\nDisclosure needs no payload at all. A plain `GET /` returns a 957 KB page containing both canaries:\n\n```\nENV DISCLOSURE (plain GET, no injection): 2/2 canary secrets present in the 500 page\n  -> CANARY_AWS_SECRET_dev_machine_9f3a1c, CANARY_npm_TOKEN_abcdef\n```\n\nFor the injection, the payload goes in an ordinary request header. `JSON.stringify` escapes `\"` as `\\\"`, so the handler uses single quotes:\n\n```\n<TAG><img src=/nonexistent-image onerror='window.__QPWN=document.domain+\":\"+location.port'>\n```\n\nLoaded in headless Chromium:\n\n```\nPOSITIVE  </SCRIPT >  (uppercase + space)   window.__QPWN=127.0.0.1:3200  injectedImg=1  ATTACKER SCRIPT EXECUTED\nPOSITIVE  </script >  (lowercase + space)   window.__QPWN=127.0.0.1:3200  injectedImg=1  ATTACKER SCRIPT EXECUTED\nPOSITIVE  </script/>  (lowercase + slash)   window.__QPWN=127.0.0.1:3200  injectedImg=1  ATTACKER SCRIPT EXECUTED\nPOSITIVE  </ScRiPt>   (mixed case)          window.__QPWN=127.0.0.1:3200  injectedImg=1  ATTACKER SCRIPT EXECUTED\nNEG-CTRL  </script>   (what the filter matches)\n                                            window.__QPWN=null            injectedImg=0  no execution\n```\n\nThe negative control is the same payload with the one spelling `replaceAll` actually matches. Nothing is injected and nothing runs, which isolates the bug to the escape rather than to the surrounding page. Confirming the injection context, a probe header comes back inside the single `<script type=\"module\">` element:\n\n```\n...\"Headers\":{\"host\":\"127.0.0.1:3200\",\"user-agent\":\"curl/8.18.0\",\"accept\":\"*/*\",\n   \"x-probe\":\"</SCRIPT ><img src=/nope onerror=\\\"window.__QPWN=1\\\">MARKEREND\"},...\n```\n\nNo `Content-Security-Policy` is sent with the page.\n\n### Impact\n\nExposure of sensitive system information, plus HTML injection into a page that carries it. This is development only, since `serve.devError` does not exist in a production build, and it requires the app's SSR render to throw. That is the routine state this page exists to display, and an attacker who can reach the port can simply poll for it.\n\nThe disclosure is the substantive half and needs nothing but a TCP connection: shell environment, all request headers, all cookies, and ten lines of source around every stack frame. On a developer machine that typically means cloud credentials, npm or GitHub tokens and database connection strings. Because Quasar overrides Vite's `localhost` default with `0.0.0.0`, everyone on the same network segment or in a shared container network can ask for it.\n\nThe injection is best treated as a chained issue on top of that rather than as a drive-by. A raw HTTP client can set the header but only poisons its own page. For the code to run in the developer's browser the payload has to travel with the developer's own request, which in practice means the cookie channel, since cookie values are URL-decoded and any page on a `localhost` or `127.0.0.1` origin can set a cookie that is sent to every port on that host. Cross-origin `fetch` does not work: CORS-safelisted headers forbid `<` and `>`, and browsers percent-encode them in the URL while `req.url` is never decoded.\n\nFixing the escape alone leaves the disclosure. Serializing with something that escapes `<`, such as the `serialize-javascript` already used correctly in `app-vite/lib/modes/ssr/ssr-utils.js`, closes the injection; redacting or omitting `process.env` and cookie values closes the disclosure; defaulting `devServer.host` to `localhost` as Vite does would reduce who can ask.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N/SC:H/SI:H/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@quasar/render-ssr-error"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.2.4"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.2.3"
    }
  }, {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@quasar/app-vite"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.3.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.2.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/quasarframework/quasar/security/advisories/GHSA-r5mf-4r5x-q78f"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-106106"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/quasarframework/quasar/commit/61c2bd8a607785fdade72cce20e8faf1de7eee15"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/quasarframework/quasar"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/quasarframework/quasar/releases/tag/@quasar/app-vite-v3.3.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-497", "CWE-79" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-07T16:16:12Z",
    "nvd_published_at" : "2026-10-06T18:16:52Z"
  }
}