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”

Email security@carabase.dev. Send your report privately so we can triage and fix before any public disclosure.

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 application at any tagged release
  • The Admin SPA bundle served at /admin/
  • The inbound MCP surface (/mcp streamable HTTP and the legacy /mcp/sse + /mcp/messages SSE transport) and its access gate
  • The operator shell scripts that ship with the host

Out of scope:

  • The OpenClaw gateway itself — that’s a separate project with its own disclosure process
  • The local vendor CLIs that the codex_cli / claude_code chat and agent runtimes shell out to (Codex, Claude Code) — report those to their respective vendors; issues in how the host invokes them (e.g. an escape past the read-only token gate) are in scope
  • Tailscale — report directly to tailscale.com/security
  • Issues in third-party connectors (GitHub, Google, Granola, and the other integrations) — report to the respective vendor
  • Dependency CVEs that already have a public CVE — report it to us by email
  • 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 a small 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 advisories once we publish any.)