请使用 GitHub 的 Private vulnerability reporting / Security Advisory 私下报告以下问题：凭据泄露、Profile 数据越权、控制 socket 绕过、下载校验绕过、代理 失败后意外直连，或开发者模式权限绕过。

请提供受影响版本、macOS 版本与架构、最小复现步骤和已脱敏证据。不要在公开 Issue、 截图或日志中提交代理密码、VLESS URL、Cookie、Keychain 内容或真实个人数据。

当前安全修复范围覆盖仓库 main 分支和最新发布版本。第三方网站封禁、代理质量、 上游 fingerprint-chromium / Xray 漏洞和用户自行安装的扩展，应同时报告给对应上游； 若 WBrowser 的集成扩大了影响，也请一并报告给本项目。

Use GitHub Private vulnerability reporting / Security Advisories for credential exposure, cross-profile data access, control-socket bypasses, download-verification bypasses, unexpected direct-network fallback, or developer-mode authorization bypasses.

Include the affected version, macOS version and architecture, minimal reproduction steps, and redacted evidence. Do not place proxy passwords, VLESS URLs, cookies, Keychain content, or real personal data in public issues, screenshots, or logs.

Security fixes target the repository's main branch and latest release. Website blocking, proxy quality, upstream fingerprint-chromium/Xray issues, and user-installed extensions should also be reported to the relevant upstream. Please report here as well if WBrowser's integration increases the impact.

Managed fingerprint Chromium installation is fail closed against a compiled allowlist that binds the exact release tag, macOS DMG name, byte size, and SHA-256. GitHub release data may discover the approved asset but cannot approve a new one at runtime. The ordinary build also ignores WBROWSER_XRAY_PATH; un-pinned Xray selection exists only behind the explicit wbrowser_dev build tag and must never be enabled in a release build.

The source build keeps Go module compatibility at go 1.25.0, while release admission requires the pinned patched toolchain go1.26.5. The build stage restores npm dependencies from both lockfiles and performs the existing Wails post-build bundling without a Developer ID credential. Formal signing is a separate stage over the staged .app; review script/release.sh verify-sign-stage output before supplying a signing identity. The sign stage requires an out-of-band unsigned-ZIP digest, locks the resulting signature to Team 8UPRU238P7, and rejects any artifact that differs from that recorded digest. Release builds reject non-empty GOFLAGS, record that no user build tags were admitted, inspect the final Mach-O build settings, and reject the wbrowser_dev capability. The separate notarize stage requires the signed-ZIP digest, accepts only Apple Accepted, retrieves the private audit log, staples and Gatekeeper-verifies the app, then recreates the public ZIP and SHA256SUMS. A successful local build or signature alone is not proof of distribution readiness.

Both npm projects record exact reviewed lifecycle-script package versions in allowScripts; this makes the trust decision auditable but does not sandbox an approved install script. Formal release admission requires npm 11.17.0+ and uses npm ci --strict-allow-scripts; lockfile integrity checks and both full and production-only npm audit gates remain required.

Profile 代理中继只绑定 loopback，并随浏览器进程停止，但当前不向 Chromium 增加一层 WBrowser 自有认证令牌。同一 macOS 用户下、能够发现临时端口的本机进程属于相同信任 边界。把令牌放进 Chromium 命令行或同用户可读的临时文件不能形成可靠隔离；真正加强 该边界需要 App Sandbox/XPC 级设计。本项目将它记录为已知架构风险，而不声称本地恶意 进程隔离。

The per-Profile proxy relay is loopback-only and stops with the browser, but it does not add a WBrowser-specific authentication token. Local processes running as the same macOS user remain in the same trust boundary if they discover the ephemeral port. A token exposed through Chromium arguments or a same-user file would not provide meaningful isolation; materially strengthening this boundary requires an App Sandbox/XPC design. This is a documented architectural risk, not a claim of isolation from malicious local processes.