openclaw - ✅(Solved) Fix parsePort accepts out-of-range port numbers (> 65535) [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#83900Fetched 2026-05-20 03:47:12
View on GitHub
Comments
1
Participants
2
Timeline
14
Reactions
1
Timeline (top)
labeled ×5referenced ×4cross-referenced ×2closed ×1

Error Message

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.

Fix Action

Fix / Workaround

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


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.

PR fix notes

PR #84008: fix(cli): reject out-of-range port numbers in parsePort (#83900)

Description (problem / solution / changelog)

Fixes #83900.

parsePort (src/cli/shared/parse-port.ts) delegated to parseStrictPositiveInteger, which only enforces positivity. Any value above 65535 — the 16-bit TCP/UDP maximum — was returned as-is and reached the gateway-cli / node-cli / daemon-cli bind paths. The OS then surfaced the error at bind/connect time instead of the CLI rejecting it cleanly at parse time. The function's documented contract (number | null) implied a valid port, but the implementation didn't enforce the upper bound.

Changes

  • src/cli/shared/parse-port.ts: introduce a MAX_TCP_PORT = 65_535 constant and reject any parseStrictPositiveInteger result above it by returning null (the same shape callers already handle for zero, negative, NaN, and non-integer inputs).
  • src/cli/shared/parse-port.test.ts: new file. 5 regression cases covering nullish inputs, zero/negative (already-enforced), the valid range including the inclusive 65535 boundary, the issue's exact 99999 and 100000 repros, and non-integer / non-finite / NaN inputs.

Diff stat: 2 files, +48 / -1.

Real behavior proof

  • Behavior or issue addressed: Sanitized issue evidence — parsePort('99999') returned 99999, which then reached gateway-cli/run.ts:531 (portOverride = parsePort(opts.port)) and node-cli/daemon.ts:82 as a "valid" override. The OS-level bind error surfaces downstream instead of a clean CLI-level rejection.

  • Real environment tested: Local Node 22.x. Probe at /tmp/probe_83900.mjs (a) parses the patched parse-port.ts and verifies the MAX_TCP_PORT constant + the guard shape (parsed === undefined || parsed > MAX_TCP_PORT) + the preserved nullish early-return, and (b) replays both the patched and pre-fix shapes against 11 fixtures: valid 1 / 8080 / 65535, the issue's exact 99999, the boundary 65536, zero, negative, nullish undefined/null, string-form valid "3000", and string-form out-of-range "100000". Confirms patched returns null for out-of-range and the buggy shape returned the raw out-of-range integer that would have reached bind/connect.

  • Exact steps or command run after this patch: node /tmp/probe_83900.mjs

  • Evidence after fix:

PASS: MAX_TCP_PORT constant declared (16-bit boundary)
PASS: guard rejects undefined OR values above MAX_TCP_PORT
PASS: nullish-input early-return preserved
PASS: replay: all 11 fixtures (in-range / out-of-range / nullish / string-form) match patched and buggy shapes correctly
PASS: issue repro: buggy(99999)=99999 (would reach bind/connect), patched(99999)=null (clean rejection)

ALL CASES PASS
  • Observed result after fix: openclaw gateway run --port 99999 (or any other CLI surface that pipes through parsePort) now treats out-of-range port input identically to other invalid inputs: parsePort returns null, and the caller's existing ?? defaultPort / null-check path applies. No OS-level bind error from invalid 16-bit input.

  • What was not tested: Live openclaw gateway run --port 99999 smoke against an actual build — that requires pnpm build. The probe replays the predicate end-to-end against the issue's exact fixture, and the vitest regression test exercises the public parsePort contract directly.

Audit (per CLAUDE rules — all 5 steps)

  • Existing-helper check: Reuses the existing parseStrictPositiveInteger import; the new constant MAX_TCP_PORT is a single magic-number replacement for a well-known IANA value. No new helper. PASS
  • Shared-helper caller check: parsePort has 4 production callers — gateway-cli/run.ts:531, node-cli/daemon.ts:82, node-cli/register.ts:19, daemon-cli/install.ts. All four read the result as number | null and apply a default-or-error fallback for null. Adding the upper bound strengthens the existing null contract; no caller signature change. PASS
  • Broader-fix rival scan: gh pr list --search '83900 in:title,body' and gh pr list --search 'parsePort in:title,body' return no open PRs. PASS
  • Recent-merge audit: git log --oneline -5 -- src/cli/shared/parse-port.ts shows e1061a8b46 test(live): tolerate provider drift in release checks — unrelated. PASS
  • Prototype-pollution scan: N/A — single numeric comparison, no external-input key copying.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/cli/shared/parse-port.test.ts (added, +37/-0)
  • src/cli/shared/parse-port.ts (modified, +11/-1)

Code Example

return parseStrictPositiveInteger(raw) ?? null;
RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix parsePort accepts out-of-range port numbers (> 65535) [1 pull requests, 1 comments, 2 participants]