GHSA-5478-66c3-rhxr: Pretext Denial of Service Vulnerability

HIGH
CWE-407
Published
Advisory Summary

GHSA-5478-66c3-rhxr is a HIGH denial of service vulnerability (CWE-407: Inefficient Algorithmic Complexity) affecting Pretext libraries in the npm ecosystem. The issue involves algorithmic complexity (dos) in the text analysis phase. Remediation is available by upgrading affected packages to version 0.0.5.

GHSA-5478-66c3-rhxr at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-5478-66c3-rhxr
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-407: Inefficient Algorithmic Complexity
Affected Product Pretext
Package Ecosystem npm
Published Date
Last Updated

How to Fix GHSA-5478-66c3-rhxr

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

@chenglou/pretext fixed: 0.0.5
npm install @chenglou/pretext@0.0.5
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 @chenglou/pretext

How to Check if You Are Affected

To determine whether your Node.js application is affected by GHSA-5478-66c3-rhxr, inspect your project dependencies using npm:

npm ls @chenglou/pretext

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

Note: The npm ls @chenglou/pretext 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-407: Inefficient Algorithmic Complexity, where an algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached. In Pretext, 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

`isRepeatedSingleCharRun()` in `src/analysis.ts` (line 285) re-scans the entire accumulated segment on every merge iteration during text analysis, producing O(n²) total work for input consisting of repeated identical punctuation characters. An attacker who controls text passed to `prepare()` can block the main thread for ~20 seconds with 80KB of input (e.g., `"(".repeat(80_000)`). Tested against commit 9364741d3562fcc65aacc50953e867a5cb9fdb23 (v0.0.4) on Node.js v24.12.0, Windows x64. A standalone PoC and detailed write-up are attached below. --- ## Root Cause The `buildMergedSegmentation()` function (line 795) processes text segments produced by `Intl.Segmenter`. When consecutive non-word-like segments consist of the same single character (e.g., `(`, `[`, `!`, `#`), the code merges them into one growing segment (line 859): ```typescript // 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 ``` Before each merge, it calls `isRepeatedSingleCharRun()` (line 857) to verify that ALL characters in the accumulated segment match the new character: ```typescript // 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 } ``` `Intl.Segmenter` with `granularity: 'word'` produces individual non-word segments for each punctuation character. For a string of N identical punctuation characters, the merge check is called N times. On the k-th call, the accumulated segment is k characters long, so `isRepeatedSingleCharRun` performs k comparisons. Total work: `1 + 2 + 3 + ... + N = N(N+1)/2 = O(n^2)` ### Call chain ``` 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 ``` ## Proof of Concept The simplest payload is a string of repeated `(` characters: ```typescript 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 ``` Any single character that meets these criteria works: 1. Classified as `'text'` by `classifySegmentBreakChar` (analysis.ts:321) - i.e., not a space, NBSP, ZWSP, soft-hyphen, tab, or newline 2. Produced as individual non-word segments by `Intl.Segmenter` (word granularity) 3. Not `-` or em-dash (explicitly excluded at lines 855-856) Working payload characters include: `(`, `[`, `{`, `#`, `@`, `!`, `%`, `^`, `~`, `<`, `>`, etc. --- ## Impact - **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. ## Suggested Fix 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)):** ```typescript 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.

GHSA-5478-66c3-rhxr Affected Pretext Versions

1 component(s)
Fixed Versions:
0.0.5
Product / Package Ecosystem Affected Versions Fixed Version
@chenglou/pretext
npm
< 0.0.5
0.0.5

References

Frequently Asked Questions

