browser.proxy profile mutations now blocked on gateway path

eleqtrizit

·Apr 7, 2026·#60489fix(browser): align browser.proxy profile mutation guards

A security gap has been closed: persistent browser profile create, reset, and delete operations through browser.proxy are now blocked on both the gateway-forwarded node.invoke path and the node-host proxy path, regardless of whether a profile allowlist is configured.

The browser extension's node-host proxy path had restrictions in place to prevent browser.proxy calls from mutating persistent browser profiles—but those restrictions didn't apply when the same operations were forwarded through the gateway's node.invoke handler. That inconsistency created a security gap. A call to create, reset, or delete a persistent profile through the gateway could slip past guards that would catch it on the direct node-host path.

The fix makes the mutation check unconditional on the node-host side and adds the same guard to the gateway handler. On the gateway side, new path-normalization logic handles the variety of ways a path string might arrive—missing leading slashes, trailing slashes, inconsistent casing—and determines whether the operation targets a persistent profile. If it does, the request is rejected with an INVALID_REQUEST error before forwarding.

Profile allowlists remain intact as an additional layer, but they no longer gate the mutation guard. The restriction now applies universally, which closes the bypass and simplifies the security model.

View Original GitHub Description

Summary

align node.invoke(browser.proxy) with the existing persistent profile mutation restrictions
keep the node-host proxy path blocked even when no profile allowlist is configured

Changes

reject persistent browser profile create/reset/delete requests in the gateway node.invoke handler before forwarding browser.proxy
make the node-host browser.proxy mutation check unconditional instead of tying it to allowProfiles
replace the legacy node-host bypass test with a rejection case and add a gateway regression test for the forwarded browser.proxy path

Validation

ran corepack pnpm test -- extensions/browser/src/node-host/invoke-browser.test.ts
ran corepack pnpm exec vitest run --config vitest.gateway.config.ts src/gateway/server.node-invoke-approval-bypass.test.ts --pool=forks
ran claude -p "/review" before opening the PR; the command returned without code feedback because it requested PR context instead

Notes

full pnpm check is currently blocked by unrelated pre-existing TypeScript errors in extensions/feishu, extensions/matrix, and extensions/signal
no existing GHSA-linked fix PR or private fork was present for this advisory at implementation time