#3778·clawhub

Possible false positive: loopback browser host permission classified as an untrusted install source

Author: schchitCreated Sep 17, 2026Updated Sep 17, 2026
Labelsr: rescan-guidancesecurityP2clawsweeper:source-reproclawsweeper:no-new-fix-prclawsweeper:needs-security-reviewimpact:securityissue-rating: 🦞 diamond lobster

Affected release

Observed result

The detailed audit dated 2026-09-17 06:12 UTC shows Review. Its visible static finding is:

  • Rule: suspicious.install_untrusted_source
  • Message: Install source points to URL shortener or raw IP.
  • Location: manifest.json:19
  • Evidence: "http://127.0.0.1/*"

The evidence is a Manifest V3 host_permissions entry for communication with a manually started local recorder. It is not an installation command or an executable download source. A rescan was requested through the owner UI on 2026-09-17; the UI acknowledged the request with Scanning. The rescan has now completed: the overview text and audit timestamp updated, but the outcome remains Review with the same static finding.

Context to review

The bundled daemon listens on 127.0.0.1. The extension validates loopback HTTP configuration and rejects redirects. Data endpoints require an explicit high-entropy token; /health reports limited availability/version information. The native OpenClaw entry registers only an optional jep_guard_health tool, which accepts no destination argument, requests a fixed loopback /health path, rejects redirects, and limits response size and duration. Loading the plugin does not start the daemon or install the extension.

The browser permission still deserves review: it grants loopback host access across ports, and local tokens/logs are sensitive. We are requesting accurate classification of this permission, not an exemption from reviewing those behaviors or a blanket safety endorsement.

Reproduction

  1. Inspect manifest.json at the pinned source commit above.
  2. Note that the matching URL appears under host_permissions.
  3. Inspect the published version's detailed static finding.
  4. Confirm whether the rule distinguishes browser connection permissions from install/download sources.

Validation scope

  • Local package tests: 21 passed, none skipped.
  • Plugin Inspector against OpenClaw 2026.9.4: zero breakages/warnings; runtime registration captured one tool and no hooks.
  • A real loopback daemon exercise checked authenticated recording, unauthorized requests, untrusted Origin rejection, nonce replay rejection, restart persistence, and the native health tool.
  • A complete installed OpenClaw Gateway/Chromium extension flow has not been validated. The recorder is not execution enforcement and its local hash chain is not an issuer signature.

Could maintainers review whether this is a permission-context false positive and, if confirmed, correct the finding or rule classification?