Skip to content
z4j docs

Vulnerability disclosure

Reporting

Section titled “Reporting”

Email [email protected]. We do not currently publish a PGP key. If the details should not travel in plain email, send only a contact request first; we will arrange a private channel and publish its fingerprint before asking you to send the report.

Include:

  • Description of the issue.
  • Steps to reproduce (minimal repro preferred).
  • Affected version(s).
  • Your contact info for follow-up.

Please do not

Section titled “Please do not”
  • 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.

Safe harbor

Section titled “Safe harbor”

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 demo instance at demo.z4j.dev.
  • 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.

Response timeline

Section titled “Response timeline”
Event Target
Acknowledge receipt 48 hours
Initial triage 5 business days
Fix a confirmed critical issue 7 days from confirmation
Fix any other confirmed issue 30 days from confirmation
Coordinated public disclosure 90 days from your first report

For a critical issue under active exploitation, we disclose as soon as a fix is available and you consent. Triage and fix time come out of our 90-day window, not yours.

Credit

Section titled “Credit”

With your permission, we credit you by name or pseudonym in the release notes and any published advisory. We do not currently offer a bug bounty.

Scope

Section titled “Scope”

In scope:

  • The brain (z4j) and every official z4j-* package on PyPI.
  • The wire protocol.
  • Official z4jdev/* Docker images.
  • Our hosted infrastructure at z4j.com, z4j.dev, and demo.z4j.dev.

Out of scope:

  • Third-party queue engines (report to them).
  • Third-party infra (Postgres, Redis, etc.) - report upstream.
  • Denial of service that requires the attacker to spend excessive resources.

A cheap resource-exhaustion path available to one project or one low-privilege user against a shared brain is in scope. The product enforces per-project ceilings and request throttles; a practical bypass of those boundaries is something we want reported.

Published advisories

Section titled “Published advisories”

Published advisories appear under z4jdev/z4j security advisories with a GHSA ID and, when GitHub's CNA assigns one, a CVE ID. Security fixes shipped without a coordinated advisory remain recorded with their fixed-in versions in the project CHANGELOG.md.

What we know about and have not fixed

Section titled “What we know about and have not fixed”

Findings we raise ourselves and then decide to defer get no response clock, because nobody is waiting on us. They get a public entry instead, with the mitigation available today and what has to be true before it comes off the list. One is open now: the in-database boundaries do not hold against a role that can write their tables. See threat model and HMAC audit chain.