GHSA-5478-66C3-RHXR

Pretext: Algorithmic Complexity (DoS) in the text analysis phase

// analysis.ts:849-859 - the merge branch inside the build loop
} else if (
  isText &&
  !piece.isWordLike &&
  mergedLen > 0 &&
  mergedKinds[mergedLen - 1] === 'text' &&
  piece.text.length === 1 &&
  piece.text !== '-' &&
  piece.text !== ', ' &&
  isRepeatedSingleCharRun(mergedTexts[mergedLen - 1]!, piece.text)  // <- O(n) per call
) {
  mergedTexts[mergedLen - 1] += piece.text  // append to accumulator

// analysis.ts:285-291
function isRepeatedSingleCharRun(segment: string, ch: string): boolean {
  if (segment.length === 0) return false
  for (const part of segment) {    // <- Iterates ENTIRE accumulated string
    if (part !== ch) return false
  }
  return true
}

prepare(text, font)                                          // layout.ts:472
  -> prepareInternal(text, font, ...)                        // layout.ts:424
    -> analyzeText(text, profile, whiteSpace='normal')       // layout.ts:430 -> analysis.ts:993
      -> buildMergedSegmentation(normalized, profile, ...)   // analysis.ts:1013 -> analysis.ts:795
        -> for each Intl.Segmenter segment:
          -> isRepeatedSingleCharRun(accumulated, newChar)   // line 857 -> line 285
            -> iterates entire accumulated string            // O(k) per call, k growing

import { prepare } from '@chenglou/pretext'

// 80,000 characters -> ~20 seconds of main-thread blocking
const payload = '('.repeat(80_000)
prepare(payload, '16px Arial')  // Blocks for ~20 seconds

• Chat/messaging applications: User sends an 80KB message of ( characters;
  the receiving client's UI thread freezes for ~20 seconds while rendering.
• Comment/form systems: User-supplied text in any text field that uses
  pretext for layout measurement blocks the main thread.
• Server-side rendering: If prepare() is called server-side (Node.js/Bun),
  a single request can consume 20+ seconds of CPU time per 80KB of payload.

The attack requires no authentication, special characters, or encoding tricks -
just repeated ASCII punctuation. 80KB is well within typical text input limits.

As an application-level mitigation, callers can cap the length of text passed to
prepare() before a library-level fix is available.

Kodem intelligence

Already deployed Kodem?

Replace the O(n) full-scan verification with O(1) constant-time checks.
Since the merge only ever appends the same character to an existing repeated-char run, the invariant is maintained structurally:

Option A - Check only endpoints (O(1)):

function isRepeatedSingleCharRun(segment: string, ch: string): boolean {
  return segment.length > 0 && segment[0] === ch && segment[segment.length - 1] === ch
}

This works for the current code because this branch only fires after earlier merge branches (CJK, Myanmar, Arabic) have been skipped, and those branches produce segments that would not start and end with the same ASCII punctuation character. However, the safety relies on an emergent property of the branch ordering and the other merge branches. Future refactors that add new merge branches or reorder the existing ones could silently break the invariant.

Option B - Track with metadata
Add a boolean lastMergeWasSingleCharRun alongside the accumulator arrays. Set it to true when a single-char merge succeeds, false when any other merge branch is taken. Check the flag instead of re-scanning the string.

1. What is GHSA-5478-66C3-RHXR? GHSA-5478-66C3-RHXR is a high-severity security vulnerability in @chenglou/pretext (npm), affecting versions <= 0.0.4. It is fixed in 0.0.5.
2. Which versions of @chenglou/pretext are affected by GHSA-5478-66C3-RHXR? @chenglou/pretext (npm) versions <= 0.0.4 is affected.
3. Is there a fix for GHSA-5478-66C3-RHXR? Yes. GHSA-5478-66C3-RHXR is fixed in 0.0.5. Upgrade to this version or later.
4. Is GHSA-5478-66C3-RHXR exploitable, and should I be worried? Whether GHSA-5478-66C3-RHXR 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 GHSA-5478-66C3-RHXR 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 GHSA-5478-66C3-RHXR? Upgrade @chenglou/pretext to 0.0.5 or later.