Thanks for taking the time to disclose a vulnerability responsibly. Rembric is maintained as a single-process self-hosted server that stores operator memory in a local SQLite file — security issues in this code base may affect the integrity, confidentiality, or recoverability of that memory in operator deployments. We take reports seriously.
Rembric is pre-1.0. Only the latest minor release on main is supported for
security fixes; older minors are best-effort. Operators are encouraged to track
the latest published ghcr.io/susomejias/rembric:v* tag and follow the upgrade
notes in docs/docker.md.
| Version line | Supported |
|---|---|
| latest minor | ✅ active fixes |
| any older | ❌ best-effort, no SLA |
Once the project ships v1.0.0, this policy will be updated with a formal
support window (likely the current and previous minor).
Preferred: GitHub Security Advisories. Go to the repository's
Security tab and
click Report a vulnerability. This opens a private channel between you and
the maintainer; do not file a public issue.
Email fallback: if you cannot use Security Advisories for any reason
(corporate firewall, anonymous report, …), email rembric@susomejias.dev
with subject line [rembric-security] <short description>.
When you report, please include:
- Affected version(s) — output of
GET /healthzfrom the running server, or the tag of the Docker image you pulled. - Reproduction steps. A minimal reproducer in a fresh
pnpm run dev:docker:upenvironment is ideal. - Impact assessment from your end — what an attacker could read, modify, or deny.
- Your preferred disclosure timeline (default: see "Disclosure timeline" below).
- Whether you want public credit for the fix and the name / handle / URL you want listed.
You do not need to provide a fix. We appreciate when reporters do, but a clear reproducer is enough to act on.
- We acknowledge receipt within 5 business days.
- We aim to triage (confirmed / can't reproduce / out of scope) within 10 business days.
- We aim to ship a fix for confirmed high-severity issues within 30 days. Lower-severity issues may roll into the next regular release.
If you do not receive acknowledgement within 5 business days via Security Advisories, the email fallback above is the right next step. If the email also goes unanswered for another 5 business days, you may publicly disclose at your discretion — we will not penalise that.
Default coordinated disclosure: 90 days from acknowledgement, or 7 days after a fix is publicly released, whichever comes first.
Pre-1.0 versions are not eligible for coordinated disclosure beyond best-effort: because the project is still pre-stable, a "fix" may require an interface change. We will work with you to find a reasonable disclosure path but cannot commit to a backward-compatible patch on older minors before v1.0.0.
In scope:
- The Rembric server (everything under
apps/server/src/). - The shipped Docker image (
ghcr.io/susomejias/rembric:*). - The shared plugin tree (
apps/plugin/) and every client plugin built from it: Claude Code, Codex CLI, Hermes Agent, opencode, and Pi. - The MCP tool surface and the HTTP API exposed at
/mcp,/mcp/<slug>,/api/<slug>/sessions*,/dashboard*,/healthz, and the OAuth 2.1 endpoints (/authorize,/token,/register,/revoke,/.well-known/oauth-*,/dashboard/oauth/consent).
Out of scope (please do not spend time on these):
- Vulnerabilities in dependencies that are already in our SBOM and have a published advisory — we track these via Dependabot / release-please and will pick up patches in the normal release cadence.
- Misconfiguration of the operator's deployment (exposing the server to the open internet without TLS, sharing the admin token, etc.) — operationally outside the project's control. See the README's "Project status" section for the data-protection contract.
- Reports based on third-party security scanners without a demonstrated
exploit path on a default-configuration
pnpm run dev:docker:up. - Best-practice suggestions ("you should use Argon2 instead of bcrypt-style hashing") — open a regular issue or PR for these.
- We will credit reporters who request it (in the GitHub Advisory and the release notes).
- We will publish a Security Advisory with the CVE (once assigned) on every confirmed high-severity issue.
- We will not offer a paid bug bounty.
- We will not pursue legal action against good-faith research conducted within the scope above.
This policy itself is a living document. Pull requests welcome.