Skip to content
Open Breno

Report a vulnerability

How to report a security problem in Breno, what to include, what testing is acceptable, and what to expect.

If you believe you have found a security problem in Breno, please tell us. We would rather hear about it from you than not at all.

How to report#

Email contact@breno.ng with the subject starting Security report, or use the contact form and choose Security report. Do not post details publicly until we have had a chance to fix it.

A machine-readable version of this policy is at /.well-known/security.txt.

What to include#

  • What you found, and where (the address or the feature).
  • How to reproduce it, step by step.
  • What an attacker could do with it, in your assessment.
  • Anything that would help us confirm it: requests, responses, a short recording.
  • How to reach you, if you want a reply.

Testing: what is acceptable#

  • Test only against an instance you own, or have written permission to test.
  • Do not access, change or delete data that is not yours while demonstrating a problem. Stop as soon as you have shown that it is real.
  • Do not run denial-of-service, spam or social-engineering attacks, and do not test physical security.
  • Do not use a finding to read another person's data.

Reports that respect this are ones we can act on quickly. Testing that does not is itself a problem.

What to expect from us#

A person reads every report. We will confirm what we find and keep you informed about the fix. We do not run a paid bounty program, and we do not publish a response deadline we cannot promise to meet.

Not a vulnerability#

Missing best-practice headers with no demonstrated impact, theoretical issues without a way to exploit them, and the items already documented on Known limits (for example, that source permissions are not read from connected tools) are better raised as feedback than as vulnerabilities.