GoClaw Browser Tool Local File Disclosure via file:// URLs

Vulnerability Overview Title: [Security] Authenticated Browser Tool File Navigation Allows Local File Disclosure via URLs #1207 Description: An authenticated user with or higher privileges can navigate to a URL via GoClaw's browser tool and recover file contents using standard page reading primitives (such as and ). This results in the arbitrary disclosure of local files within the file access scope of the GoClaw browser process user. Detailed Information: The issue lies in the direct tool invocation path exposed by . After authentication and role enforcement, the handler accepts attacker-controlled JSON parameters, copies the into tool arguments, and dispatches the request directly to the registered tool implementation. In the affected code paths: - accepts authenticated requests and forwards attacker-controlled parameters to the tool registry. - reads in , only checking that it is non-empty. - passes directly to pointing to the page, without any scheme whitelist. Therefore, an attacker can provide a payload such as: Once the browser reaches the local file, the same authenticated caller can read the page text via the expected product functionality: This is not a synthesized internal condition. Verification used the actual public handler, the production browser tool, and a real Chrome CDP target. The observed result was successful navigation to and recovery of the canary string from the rendered page. Scope Ecosystem: Go Package Name: github.com/nextlevelbuilder/goclaw Affected Versions: <= 3.13.3-beta.3 Fixed Version: Not provided Remediation Severity: Medium Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Weakness: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor POC Code Prerequisites A GoClaw deployment exposing The tool enabled An accessible Chrome/Chromium CDP endpoint An authenticated account with or higher privileges No runtime URL scheme allow-list blocking A target file readable by the OS user running the GoClaw browser process Reproduction Steps 1. Copy the main verification script from . 2. Copy the control script from . 3. Download support files to replicate the integration test setup: - - - 4. Run the verification script from the repository root: 5. Observe the script: - Create a canary file - Call with and URL - Call with to read page text 6. Run the control script: 7. Confirm that the control case navigates to and does not expose the canary. Evidence Logs The verification log shows the following runtime evidence: The control log shows: Impact This is an authenticated information disclosure vulnerability. Any authenticated user with access to the browser tool can read local files accessible by the OS user running the GoClaw browser process. In practice, this may expose deployment local configurations, workspace files, logs, tokens inadvertently written to disk, proxy artifacts, or other sensitive local data. Occurrence Permanent Link: goclaw/internal/http/tools_invoke.go Permanent Link: goclaw/pkg/browser/tool.go Permanent Link: goclaw/pkg/browser/browser_page.go Comments mrpoone 3 weeks ago: - Summary: I triangulated against existing fix paths in the current queue, which appear to target the same browser navigation guard surface. Repetition: #fix-in-review#Evidence-n This issue reports that accepts URLs via , then exposes rendered file content via / n-Existing PR #891 is titled disclosure acceptance case rather than creating a parallel fix n. This issue has no priority maintainer comments, nor a separate merged PR found for this exact browser file navigation disclosure-nexxt steps: Verify that PR #891 specifically blocks non-web/local file schemes ( , and any other dangerous local/web schemes) prior to navigation, and covers direct tool invocations via , with regression tests. Keep this issue open until the fix PR is merged and verified. mrpoone 3 weeks ago: - Added labels: , , , , clark-cant 2 weeks ago: - Added labels:

Goal Reached Thanks to every supporter — we hit 100%!

GoClaw Browser Tool Local File Disclosure via file:// URLs

More from this source