fix(security): bound text length before stripping tags

[dknauss]

Fixes a CPU-exhaustion vulnerability found by an adversarial security review of the REST surface. Confirmed by measurement, not inference.

The bug

Every CSL string is run through a looped wp_strip_all_tags(). Core's implementation first applies a lazy script/style-stripping regex that exhausts PCRE's JIT stack past roughly 600 KB and degrades to catastrophic backtracking. Measured against core's real implementation:

Payload	Cost
400 KB	0.00s
600 KB	2.41s
800 KB	7.73s
950 KB	12.86s

A cliff, not a slope. BIBLIOGRAPHY_BUILDER_MAX_FORMAT_BYTES bounds the whole request body, but nothing bounded an individual value — so one field could carry the entire megabyte into that regex.

Two halves, and the second is worse

Write path — POST /format, reachable by anyone with edit_posts (Contributor). Costs the attacker one request per hit.

Read path — GET /posts/{id}/bibliographies/{index}?format=text, plus the formatted-text sanitizer. This one is materially worse:

• bibliography_builder_can_read_post() returns true unconditionally for any publish post, so no authentication is required
• Block attributes are not schema-validated on save, so the payload can be written straight into post_content, never passing through the formatter or its guard
• Once stored, every subsequent read pays the cost again, free to the caller

The fix

Write path rejects strings over 64 KB — checked once over the decoded item, upstream of every strip. Deliberately not per call site: stripping is reached from flat string fields, author name parts, date literal/raw values, and both branches of the string-or-array handler. A limit on one leaves the same cost reachable under a different key. (The first version of this patch did exactly that and was rejected in review.)

Read path truncates to the same bound rather than rejecting, because refusing to render a bibliography that already exists would break the post rather than protect it.

The bound is applied per citation, never to the joined response. Capping the whole body would add nothing — the per-citation bound already keeps aggregate cost linear — and would silently drop the tail of an ordinary bibliography: 50 annotated entries exceed 64 KB on their own, well inside the supported 200-citation limit. (The third version of this patch did that too, and was also rejected.)

The test harness was hiding it

bootstrap.php stubbed wp_strip_all_tags as bare strip_tags(), omitting the regex that is the entire cost. No existing test could have observed this. The stub now mirrors core.

That also corrected an existing assertion: it expected <script>alert(1)</script> to strip to alert(1), but WordPress removes the element and its contents, giving Safe. That test was documenting a fiction the stub invented.

Verification

Every fix measured in both directions:

	RED	GREEN
Write path, all 5 strip sites (7 cases)	74s wall, 6 of 7 failing	0.067s
Read path, both stripping paths	24.4s wall	0.003s
Response-truncation regression	41 of 50 entries survive	50 of 50

187 tests / 428 assertions. PHPCS, Psalm, i18n, and verify-metrics clean.

Review history

Rejected three times before approval, each time correctly:

1. Capped one of five call sites — the other four still cost ~12.3s each
2. Fixed the write path while the unauthenticated read path stayed live
3. Fixed the read path but reused the single-field cap as a response cap, silently truncating legitimate annotated bibliographies

Every rejected version passed its own tests.

Risk

Contained. No change to block output, save format, or stored data. The read path's only behavioural change is truncating a single stored string past 64 KB — far beyond any real citation.

Not included

The post-type visibility check, the href scheme allowlist, and U+2028/U+2029 escaping are queued for a separate PR. None is a confirmed vulnerability, and this diff has been wrong enough times to be worth landing on its own.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 96.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 81.05%. Comparing base (ecadee1) to head (bbc8b29).

Files with missing lines	Patch %	Lines
bibliography-builder.php	96.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #75      +/-   ##
==========================================
+ Coverage   80.94%   81.05%   +0.10%     
==========================================
  Files          43       43              
  Lines        3128     3151      +23     
  Branches      523      523              
==========================================
+ Hits         2532     2554      +22     
- Misses        190      191       +1     
  Partials      406      406              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.