What is GHSA-5478-66c3-rhxr?
GHSA-5478-66c3-rhxr is a security vulnerability in Pretext involving Algorithmic Complexity (DoS) in the text analysis phase under CWE-407: Inefficient Algorithmic Complexity.
Which Pretext versions are affected?
Affected versions include releases prior to 0.0.5 across affected packages: @chenglou/pretext.
What version fixes GHSA-5478-66c3-rhxr?
Upgrading to 0.0.5 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @chenglou/pretext affected?
Yes, @chenglou/pretext is affected in releases prior to 0.0.5. Upgrade your dependency to 0.0.5 or later.
What CWE is associated with GHSA-5478-66c3-rhxr?
GHSA-5478-66c3-rhxr is classified under CWE-407: Inefficient Algorithmic Complexity (An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.).
How can I check npm dependencies for GHSA-5478-66c3-rhxr?
Run the dependency tree command: 'npm ls @chenglou/pretext'. 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-5478-66c3-rhxr",
  "modified" : "2026-04-08T21:50:51Z",
  "published" : "2026-04-08T21:50:51Z",
  "aliases" : [ ],
  "summary" : "Pretext: Algorithmic Complexity (DoS) in the text analysis phase",
  "details" : "`isRepeatedSingleCharRun()` in `src/analysis.ts` (line 285) re-scans the entire accumulated segment on every merge iteration during text analysis, producing O(n²) total work for input consisting of repeated identical punctuation characters. An attacker who controls text passed to `prepare()` can block the main thread for ~20 seconds with 80KB of input (e.g., `\"(\".repeat(80_000)`).\n\nTested against commit 9364741d3562fcc65aacc50953e867a5cb9fdb23 (v0.0.4) on Node.js v24.12.0, Windows x64.\n\nA standalone PoC and detailed write-up are attached below.\n\n---\n\n## Root Cause\n\nThe `buildMergedSegmentation()` function (line 795) processes text segments produced by `Intl.Segmenter`. When consecutive non-word-like segments consist of the same single character (e.g., `(`, `[`, `!`, `#`), the code merges them into one growing segment (line 859):\n\n```typescript\n// analysis.ts:849-859 - the merge branch inside the build loop\n} else if (\n  isText &&\n  !piece.isWordLike &&\n  mergedLen > 0 &&\n  mergedKinds[mergedLen - 1] === 'text' &&\n  piece.text.length === 1 &&\n  piece.text !== '-' &&\n  piece.text !== '—' &&\n  isRepeatedSingleCharRun(mergedTexts[mergedLen - 1]!, piece.text)  // <- O(n) per call\n) {\n  mergedTexts[mergedLen - 1] += piece.text  // append to accumulator\n```\n\nBefore each merge, it calls `isRepeatedSingleCharRun()` (line 857) to verify that ALL characters in the accumulated segment match the new character:\n\n```typescript\n// analysis.ts:285-291\nfunction isRepeatedSingleCharRun(segment: string, ch: string): boolean {\n  if (segment.length === 0) return false\n  for (const part of segment) {    // <- Iterates ENTIRE accumulated string\n    if (part !== ch) return false\n  }\n  return true\n}\n```\n\n`Intl.Segmenter` with `granularity: 'word'` produces individual non-word segments for each punctuation character. For a string of N identical punctuation characters, the merge check is called N times. On the k-th call, the accumulated segment is k characters long, so `isRepeatedSingleCharRun` performs k comparisons.\n\nTotal work: `1 + 2 + 3 + ... + N = N(N+1)/2 = O(n^2)`\n\n### Call chain\n\n```\nprepare(text, font)                                          // layout.ts:472\n  -> prepareInternal(text, font, ...)                        // layout.ts:424\n    -> analyzeText(text, profile, whiteSpace='normal')       // layout.ts:430 -> analysis.ts:993\n      -> buildMergedSegmentation(normalized, profile, ...)   // analysis.ts:1013 -> analysis.ts:795\n        -> for each Intl.Segmenter segment:\n          -> isRepeatedSingleCharRun(accumulated, newChar)   // line 857 -> line 285\n            -> iterates entire accumulated string            // O(k) per call, k growing\n```\n\n## Proof of Concept\n\nThe simplest payload is a string of repeated `(` characters:\n\n```typescript\nimport { prepare } from '@chenglou/pretext'\n\n// 80,000 characters -> ~20 seconds of main-thread blocking\nconst payload = '('.repeat(80_000)\nprepare(payload, '16px Arial')  // Blocks for ~20 seconds\n```\n\nAny single character that meets these criteria works:\n1. Classified as `'text'` by `classifySegmentBreakChar` (analysis.ts:321) - i.e., not a space, NBSP, ZWSP, soft-hyphen, tab, or newline\n2. Produced as individual non-word segments by `Intl.Segmenter` (word granularity)\n3. Not `-` or em-dash (explicitly excluded at lines 855-856)\n\nWorking payload characters include: `(`, `[`, `{`, `#`, `@`, `!`, `%`, `^`, `~`, `<`, `>`, etc.\n\n---\n\n## Impact\n\n- **Chat/messaging applications:** User sends an 80KB message of `(` characters;\n  the receiving client's UI thread freezes for ~20 seconds while rendering.\n- **Comment/form systems:** User-supplied text in any text field that uses\n  `pretext` for layout measurement blocks the main thread.\n- **Server-side rendering:** If `prepare()` is called server-side (Node.js/Bun),\n  a single request can consume 20+ seconds of CPU time per 80KB of payload.\n\nThe attack requires no authentication, special characters, or encoding tricks -\njust repeated ASCII punctuation. 80KB is well within typical text input limits.\n\nAs an application-level mitigation, callers can cap the length of text passed to\n`prepare()` before a library-level fix is available.\n\n## Suggested Fix\n\nReplace the O(n) full-scan verification with O(1) constant-time checks. \nSince the merge only ever appends the same character to an existing repeated-char run, the invariant is maintained structurally:\n\n**Option A - Check only endpoints (O(1)):**\n```typescript\nfunction isRepeatedSingleCharRun(segment: string, ch: string): boolean {\n  return segment.length > 0 && segment[0] === ch && segment[segment.length - 1] === ch\n}\n```\nThis 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.\n\n**Option B - Track with metadata**\nAdd 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.",
  "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" : "@chenglou/pretext"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.0.5"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.0.4"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/chenglou/pretext/security/advisories/GHSA-5478-66c3-rhxr"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/chenglou/pretext"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/chenglou/pretext/releases/tag/v0.0.5"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-407" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-08T21:50:51Z",
    "nvd_published_at" : null
  }
}