Skip to content

Security: bigbraingoldfish/lullabeast

Security

SECURITY.md

Security Policy

Security model

The Lullabeast dashboard and every route under /api/* are protected by a single shared access token (AUTODEV_UI_TOKEN, generated by install.sh into .env). A browser is authorized once via the tokenized URL printed at server startup (/?token=…, which sets an HttpOnly SameSite=Lax cookie); scripts send the same value as Authorization: Bearer <token>. The query-string channel is honored only on /, so the token never appears in API request logs. This is single-user, local-tool authentication — one token, no user accounts, roles, or audit trail.

When no token is configured the server falls back to a legacy open mode: loopback requests are served unauthenticated, and requests from any non-loopback address are refused (403). Two routes are always exempt: GET /health (liveness — returns only {"ok": true}) and /static/* (frontend assets).

The UI and API are designed to run on loopback (127.0.0.1, port 18790) and must not be exposed to untrusted networks without a reverse proxy, TLS, and access control in front — the shared token is a local-tool lock, not a substitute for those. See SETUP.md — Security and network exposure for binding options.

The agent pipeline (planner → executor → reviewer) executes code on the host machine. The trust boundary is the local user account: anyone who can invoke the pipeline API can cause code to run under the account that owns the Lullabeast process. Treat this as operator tooling for a trusted machine, not a multi-tenant service.

Reporting vulnerabilities

Non-sensitive findings (documentation gaps, missing headers, hardening suggestions): open a GitHub issue with the title prefix [SECURITY].

Sensitive findings (credential exposure, remote code execution, authentication bypass): use GitHub's private vulnerability reporting so the report is not publicly visible until a fix is prepared.

Do not send vulnerability reports by email. We do not publish a security contact address.

Scope

In scope:

  • The pipeline agents and their gate scripts (autodev/pipeline/gate_scripts/)
  • The UI server (ui/server.py) and its API routes
  • The install script (install.sh) and its handling of secrets and file permissions
  • The environment variable contract (.env, .env.example, AUTODEV_UI_TOKEN, AUTODEV_HOOKS_TOKEN, OPENCLAW_ROOT, AUTODEV_REPO_PATH)

Out of scope:

  • The underlying LLM models or their hosted APIs (OpenRouter, Anthropic, etc.)
  • OpenClaw itself — it is a separate project and has its own security surface
  • Issues in third-party Python dependencies that are not exploitable via Lullabeast's code paths (report those upstream)

Known limitations

Limitation Detail
Single shared access token One token guards the dashboard and all of /api/*. There are no per-user accounts, roles, individually revocable sessions, or audit trail. Rotate by changing AUTODEV_UI_TOKEN in .env and restarting the server (existing browser cookies stop working).
Loopback-only recommendation LAN or internet exposure without a reverse proxy + TLS is not supported and not recommended. With no token configured, non-loopback requests are refused outright.
No rate limiting The API has no rate limiting on any route. An attacker who can reach the port can call endpoints without restriction.
.env stores secrets in plaintext install.sh writes AUTODEV_UI_TOKEN (the dashboard access token) and AUTODEV_HOOKS_TOKEN (the OpenClaw webhook Bearer token) to .env as plaintext. This is standard practice for local tooling but means the file should be treated as a credential: chmod 600 .env, do not commit it, do not check it into shared storage. The startup banner also prints the tokenized dashboard URL to stdout, so service logs (e.g. journald) contain it.
Agent pipeline runs as local user Gate scripts and the orchestrator run with the same OS privileges as the process that starts them. There is no sandboxing below the user account.
Preflight may git init the target directory When you point Setup & Preflight at a directory that is not yet a git repository, it auto-initializes one (git init + an initial commit) so the pipeline has a HEAD to build on. Preflight refuses this when the target contains other git repositories (i.e. you aimed it at a parent of your projects), but you should still point Lullabeast at a single project directory — not a parent folder — since the pipeline runs git add . in that tree every phase.

There aren't any published security advisories