跳过主要内容
Capgo logo

漏洞赏金计划

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

查看仓库 报告安全问题

Capacitor Updater Plugin

The core Capacitor plugin that handles over-the-air updates on mobile devices

查看仓库 报告安全问题

有效报告要求

要符合 Bug Bounty 计划，报告必须满足以下所有要求：

  • 您必须在我们的 GitHub 仓库中准确标识出存在漏洞的文件和行号
  • 您的报告必须通过 GitHub 的安全建议在相关仓库中提交
  • 您必须提供漏洞的清晰描述及其潜在影响
  • 您必须提供可复现的步骤来演示问题

注意： 如果您无法提供存在问题的 code 文件中的 GitHub 行号，报告将不符合 Bug Bounty 计划的要求。报告必须通过 GitHub 的安全建议提交。支付将通过 Algora.io 处理，请在该平台上创建账户以便我们直接在该平台上支付给您。

响应时间和尊严

我们友好并且会为有效报告支付，但我们无法与不尊严我们时间的人合作。请保持沟通平和，并遵循此计划。

  • 我们将在 24-72 小时内响应安全报告和漏洞。
  • 请勿向我们发送垃圾邮件。超过三封邮件在同一天发送将被视为垃圾邮件并被阻止。
  • 我们不会为忽视这些规则或发送垃圾邮件的报告支付。
  • 我们只接受遵循此漏洞赏金计划的在范围内的报告;其他任何内容可能会被阻止。
  • 请勿询问状态更新，如"您是否检查了?"或类似问题。我们确认收到您的报告后，已经足够了。之后，仍然有大量工作需要做，准备一个拉取请求可能需要几天时间。

重要提示： Capgo 是一个小型自举公司，因此我们的赏金金额较低。没有明确的利用路径的报告将支付至多 $30。具有真实、可复现影响的 Capgo 漏洞将支付至多 $300。我们接受并审查安全报告的 Capgo 插件，但针对 code 插件的付费赏金仅限于 @capgo/capacitor-updater。其他 Capgo 插件是免费使用的，不属于我们的付费产品，因此报告将被审查但不付款。我们只在我们确定问题、修复它、打开拉取请求并您在发布后验证修复有效时才会发放付款。这整个过程通常需要 20-30 天。请勿发送类似"获取付款"的消息；付款只在发布后且您已测试和验证修复时才会发生。

如何报告

  1. 请前往 GitHub 相关仓库
  2. 点击 "安全" 标签
  3. 点击 "报告漏洞" 以创建一个新的安全建议
  4. 包含漏洞存在的确切文件路径和行号
  5. 提供详细步骤来复现问题并解释安全影响

不在范围内

  • Reports without exact code line references in GitHub
  • 通过 GitHub Security Advisory 未提交的报告
  • 理论漏洞没有概念证明
  • 第三方平台、依赖项或服务的漏洞， Capgo 无法直接修复（请向上游报告，例如 Supabase）
  • 社会工程或钓鱼攻击
  • 拒绝服务攻击
  • SSRF 或 DNS 欺骗报告针对 webhook 或网站预览。这些功能在无服务器基础设施上运行，无法用于访问私有 Capgo 基础设施，因此它们在我们的环境中不可利用。
  • User-owned application code or project configuration that Capgo does not own, ship, or control, including files such as capacitor.config.ts, config.capacitor.ts, app source code, and environment-specific settings.
  • 访问Capgo包文件或证明包文件可以下载。包文件是公共的Web资产,用户已知此信息,并且访问它们不被认为是数据泄露。

Supabase和第三方服务

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.

示例

这里无效

  • 仅有Supabase可以修复的Supabase平台bug,停机或行为
  • 无法复现的发现
  • A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change

有效

  • 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
  • 在Capgo的Supabase项目、模式或策略中出现可重现的问题，即使它是通过Supabase端点暴露的

已知的Supabase Auth限制（已报告）

有些发现反复报告，原因是Supabase Auth的默认设置或平台行为，而不是Capgo code。我们只会在这些发现可以在我们的Supabase示例项目中重现，并且修复需要在Supabase端进行配置更改，而不需要更改Capgo安全规则时才会进行审查。如果修复需要更改Capgo拥有的SQL、RPC、RLS策略、函数或应用逻辑，请将其报告给我们，因为这在我们的范围内。

  • 提供可重现的案例并确定具体的修复：要么是Supabase设置/配置更改来解决Supabase行为问题，要么是Capgo拥有的code/配置对象需要更改
  • 电子邮件验证行为应遵循您的Supabase Auth项目设置（例如，是否禁用电子邮件确认并使用捕获式认证）
  • 密码更新和账户恢复流程可能不总是需要旧密码重新输入或重新验证，如果Supabase Auth配置为这样
  • 如果问题在此列表中，但您可以在提供的项目中显示一个具体的Supabase端修复或一个具体的Capgo安全缺陷，我们可以考虑它在我们的范围内

有关我们的Bug Bounty计划的任何问题，请通过我们的GitHub安全咨询联系我们