v5.0.7: three latent bugs found in static review (escape_for_json control-char gap, server.cjs payload-size DoS, find-polluter.sh unquoted loop)

[waple0820]

Hi — while vendoring v5.0.7 into a downstream repo, an automated review picked up three latent bugs across hooks/scripts. Reporting in one bundle since they're independent and individually small. None are critical for our use case (we won't patch the vendor copy and rely on upstream fixes), but they look like real correctness gaps.

---

1. hooks/session-start — escape_for_json only escapes a subset of C0 control characters

escape_for_json (lines ~23–31) handles \\, ", \n, \r, \t but does not escape \b (U+0008), \f (U+000C), or other C0 control characters (U+0000–U+001F) which RFC 8259 requires be escaped in JSON strings.

If any SKILL.md file (now or in the future) contains an unescaped form-feed / backspace / etc., the hook emits invalid JSON and Claude Code silently discards it — superpowers never activates. Failure mode is silent.

Related: closed issue #612 covered a different aspect of the same function.

Suggested fix: add the remaining required substitutions, or pipe through python -c 'import json,sys; print(json.dumps(sys.stdin.read())[1:-1])' to delegate escaping to a real JSON encoder.

---

2. skills/brainstorming/scripts/server.cjs — no upper bound on WebSocket payload allocation

payloadLen = Number(buffer.readBigUInt64BE(2));
// ...
const data = Buffer.alloc(payloadLen);

A WebSocket client can advertise a 64-bit payload length, causing Buffer.alloc to attempt a multi-GB allocation and crash the brainstorm server process. Risk is bounded — server binds to 127.0.0.1 so exploitation requires local access (any process / browser tab on the user's machine) — but worth a sanity ceiling (e.g. reject frames > 10 MB).

Related: #1014 covers Origin validation on the same WebSocket path; this is a separate hardening item.

Suggested fix: validate payloadLen <= MAX_FRAME_BYTES and close the connection on overrun.

---

3. skills/systematic-debugging/find-polluter.sh — unquoted loop variable word-splits paths with spaces

TEST_FILES=$(find . -path "$TEST_PATTERN" | sort)
for TEST_FILE in $TEST_FILES; do

$TEST_FILES is unquoted, so any test path containing whitespace is split across multiple iterations and the script reports incorrect results. Severity is low (this is a debugging utility, not a runtime path), but it's a footgun if anyone has spaces in their repo paths.

Suggested fix:

while IFS= read -r TEST_FILE; do
    ...
done < <(find . -path "$TEST_PATTERN" | sort)

---

Why one bundled issue

These are all small enough that filing three separate issues felt like noise. Happy to split if maintainers prefer.

Thanks for superpowers — vendoring it as the methodology backbone for our team's coding agent setup, including in the lexmount/deepbrowse repo.