GHSA-5478-66C3-RHXR
Vulnerability from github – Published: 2026-04-08 21:50 – Updated: 2026-04-08 21:50isRepeatedSingleCharRun() 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):
// 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:
// 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:
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
pretextfor 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)):
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.0.4"
},
"package": {
"ecosystem": "npm",
"name": "@chenglou/pretext"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T21:50:51Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "`isRepeatedSingleCharRun()` in `src/analysis.ts` (line 285) re-scans the entire accumulated segment on every merge iteration during text analysis, producing O(n\u00b2) 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 \u0026\u0026\n !piece.isWordLike \u0026\u0026\n mergedLen \u003e 0 \u0026\u0026\n mergedKinds[mergedLen - 1] === \u0027text\u0027 \u0026\u0026\n piece.text.length === 1 \u0026\u0026\n piece.text !== \u0027-\u0027 \u0026\u0026\n piece.text !== \u0027\u2014\u0027 \u0026\u0026\n isRepeatedSingleCharRun(mergedTexts[mergedLen - 1]!, piece.text) // \u003c- 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) { // \u003c- Iterates ENTIRE accumulated string\n if (part !== ch) return false\n }\n return true\n}\n```\n\n`Intl.Segmenter` with `granularity: \u0027word\u0027` 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 -\u003e prepareInternal(text, font, ...) // layout.ts:424\n -\u003e analyzeText(text, profile, whiteSpace=\u0027normal\u0027) // layout.ts:430 -\u003e analysis.ts:993\n -\u003e buildMergedSegmentation(normalized, profile, ...) // analysis.ts:1013 -\u003e analysis.ts:795\n -\u003e for each Intl.Segmenter segment:\n -\u003e isRepeatedSingleCharRun(accumulated, newChar) // line 857 -\u003e line 285\n -\u003e 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 \u0027@chenglou/pretext\u0027\n\n// 80,000 characters -\u003e ~20 seconds of main-thread blocking\nconst payload = \u0027(\u0027.repeat(80_000)\nprepare(payload, \u002716px Arial\u0027) // Blocks for ~20 seconds\n```\n\nAny single character that meets these criteria works:\n1. Classified as `\u0027text\u0027` 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: `(`, `[`, `{`, `#`, `@`, `!`, `%`, `^`, `~`, `\u003c`, `\u003e`, etc.\n\n---\n\n## Impact\n\n- **Chat/messaging applications:** User sends an 80KB message of `(` characters;\n the receiving client\u0027s 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 \u003e 0 \u0026\u0026 segment[0] === ch \u0026\u0026 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.",
"id": "GHSA-5478-66c3-rhxr",
"modified": "2026-04-08T21:50:51Z",
"published": "2026-04-08T21:50:51Z",
"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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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",
"type": "CVSS_V4"
}
],
"summary": "Pretext: Algorithmic Complexity (DoS) in the text analysis phase"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.