跳过主要内容
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

查看仓库 报告安全问题

有效报告要求

要符合漏洞赏金计划，报告必须满足以下所有要求：

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

重要： 如果您无法提供存在问题的code在GitHub中的确切行号，报告将不符合漏洞赏金计划的要求。报告必须通过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 安全建议提交的报告
  • 理论上的漏洞没有概念证明
  • 第三方平台、依赖项或服务的漏洞， Capgo 无法直接修复（请向 Supabase 等上游报告）
  • 社会工程或钓鱼攻击
  • 拒绝服务攻击
  • SSRF 或 DNS 欺骗报告针对 webhook 或网站预览。这些功能在无服务器基础设施上运行，无法用于访问私有 Capgo 基础设施，因此它们在我们的环境中不可利用。
  • 用户拥有的应用程序 code 或项目配置，Capgo 不拥有、运输或控制，包括文件，如 capacitor.config.ts、config.capacitor.ts、应用源 code 和环境特定设置。
  • 访问 Capgo 包文件或证明包文件可以下载。包文件是公共网络资产，用户已知此信息，访问它们不被视为数据泄露。

Supabase 和第三方服务

如果根源是 Supabase 平台或服务错误，请向 Supabase 报告，而不是 Capgo。如果易受攻击的逻辑、SQL、RPC、RLS 策略、边缘函数或配置由 Capgo 创建或选择，我们可以在我们的项目中修复它，即使 Supabase 提供了端点。对于 Supabase 行为本身的发现，请包含可复现的案例和在项目配置如我们的项目中预防它的确切 Supabase 设置或配置更改。

示例

这里无效

  • 仅 Supabase 可以修复的 Supabase 平台错误、停机或行为
  • 无法复现的发现
  • 指责 Capgo 对 Supabase 行为负责而没有显示 Capgo 控制的修复或确切的 Supabase 设置/配置更改的声明

有效

  • 我们可以在项目设置中修复的 Capgo 控制的 Supabase 错误配置（带有步骤）
  • Capgo 所有 SQL、RPC、RLS、函数或集成问题，导致不安全的 Supabase 使用
  • A Capgo 的 Supabase 项目、架构或策略中存在可复现的问题，即使它是通过 Supabase 端点暴露的

已知 Supabase Auth 限制（已报告）

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.

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

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