Skip to content

Vulnerability disclosure

Email security@z4j.com. PGP key: see SECURITY.md in the repo.

Include:

  • Description of the issue.
  • Steps to reproduce (minimal repro preferred).
  • Affected version(s).
  • Your contact info for follow-up.
  • File a public GitHub issue.
  • Post to public mailing lists / chat rooms / social before we’ve had time to respond.
  • Demonstrate the issue against systems you don’t own.

We follow the disclose.io baseline. You may research in good faith - we won’t pursue legal action for:

  • Testing on your own self-hosted brain.
  • Testing against our public dev/demo instance (if/when we host one).
  • Accidental access to data during good-faith research - with prompt disclosure.

We will not take legal action against researchers who:

  • Stop testing on discovery.
  • Don’t exfiltrate data beyond what’s needed to prove the bug.
  • Don’t disclose publicly before our patch is available.
EventTarget
Acknowledge receipt48 hours
Initial triage5 business days
Patch for critical7 days from triage
Patch for high30 days
Patch for medium/low90 days
Coordinated public disclosure90 days from patch, or immediate if already disclosed

We publish a SECURITY_HALL_OF_FAME.md in the repo, with researcher name (or pseudonym) and issue summary. Bug bounty is not currently offered; happy to recognize publicly and in release notes.

In scope:

  • Brain (z4j-brain).
  • Agent packages (z4j-*).
  • Wire protocol.

Out of scope:

  • Third-party queue engines (report to them).
  • Third-party infra (Postgres, Redis, etc.) - report upstream.
  • Denial-of-service via resource exhaustion on single-tenant self-hosted brain (operator owns resourcing).

Two rounds of internal audits pre-1.0 found and closed issues across authentication, session handling, and event redaction. Full details in docs/SECURITY_AUDIT_PRERELEASE.md (intentionally public - transparency).