Skip to content

fix(deps): update dependency @chenglou/pretext to ^0.0.5 [security]#335

Open
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-chenglou-pretext-vulnerability
Open

fix(deps): update dependency @chenglou/pretext to ^0.0.5 [security]#335
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-chenglou-pretext-vulnerability

Conversation

@renovate
Copy link
Copy Markdown

@renovate renovate bot commented Apr 16, 2026

This PR contains the following updates:

Package Change Age Confidence
@chenglou/pretext ^0.0.4^0.0.5 age confidence

GitHub Vulnerability Alerts

GHSA-5478-66c3-rhxr

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

// 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 '@&#8203;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)):

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.

Severity
  • CVSS Score: 8.7 / 10 (High)
  • Vector String: 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

Release Notes

chenglou/pretext (@​chenglou/pretext)

v0.0.5

Compare Source

Added
  • Geometry-first rich line helpers for manual layout work: measureLineStats(), measureNaturalWidth(), layoutNextLineRange(), and materializeLineRange().
  • @chenglou/pretext/rich-inline, a narrow helper for inline-only rich text, mentions/chips, and browser-like boundary whitespace collapse.
  • { wordBreak: 'keep-all' } support on prepare() / prepareWithSegments() for CJK and Hangul text, plus a small standing keep-all browser oracle.
  • A virtualized markdown chat demo that dogfoods the rich-inline helper and pre-wrap text measurement.
Changed
  • Documentation now matches the current public API surface and user-facing limitations more closely.
  • The maintained corpus/status workflow now centers on checked-in Chrome and Safari step=10 sweeps instead of the older representative/sample reports.
  • Prepare-time analysis is more resilient on long mixed-script, CJK, Arabic, repeated-punctuation, and other degenerate inputs.
  • bun start now binds to LAN by default, and bun run start:windows provides a Windows-friendly fallback.
Fixed
  • Mixed CJK-plus-numeric runs, keep-all mixed-script boundaries, and long breakable runs now stay closer to browser behavior.
  • Rich-path bidi metadata and CJK detection now handle the relevant astral Unicode ranges correctly.
  • The probe page now reports line content end offsets correctly when a line range steps past a hard break omitted from rendered line text.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • ""
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@renovate renovate bot added the Dependency label Apr 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants