Skip to content
Carabase Host

Vulnerability disclosure

If you’ve found a security issue in Carabase Host — credential leakage, authentication bypass, RLS escape, supply-chain risk, anything else that breaks the threat model — we want to hear about it before it’s public.

How to report

Section titled “How to report”

Preferred: GitHub Security Advisories (private vulnerability reporting). Go to the repo’s Security tab and click Report a vulnerability. This creates a private advisory only the maintainers can see.

Alternative: email. Send to security@carabase.dev. (PGP key + fingerprint will be published once we set up the mailbox.)

Please include:

  • A description of the issue and what an attacker could do with it
  • Affected version(s) — GET /api/v1/version reports the running version
  • Steps to reproduce, or a proof-of-concept if you have one
  • Your preferred attribution (real name / handle / anonymous)

What we promise

Section titled “What we promise”
  • Acknowledgement within 72 hours of receiving the report
  • A fix or mitigation plan within 14 days for high/critical issues, 30 days for moderate, best-effort for low
  • A coordinated disclosure window — we’ll agree on a date for public disclosure together, default 90 days from acknowledgement
  • Public credit in the security advisory, unless you prefer to stay anonymous

Scope

Section titled “Scope”

In scope:

  • The carabase-host repo (this codebase) at any tagged release
  • The Admin SPA bundle served at /admin/
  • The MCP server at /mcp/sse
  • The shell scripts under scripts/ that ship with the host

Out of scope:

  • The OpenClaw gateway itself — that’s a separate project with its own disclosure process
  • Tailscale — report directly to tailscale.com/security
  • Issues in third-party connectors (GitHub, Google, Granola) — report to the respective vendor
  • Dependency CVEs that already have a public CVE — open a regular issue or PR
  • DoS / resource exhaustion attacks — single-tenant, self-hosted; denying the service to yourself isn’t a meaningful attack
  • Social engineering / phishing the maintainer — not a software vulnerability

What you should NOT do

Section titled “What you should NOT do”
  • Don’t test against installs you don’t own
  • Don’t publicly disclose before the agreed window
  • Don’t demand bug bounty payment — this is an OSS project run by individuals, not a company with a budget. We’ll do our best to credit and amplify your work, but we can’t pay

Recent advisories

Section titled “Recent advisories”

(None yet. This page will list all CVEs / GHSA advisories once we publish any.)