morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #5253] [Bug] Valid large base64 bodies overflow shared capture validation regexes #3208

New issue

Closed

opened 2026-10-31 00:37:52 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:37:52 +00:00

Owner

Originally created by @morluto on GitHub (Oct 19, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5253

Before submitting

Searched open and closed reports for base64/stack/large HAR failures.
Only synthetic data is included; no credentials or target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

A valid HAR 1.2 containing one 4 MiB canonical-base64 response body fails through the compiled CLI with exit 1 and execution_failure. Its diagnostic says Capture decoder failed unexpectedly (RangeError). The HAR is 5,593,044 bytes, below the advertised 32 MiB input budget. The ordinary decoder path should retain these bytes; no source-byte or output budget was exceeded in this reproduction.

Reproduction

Executed once through the compiled CLI on the source revision below. With the locked development dependencies, pinned Node and built CLI available, from the repository:

node --import tsx --input-type=module <<'JS'
import { writeFile } from 'node:fs/promises';
import { historicalHar } from './tests/fixtures/historicalHar.ts';
const fixture = historicalHar();
const bytes = Buffer.alloc(4 * 1024 * 1024, 0x61);
const entry = fixture.log.entries[0];
entry.response.content = {
  size: bytes.length, mimeType: 'application/octet-stream',
  encoding: 'base64', text: bytes.toString('base64')
};
entry.response.bodySize = bytes.length;
await writeFile('/tmp/rea-large-base64.har', JSON.stringify(fixture));
JS
node scripts/rea.mjs inspect-web-network-capture /tmp/rea-large-base64.har har --json

This reads a synthetic local capture; it does not contact its recorded URL or execute a target.

Expected behavior

Return complete retained HAR Evidence with the original canonical body, its 4,194,304-byte count and SHA-256 digest. Preserve the separate producer-declared sizes and malformed-base64 rejection. WEB_NETWORK_CAPTURE_LIMITS admits up to 32 MiB input and 96 MiB output; this fixture is below both.

Impact and scope

Observed: this supported synthetic HAR fails. Source/helper probes also confirm that the same grouped repeating base64 grammar overflows for valid 4/8 MiB raw encodings. Related copies exist in CDP response-body decoding, CacheStorage fingerprinting, and canonical-base64 domain schemas. Live Chrome/cache behavior, real capture frequency, MCP execution and release-runtime applicability were not tested for this report.

REA version

Source and compiled checkout: dc936f433cf305ec9dbf9df70842303f89fab03f, package 6.7.0. Published npm runtime was not run.

Runtime and platform

Node 24.18.0; macOS 26.3 arm64.

Target and artifact context

One synthetic HAR 1.2 entry from the repository fixture, with 4 MiB of byte 0x61 encoded as canonical base64. No browser or deep-analysis provider required.

Interface

CLI

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

{"code":"execution_failure","details":{"provider_id":"har","operation":"inspect_web_network_capture","diagnostics":{"phase":"decoder","failure_kind":"decoder","reason":"Capture decoder failed unexpectedly (RangeError).","pointer":""}}}

Pinned-Node direct helper probes: 1 MiB raw succeeds; 4 MiB raw throws RangeError: Maximum call stack size exceeded. Exact thresholds for other runtimes were not measured.

Typed outcome or recovery expected

Preserve complete supported Evidence for valid input. Invalid alphabet/padding/pad bits must remain typed format failures rather than unhandled regex exceptions.

Analysis or suspected cause

Source-confirmed: src/browser/history/HarCapture.ts:269 validates base64 with a nested quantified regex. The same representation is duplicated in CdpCaptureEventHelpers.ts:115, CdpCaptureStorageFingerprints.ts:548, and domain/stringPatterns.ts:9. Shared format validation should preserve CDP's existing padded-syntax acceptance and HAR's stricter canonical pad-bit/ASCII-whitespace rules. Do not add downstream RangeError catches or truncate the body.

Additional context

Closed #1380 is a different source-map directive regex/entrypoint. Open #4425 and PR #4456 concern worker-network observation; that PR changes the first CDP helper but leaves the HAR/cache/domain counterparts. This report's closure signal is successful complete decoding of the bounded HAR plus regression coverage of shared consumers. No OOM, natural capture frequency, or runtime crash outside the isolated decoder was observed.

Originally created by @morluto on GitHub (Oct 19, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5253 ### Before submitting - [x] Searched open and closed reports for base64/stack/large HAR failures. - [x] Only synthetic data is included; no credentials or target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior A valid HAR 1.2 containing one 4 MiB canonical-base64 response body fails through the compiled CLI with exit 1 and `execution_failure`. Its diagnostic says `Capture decoder failed unexpectedly (RangeError).` The HAR is 5,593,044 bytes, below the advertised 32 MiB input budget. The ordinary decoder path should retain these bytes; no source-byte or output budget was exceeded in this reproduction. ### Reproduction Executed once through the compiled CLI on the source revision below. With the locked development dependencies, pinned Node and built CLI available, from the repository: ```sh node --import tsx --input-type=module <<'JS' import { writeFile } from 'node:fs/promises'; import { historicalHar } from './tests/fixtures/historicalHar.ts'; const fixture = historicalHar(); const bytes = Buffer.alloc(4 * 1024 * 1024, 0x61); const entry = fixture.log.entries[0]; entry.response.content = { size: bytes.length, mimeType: 'application/octet-stream', encoding: 'base64', text: bytes.toString('base64') }; entry.response.bodySize = bytes.length; await writeFile('/tmp/rea-large-base64.har', JSON.stringify(fixture)); JS node scripts/rea.mjs inspect-web-network-capture /tmp/rea-large-base64.har har --json ``` This reads a synthetic local capture; it does not contact its recorded URL or execute a target. ### Expected behavior Return complete retained HAR Evidence with the original canonical body, its 4,194,304-byte count and SHA-256 digest. Preserve the separate producer-declared sizes and malformed-base64 rejection. `WEB_NETWORK_CAPTURE_LIMITS` admits up to 32 MiB input and 96 MiB output; this fixture is below both. ### Impact and scope Observed: this supported synthetic HAR fails. Source/helper probes also confirm that the same grouped repeating base64 grammar overflows for valid 4/8 MiB raw encodings. Related copies exist in CDP response-body decoding, CacheStorage fingerprinting, and canonical-base64 domain schemas. Live Chrome/cache behavior, real capture frequency, MCP execution and release-runtime applicability were not tested for this report. ### REA version Source and compiled checkout: `dc936f433cf305ec9dbf9df70842303f89fab03f`, package 6.7.0. Published npm runtime was not run. ### Runtime and platform Node 24.18.0; macOS 26.3 arm64. ### Target and artifact context One synthetic HAR 1.2 entry from the repository fixture, with 4 MiB of byte 0x61 encoded as canonical base64. No browser or deep-analysis provider required. ### Interface CLI ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence ```json {"code":"execution_failure","details":{"provider_id":"har","operation":"inspect_web_network_capture","diagnostics":{"phase":"decoder","failure_kind":"decoder","reason":"Capture decoder failed unexpectedly (RangeError).","pointer":""}}} ``` Pinned-Node direct helper probes: 1 MiB raw succeeds; 4 MiB raw throws `RangeError: Maximum call stack size exceeded`. Exact thresholds for other runtimes were not measured. ### Typed outcome or recovery expected Preserve complete supported Evidence for valid input. Invalid alphabet/padding/pad bits must remain typed format failures rather than unhandled regex exceptions. ### Analysis or suspected cause Source-confirmed: `src/browser/history/HarCapture.ts:269` validates base64 with a nested quantified regex. The same representation is duplicated in `CdpCaptureEventHelpers.ts:115`, `CdpCaptureStorageFingerprints.ts:548`, and `domain/stringPatterns.ts:9`. Shared format validation should preserve CDP's existing padded-syntax acceptance and HAR's stricter canonical pad-bit/ASCII-whitespace rules. Do not add downstream RangeError catches or truncate the body. ### Additional context Closed #1380 is a different source-map directive regex/entrypoint. Open #4425 and PR #4456 concern worker-network observation; that PR changes the first CDP helper but leaves the HAR/cache/domain counterparts. This report's closure signal is successful complete decoding of the bounded HAR plus regression coverage of shared consumers. No OOM, natural capture frequency, or runtime crash outside the isolated decoder was observed.

bsakaguchi

2026-10-31 00:37:52 +00:00

closed this issue
added the
triage

bug
labels

bsakaguchi commented

2026-10-31 00:37:53 +00:00

Author

Owner

@morluto commented on GitHub (Oct 19, 2026):

Fixed on main in 49b4edfe77.

The root cause was repeated alphabet-quartet regex validation, duplicated between HAR and CDP and also used by canonical domain schemas. The shared domain grammar now checks alphabet/padding separately from quartet length. CDP body shapes/cache fingerprints share decoding; binary WebSocket sizing validates/counts without allocating decoded bytes. HAR still requires canonical zero pad bits and permits only its existing ASCII whitespace normalization. Source text, retained bytes, hashes and malformed-input behavior are preserved.

A first quartet-expansion candidate passed at 4 MiB but failed a near-budget probe; it was rejected before publication. The final tests include roughly 32 MiB encoded values under ordinary, Unicode and Unicode-set regex modes, including bad suffixes, lengths and pad bits.

Validation on pinned Node 24.18.0/macOS 26.3 arm64: 14 affected test files, 241 tests passed; npm run check, npm run docs:check, and test discovery passed. The compiled CLI retains the complete 4 MiB HAR body. Default MCP correctly returns its transport-budget diagnostic with a retained Evidence reference; the test exports that exact record and checks complete bytes/count/digest and unchanged source input.

No real Chrome, published npm runtime, alternate Node-major, or live IDE-client evaluation was performed. This closes the reproduced validation defect; worker observation #4425 remains separate.

@morluto commented on GitHub (Oct 19, 2026): Fixed on main in 49b4edfe7788495ba548e423c9c3b82dc14cca03. The root cause was repeated alphabet-quartet regex validation, duplicated between HAR and CDP and also used by canonical domain schemas. The shared domain grammar now checks alphabet/padding separately from quartet length. CDP body shapes/cache fingerprints share decoding; binary WebSocket sizing validates/counts without allocating decoded bytes. HAR still requires canonical zero pad bits and permits only its existing ASCII whitespace normalization. Source text, retained bytes, hashes and malformed-input behavior are preserved. A first quartet-expansion candidate passed at 4 MiB but failed a near-budget probe; it was rejected before publication. The final tests include roughly 32 MiB encoded values under ordinary, Unicode and Unicode-set regex modes, including bad suffixes, lengths and pad bits. Validation on pinned Node 24.18.0/macOS 26.3 arm64: 14 affected test files, 241 tests passed; `npm run check`, `npm run docs:check`, and test discovery passed. The compiled CLI retains the complete 4 MiB HAR body. Default MCP correctly returns its transport-budget diagnostic with a retained Evidence reference; the test exports that exact record and checks complete bytes/count/digest and unchanged source input. No real Chrome, published npm runtime, alternate Node-major, or live IDE-client evaluation was performed. This closes the reproduced validation defect; worker observation #4425 remains separate.

bsakaguchi referenced this issue

2026-10-31 01:08:49 +00:00

[PR #3296] [CLOSED] fix(doctor): resolve unqualified skill identity from installed destinations #5706

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3208

No description provided.

Rows
Columns