Bug Bounty Program

Capgo is committed to security and transparency. All our code is open source, and we welcome security researchers to help us identify vulnerabilities in our codebase.

Open Source Code

Every repository in the Capgo organization is open source. You can review, audit, and contribute to our code.

GitHub Organization: github.com/Cap-go

Requirements for Valid Reports

To qualify for the Bug Bounty program, your report must meet ALL of the following requirements:

• You must identify the exact file and line number in our GitHub repository where the vulnerability exists
• Your report must be submitted through GitHub Security Advisory on the relevant repository
• You must include a clear description of the vulnerability and its potential impact
• You must provide reproducible steps to demonstrate the issue

Response Time and Respect

We are friendly and we do pay for valid reports, but we cannot work with people who do not respect our time. Please keep communication calm and follow this program.

• We respond to security reports and breaches within 24-72 hours.
• Do not spam us. More than three emails in a single day is considered spam and will be blocked.
• We do not pay for reports that ignore these rules or are spam.
• Only in-scope reports that follow this bug bounty program are accepted; anything else may be blocked.
• Do not ask for status updates such as "have you checked?" or similar questions. Once we confirm we received your report, that is enough. After that, there is still significant work to do, and preparing a pull request can take several days.

How to Report

1. Navigate to the relevant repository on GitHub
2. Click on the "Security" tab
3. Click "Report a vulnerability" to create a new security advisory
4. Include the exact file path and line number(s) where the vulnerability exists
5. Provide detailed steps to reproduce the issue and explain the security impact

Out of Scope

• Reports without exact code line references in GitHub
• Reports not submitted through GitHub Security Advisory
• Theoretical vulnerabilities without proof of concept
• Issues in third-party dependencies or services (report these upstream, e.g. Supabase).
• Social engineering or phishing attempts
• Denial of service attacks

Supabase and Third-Party Services

If the issue is in Supabase and tied to a Supabase endpoint, report it to Supabase (not Capgo). We only accept Supabase-related reports if you can reproduce it and show the exact Supabase setting/config change that prevents it in a project configured like ours.

Examples

Known Supabase Auth Limitations (Already Reported)

We only review these findings when they can be reproduced in a shared Supabase demo project that mirrors our setup. In this workflow, the behavior must be confirmed as a Supabase Auth default/capability and fixed in Supabase configuration only, without changing Capgo security rules.

• Provide a reproducible case and the exact Supabase setting/config change in the demo project that resolves the issue while keeping your existing rule set intact.
• Email verification behavior is expected to follow your Supabase Auth project settings (for example, whether email confirmation is disabled and capture-based auth is used).
• Password update and account-recovery flows may not always require old-password re-entry or re-verification if Supabase Auth is configured that way.
• If the issue is in this list but you can show a concrete Supabase-side fix in the provided project, then we can consider it in scope.

For questions about our Bug Bounty program, please reach out through our GitHub Security Advisories.