[GH-ISSUE #183] Loopback browser scope misclassifies IPv6 ::1 URLs #129

New issue

Closed

opened 2026-10-15 18:21:24 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:21:24 +00:00

Owner

Originally created by @morluto on GitHub (Jul 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/183

Problem

parseConfig/browserNetworkScope currently treats IPv6 loopback as external because it checks hostname === "127.0.0.1" || hostname === "[::1]". URL.hostname for http://[::1]:8080 is "::1" (Node canonical form), so an IPv6 loopback origin can be classified as external.

Impact

Permissions on browser artifacts may be overly permissive/incorrect (e.g., browserNetworkScope becomes external).
Behavior diverges from isLiteralLoopback in src/domain/browserObservation.ts, which already treats ::1 as loopback.
Affects consistency across MCP/CLI permission handling for local browser analysis.

Reproduction

const cfg = parseConfig({ browserNetworkScope: "127.0.0.1" /* via config env */ });
const parsed = parseBrowserOrigin("http://[::1]:8080", 0); // internal check path eventually compares host against browserNetworkScope logic

Using http://[::1]:port currently follows the same external scope path because the hostname string is ::1 not [::1].

Suggested fix

Normalize URL.hostname comparisons for IPv6 loopback, e.g. treat both ::1 and [::1] as loopback, or rely on robust loopback helpers used by observation parsing.

Evidence

src/config.ts in parseBrowserOrigin / browserNetworkScope host check
src/domain/browserObservation.ts isLiteralLoopback() already checks host === "::1" and hostname variants.

Originally created by @morluto on GitHub (Jul 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/183 ### Problem `parseConfig`/`browserNetworkScope` currently treats IPv6 loopback as external because it checks `hostname === "127.0.0.1" || hostname === "[::1]"`. `URL.hostname` for `http://[::1]:8080` is `"::1"` (Node canonical form), so an IPv6 loopback origin can be classified as external. ### Impact - Permissions on browser artifacts may be overly permissive/incorrect (e.g., `browserNetworkScope` becomes `external`). - Behavior diverges from `isLiteralLoopback` in `src/domain/browserObservation.ts`, which already treats `::1` as loopback. - Affects consistency across MCP/CLI permission handling for local browser analysis. ### Reproduction ```ts const cfg = parseConfig({ browserNetworkScope: "127.0.0.1" /* via config env */ }); const parsed = parseBrowserOrigin("http://[::1]:8080", 0); // internal check path eventually compares host against browserNetworkScope logic ``` Using `http://[::1]:port` currently follows the same external scope path because the hostname string is `::1` not `[::1]`. ### Suggested fix Normalize `URL.hostname` comparisons for IPv6 loopback, e.g. treat both `::1` and `[::1]` as loopback, or rely on robust loopback helpers used by observation parsing. ### Evidence - `src/config.ts` in `parseBrowserOrigin` / `browserNetworkScope` host check - `src/domain/browserObservation.ts` `isLiteralLoopback()` already checks `host === "::1"` and hostname variants.

bsakaguchi

2026-10-15 18:21:24 +00:00

closed this issue
added the
area: runtime

enhancement
labels

bsakaguchi commented

2026-10-15 18:21:25 +00:00

Author

Owner

@morluto commented on GitHub (Jul 14, 2026):

Additional affected path: BrowserObservationService.ts contains the same IPv6 loopback check bug as config scope parsing. At line 123 it currently treats IPv6 loopback as '[::1]' (with brackets), but Node URL.hostname provides '::1' for URLs like http://[::1]:port, so browser observation scope validation can incorrectly reject local targets.

This is the same root cause as this issue, but in the application/browser scope gate path.

@morluto commented on GitHub (Jul 14, 2026): Additional affected path: `BrowserObservationService.ts` contains the same IPv6 loopback check bug as config scope parsing. At line 123 it currently treats IPv6 loopback as `'[::1]'` (with brackets), but Node `URL.hostname` provides `'::1'` for URLs like `http://[::1]:port`, so browser observation scope validation can incorrectly reject local targets. This is the same root cause as this issue, but in the application/browser scope gate path.

bsakaguchi commented

2026-10-15 18:21:25 +00:00

Author

Owner

@morluto commented on GitHub (Jul 17, 2026):

Implemented on main via the shared isLiteralLoopbackHostname helper. Both config browserNetworkScope and BrowserObservationService now recognize canonical ::1, with IPv6 coverage in tests/config.test.ts and tests/browserObservation.test.ts.

@morluto commented on GitHub (Jul 17, 2026): Implemented on main via the shared isLiteralLoopbackHostname helper. Both config browserNetworkScope and BrowserObservationService now recognize canonical ::1, with IPv6 coverage in tests/config.test.ts and tests/browserObservation.test.ts.

bsakaguchi referenced this issue

2026-10-16 21:11:48 +00:00

[PR #129] [MERGED] feat: add passive website reverse engineering #1851

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:28:45 +00:00