Severity: medium / Confidence: high / Category: bug
Triage: confirmed-bug
Detected against: openclaw v2026.5.18 (latest stable at time of scan, 2026-05-18)
Tooling: clawpatch 0.3.0 + acpx/claude-sonnet-4-5 via Brad Mills protocol

Evidence

• src/cli/shared/parse-port.ts:3-8 (parsePort)

return parseStrictPositiveInteger(raw) ?? null;

Reasoning

parseStrictPositiveInteger enforces that the value is a positive integer, but imposes no upper bound. Valid TCP/UDP port numbers are 1–65535; any value from 65536 upward is silently returned as a number rather than null. The feature's trust boundary is user-input and process-exec, so hostile or misconfigured input like '99999' reaches callers as a seemingly valid port. Callers that pass the result directly to a bind or connect call will get an OS-level error rather than a clean parsing failure.

Reproduction

parsePort('99999') returns 99999 instead of null.

Recommendation

After the existing parseStrictPositiveInteger call, add an upper-bound check: const n = parseStrictPositiveInteger(raw) ?? null; return n !== null && n <= 65535 ? n : null;

Why existing tests miss this

The feature lists no tests at all (tests: []).

Suggested regression test

it('rejects port numbers above 65535', () => { expect(parsePort(65536)).toBeNull(); expect(parsePort(99999)).toBeNull(); expect(parsePort(65535)).toBe(65535); expect(parsePort(1)).toBe(1); expect(parsePort(0)).toBeNull(); });

Minimum fix scope

Add n <= 65535 guard inside parsePort; no changes to the imported helper required.

Standardized clawpatch finding. Persistent in v2026.5.18 (not resolved by upgrading from v2026.5.12). Finding ID: fnd_sig-feat-cli-command-1589b7a20d-_a369155588.