[GH-ISSUE #7173] [Bug] Pinned zod 4.4.3 is in the range of GHSA-mrhx-c7xc-m3w5 (memory exhaustion), fixed in 4.6.6 #4296

Closed
opened 2026-10-31 00:48:37 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @arda03sarikaya-byte on GitHub (Oct 25, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7173

Before submitting

  • I searched the open and closed issues for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

Source-only finding, nothing executed. package.json of rea-agents 6.8.0 from npm (repo commit 5d42839) pins zod to 4.4.3. GitHub advisory GHSA-mrhx-c7xc-m3w5 ("Zod can exhaust memory while validating oversized constrained collections", high, CVSS 7.5, published 2026-10-01) covers every zod release below 4.6.6. The fix is in 4.6.6.

https://github.com/advisories/GHSA-mrhx-c7xc-m3w5

Reproduction

No reproduction run. Steps I actually did:

  1. Installed rea-agents 6.8.0 from npm with --ignore-scripts.
  2. Read node_modules/rea-agents/package.json: "zod": "4.4.3".
  3. Compared it with the advisory's affected range (< 4.6.6).
    I did not test for memory exhaustion in REA itself.

Expected behavior

zod pinned at 4.6.6 or later, per the advisory's patched version, and the schema tests re-run after the bump. Unverified expectation: no REA API change is needed for that bump.

Impact and scope

Observed: dependency scanners flag the pin for anyone installing REA in an audited setup. Suspected (not tested): the real exposure inside REA is small, because tool inputs come from the MCP client. The analyzed target never writes them. Severity for REA itself is untested, so I leave it unknown.

REA version

6.8.0 (rea --version); source commit 5d42839

Runtime and platform

Node 24.22.1; macOS 26.6.2 arm64; no Hopper or Ghidra involved

Target and artifact context

not applicable

Interface

Package or setup

Earliest failure stage

Unknown

Relevant output or evidence

Command or MCP request actually run: none, source read only.
Relevant result, error, or artifact: none.
Source reference: package.json in rea-agents 6.8.0 on npm, dependencies.zod = "4.4.3". Advisory: https://github.com/advisories/GHSA-mrhx-c7xc-m3w5 (affected < 4.6.6, patched 4.6.6).
Missing evidence or remaining uncertainty: no runtime test showing the memory exhaustion is reachable through REA.

Typed outcome or recovery expected

No response

Analysis or suspected cause

Hypothesis, not tested: REA validates MCP tool inputs with zod, and those inputs come from the MCP client rather than from analyzed targets, so an oversized collection would have to come from the client side. The pin itself is the issue for audited installs regardless.

Additional context

Searched open and closed issues for "zod" and for "GHSA-mrhx-c7xc-m3w5" on 2026-10-25. Ten unrelated hits for the first, none for the second.

Originally created by @arda03sarikaya-byte on GitHub (Oct 25, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7173 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior Source-only finding, nothing executed. package.json of rea-agents 6.8.0 from npm (repo commit 5d42839) pins zod to 4.4.3. GitHub advisory GHSA-mrhx-c7xc-m3w5 ("Zod can exhaust memory while validating oversized constrained collections", high, CVSS 7.5, published 2026-10-01) covers every zod release below 4.6.6. The fix is in 4.6.6. https://github.com/advisories/GHSA-mrhx-c7xc-m3w5 ### Reproduction No reproduction run. Steps I actually did: 1. Installed rea-agents 6.8.0 from npm with --ignore-scripts. 2. Read node_modules/rea-agents/package.json: "zod": "4.4.3". 3. Compared it with the advisory's affected range (< 4.6.6). I did not test for memory exhaustion in REA itself. ### Expected behavior zod pinned at 4.6.6 or later, per the advisory's patched version, and the schema tests re-run after the bump. Unverified expectation: no REA API change is needed for that bump. ### Impact and scope Observed: dependency scanners flag the pin for anyone installing REA in an audited setup. Suspected (not tested): the real exposure inside REA is small, because tool inputs come from the MCP client. The analyzed target never writes them. Severity for REA itself is untested, so I leave it unknown. ### REA version 6.8.0 (rea --version); source commit 5d42839 ### Runtime and platform Node 24.22.1; macOS 26.6.2 arm64; no Hopper or Ghidra involved ### Target and artifact context not applicable ### Interface Package or setup ### Earliest failure stage Unknown ### Relevant output or evidence Command or MCP request actually run: none, source read only. Relevant result, error, or artifact: none. Source reference: package.json in rea-agents 6.8.0 on npm, dependencies.zod = "4.4.3". Advisory: https://github.com/advisories/GHSA-mrhx-c7xc-m3w5 (affected < 4.6.6, patched 4.6.6). Missing evidence or remaining uncertainty: no runtime test showing the memory exhaustion is reachable through REA. ### Typed outcome or recovery expected _No response_ ### Analysis or suspected cause Hypothesis, not tested: REA validates MCP tool inputs with zod, and those inputs come from the MCP client rather than from analyzed targets, so an oversized collection would have to come from the client side. The pin itself is the issue for audited installs regardless. ### Additional context Searched open and closed issues for "zod" and for "GHSA-mrhx-c7xc-m3w5" on 2026-10-25. Ten unrelated hits for the first, none for the second.
bsakaguchi 2026-10-31 00:48:37 +00:00
  • closed this issue
  • added the
    bug
    triage
    labels
Author
Owner

@XinwangTao commented on GitHub (Oct 26, 2026):

Thanks for the careful source-only analysis — the "suspected small real exposure" point matters (tool inputs come from the MCP client, not from analyzed targets), but the scanner flag alone already justifies the bump for audited installs, so #7184's 4.6.6 pin plus re-running the schema tests covers both sides. One follow-up suggestion: since the stale pin was only caught by manual source audit, consider enabling Dependabot (or similar) for runtime dependencies so advisory-range pins get flagged as soon as an advisory lands, instead of silently drifting.

<!-- gh-comment-id:6406116055 --> @XinwangTao commented on GitHub (Oct 26, 2026): Thanks for the careful source-only analysis — the "suspected small real exposure" point matters (tool inputs come from the MCP client, not from analyzed targets), but the scanner flag alone already justifies the bump for audited installs, so #7184's 4.6.6 pin plus re-running the schema tests covers both sides. One follow-up suggestion: since the stale pin was only caught by manual source audit, consider enabling Dependabot (or similar) for runtime dependencies so advisory-range pins get flagged as soon as an advisory lands, instead of silently drifting.
Sign in to join this conversation.
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#4296
No description provided.