Responsible Disclosure Policy

This policy covers the Yerba web application and its public APIs, served from yerba.chatand its subdomains. If you have found a flaw that could expose creator or visitor data, bypass our bot protection on the link redirect, let one account read or change another's data, or otherwise compromise the integrity of the service, we want to hear about it. For a broader view of how we approach security and safety, see our Trust & Safety page.

This policy is for security vulnerabilities. If you want to flag harmful content or abuse rather than a technical flaw, our Trust & Safety policy covers what we consider harmful and how we handle it.

Email support@yerba.chat with the subject line "Security" and enough detail for us to reproduce and confirm the issue. A good report usually includes:

Plain email is fine for an initial report. If you need to share sensitive technical details like exploit code, say so in a short first message and we will arrange a secure channel before you send anything exploitable.

Please report promptly after you discover an issue, keep the details private until we have had a chance to fix it, and only ever access or modify your own test accounts and data. We handle any contact details you share with us in line with our privacy policy.

We will not pursue or support legal action against researchers who act in good faith and follow this policy. If you make a genuine effort to avoid privacy violations, data destruction, and service disruption, stay within the scope above, and give us a reasonable chance to respond before disclosing anything publicly, we will treat your research as authorized and work with you. If a third party brings a claim against you for work that followed this policy, we will make it known that your actions were authorized.

We will acknowledge your report within a few business days, keep you updated as we investigate, and let you know once the issue is resolved. We aim to triage quickly and to fix confirmed issues on a timeline that matches their severity, with the most serious ones prioritized first. We ask researchers to give us 90 days from our acknowledgement to resolve critical issues before any public disclosure, and we are glad to coordinate timing with you if you plan to publish. We are a small team and do not currently run a paid bug bounty program, but we are glad to credit researchers who report valid issues, if you would like the recognition.

Some activities are not covered by this policy and are not authorized. Please do not test for or report the following:

• Social engineering. Phishing or any attempt to trick our staff, creators, or fans.
• Physical attacks. Anything targeting our offices, hardware, or people.
• Denial of service. Volumetric, load, or resource-exhaustion testing against the service or its infrastructure.
• Third-party services. Issues in platforms and vendors we rely on (hosting, auth, payments, and similar). Report those to the provider directly.
• Low-impact noise. Spam, automated scanner output without a working proof of concept, missing rate limits, or best-practice and header suggestions that carry no real-world risk.

A machine-readable version of our security contact is published as security.txt (served from /.well-known/security.txt), following the standard convention so tools and researchers can find the right address automatically.