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
Capgo Backend & Landing
Main Capgo repository including backend services and landing website
Capgo CLI
Command-line interface for managing Capgo deployments and live updates
Capacitor Updater Plugin
The core Capacitor plugin that handles over-the-air updates on mobile devices
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
Important: If you cannot provide the exact line of code in GitHub where the problem exists, your report will not be eligible for the Bug Bounty program. Reports must be submitted through GitHub Security Advisory only. Payments are handled via Algora.io; please create an account there so we can pay you directly on the platform.
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.
Important: Payments are issued only after we have identified the issue, fixed it, opened a pull request, and you have verified after release that the fix works for you. This process usually takes between 20 and 30 days. Please do not send messages like "to get paid"; payment happens only once the release is live and you've tested and validated the fix.
How to Report
- Navigate to the relevant repository on GitHub
- Click on the "Security" tab
- Click "Report a vulnerability" to create a new security advisory
- Include the exact file path and line number(s) where the vulnerability exists
- 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
- Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase).
- Social engineering or phishing attempts
- Denial of service attacks
Supabase and Third-Party Services
If the root cause is a Supabase platform or service bug, report it to Supabase, not Capgo. If the vulnerable logic, SQL, RPC, RLS policy, Edge Function, or configuration was created or chosen by Capgo and we can fix it in our project, it is in scope even when Supabase serves the endpoint. For findings about Supabase behavior itself, include a reproducible case and the exact Supabase setting or config change that prevents it in a project configured like ours.
Examples
Not valid here
- A Supabase platform bug, outage, or behavior that only Supabase can fix
- A finding you cannot reproduce
- A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change
Valid here
- A Capgo-controlled Supabase misconfiguration we can fix in our project settings (with steps)
- A Capgo-owned SQL, RPC, RLS, function, or integration issue that causes insecure Supabase usage
- A reproducible issue in Capgo's Supabase project, schema, or policies, even if it is exposed through a Supabase endpoint
Known Supabase Auth Limitations (Already Reported)
Some findings are repeatedly reported and are caused by Supabase Auth defaults or platform behavior rather than Capgo code. We review these only when they can be reproduced in a shared Supabase demo project configured like ours and when the fix is a Supabase-side configuration change that does not require changing Capgo security rules. If the fix requires changing Capgo-owned SQL, RPCs, RLS policies, functions, or app logic, report it to us because that is in scope.
- Provide a reproducible case and identify the exact fix: either the Supabase setting/config change that resolves a Supabase behavior issue, or the Capgo-owned code/config object that must change.
- 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 or a concrete Capgo-owned security defect, we can consider it in scope.
For questions about our Bug Bounty program, please reach out through our GitHub Security Advisories.