Bug Bounty Programs

@pipeworx/bug-bounty-programs

公开漏洞赏金计划目录数据——计划名称、赏金范围、状态和范围内资产——来自 Bugcrowd、YesWeHack 和 HackerOne 自有的公开目录。不包含漏洞内容、研究人员档案或用户名。

属于 Pipeworx 的一部分——一个将 AI Agent 接入 1875+ 个实时数据源的 MCP 网关。这是一个独立的非官方集成，与上游提供方无关联、未获其认可，也非由其发布。

工具

• bounty_programs_search(platform?, query?, min_bounty?, launched_since?, has_wildcard?, limit?) — 按名称、最低赏金（美元）、启动日期（仅 HackerOne——见下文）以及范围是否包含 *.example.com 这类通配符资产，在一个或全部三个平台中搜索（在 yeswehack/hackerone 上实时检查；bugcrowd 会返回带有说明性 note 的 count: 0，而不是报错，因为其范围信息受登录墙保护，并非功能损坏）。
• bounty_program(platform, handle) — 按平台和用户名查询单个计划。YesWeHack 会返回完整的严重性 x 资产价值奖励表和实际范围；HackerOne 会返回实际范围，但没有数值奖励表（公开架构的任何位置都未公开此信息）；Bugcrowd 两者都不返回，并说明原因。
• bounty_new_programs(days) — 根据实际启动日期，查找过去 N 天内启动的计划。仅适用于 HackerOne；关于为何 Bugcrowd/YesWeHack 无法如实提供此数据，见下文“这里不包含什么”。

身份验证

无需密钥。以下每个端点均可在没有账户、令牌或 API 密钥的情况下响应。

数据源

• https://bugcrowd.com/engagements.json — 分页（?page=N，每页 24 条，paginationMeta.totalCount）的公开项目列表：名称、URL、奖励摘要、行业、访问状态。不包含范围／目标数据——Bugcrowd 的范围“显示”操作会跳转到研究人员登录区域 /h/engagements/{handle}/reveal.json。这是真正的登录墙，并非漏洞；bounty_program/has_wildcard 会说明这一点，而不是悄然返回空结果。
• https://api.yeswehack.com/programs（列表，?page=N）和 https://api.yeswehack.com/programs/{slug}（详情）——三者中信息最丰富的接口。详情会返回 scopes[]（真实资产标识符，部分带通配符）、out_of_scope 和 reward_grid_default/low/medium/high/critical/very_low——真实的“严重程度 × 资产价值等级”奖励表（只有项目实际使用的等级才有非空值；其余全部为 null，而不是零）。该接口没有任何启动日期字段——只有 last_update_at（最后变更时间），此处绝不会将其显示为 launched_at，以免让人误以为这是启动时间。
• https://hackerone.com/graphql（POST，未认证）——query { teams } / query { team(handle) }。已禁用内省，因此以下所有字段名都是通过尝试猜测并读取 GraphQL 返回的“您是不是想要 X？”错误发现的，而非来自已发布的架构文档：
  • teams(first/last, after/before)：handle name offers_bounties submission_state launched_at——launched_at 是真实且已验证的启动日期（已与 hackerone.com/security 中的平台首个项目日期 2013-11-06 核实）。last: N 会返回最近创建的 N 个团队，这正是 bounty_new_programs 向前遍历的方式。我们没有找到可用的 order_by 值（语法上接受 order_by: {field: ..., direction: DESC}，但我们尝试的所有 field 字段名都被拒绝），因此排序依赖顺序递增的内部 ID，而非显式按日期排序。
  • team(handle).structured_scopes_search(first)：一个联合类型（DocumentUnion）——使用 ... on StructuredScopeDocument { identifier asset_type eligible_for_bounty eligible_for_submission instruction }。identifier 是实际的范围资产（域名／URL），有时带通配符（已在线确认 *.rubyonrails.org、*.cloudflarepartners.com）。我们找到的所有位置都没有数值奖励金额——team.bounty_table 作为一种类型确实存在，但我们尝试的所有可能字段名（rewards、severities、low_bounty/high_bounty、min/max、field_names 等）都返回“不存在”。如果 HackerOne 将来公布真实字段名，bountyProgram() 中的 hackerone 分支就是唯一需要添加它们的位置。

此处未包含：Immunefi

有意不将 Immunefi 纳入此工具包的平台。/explore 和所有 /bug-bounty/{slug}/ 页面均公开访问——无需登录——但实际的范围 列表和按严重程度划分的奖励表，是从一个无法通过稳定、文档完善的 JSON 端点访问的内部 API 在客户端加载的。已于 2026-10-08 检查并排除以下方式：

• 服务端渲染的 HTML：完整页面（/bug-bounty/ens/ 约 210KB，状态码 200）中 不包含任何奖励表字段，且恰好只有一个 0x... 合约地址——范围列表在客户端 水合后才会渲染。
• Next.js RSC flight 载荷（RSC: 1 请求头，是 Next 旧版 _next/data/*.json 的 app-router 对应版本）：结果相同，约 30KB 的响应中没有奖励或范围相关键。
• robots.txt / sitemap-dynamic.xml：公开且无需身份验证，可用于发现项目 slug （约 166 个 /bug-bounty/{slug}/），但站点地图只包含 lastmod（内容最后修改时间）， 不会包含上线日期。
• 每个项目唯一真正公开的静态信息，是 Immunefi 写入页面 SEO meta description 标签的 “奖励最高达 $X”一行——信息真实， 但仅有一个概括性数字，作为项目记录过于单薄，无法与 其他三个平台的结构化范围和奖励表并列提供。

如果 Immunefi 将来发布（或我们找到）此类稳定的 JSON 端点，就可以按 yeswehack 的相同结构，将其作为第四个 platform 值添加。

同样未包含：Intigriti

未检查——根据指定此工具包的任务要求，Intigriti 的公开目录需要研究人员账号或令牌 才能浏览。因此未进行抓取，避免绕过登录。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "bug-bounty-programs": {
      "url": "https://gateway.pipeworx.io/bug-bounty-programs/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/bug-bounty-programs/mcp 上的 tools/list 会返回上表中的工具， 以及 Pipeworx 共享的元工具——ask_pipeworx、 discover_tools、search_within、remember/recall，以及网关范围内的 其他工具。因此，你看到的工具数量会多于此表所列：目前，单个工具包端点会列出约 30 个共享工具，以及 该工具包自身的工具。连接的 initialize 响应会说明其确切范围，是当天情况的权威依据。

这是有意为之，并非意外复用。元工具让限定范围的连接也能回答此工具包未涵盖的问题——通过 ask_pipeworx 跨整个目录路由——无需你再添加第二个 MCP 服务。目前无法挂载不包含 这些元工具的工具包端点；如果额外的架构定义占用的上下文超过路由功能带来的价值， 不如只连接一次完整网关，而不是连接多个工具包端点。

或者，连接完整的 Pipeworx 网关，直接列出所有工具包的工具， 而不仅仅是此工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都连接到同一个网关和同一批 1875+ 数据源。 唯一的区别是哪些工具包的工具会被直接列出；从任一端点都可以通过 ask_pipeworx 访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/bounty_programs_search \
  -H 'Content-Type: application/json' \
  -d '{"platform":"yeswehack","min_bounty":1000,"limit":10}'

首次调用无需账号。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/bounty_programs_search。查找工具：使用 {"query":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

独立运行（无需网关账号）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账号，也无需 通过网关往返调用：

{
  "mcpServers": {
    "bug-bounty-programs": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-bug-bounty-programs"]
    }
  }
}

或者直接运行它，确认可以启动：

npx -y @pipeworx/mcp-bug-bounty-programs

它通过 stdin/stdout 使用 MCP，并针对仅限此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。 使用相同的源代码和工具，但不包含 ask_pipeworx 路由功能。

使用 ask_pipeworx

你也可以用通俗的英语提问，而不是直接调用工具——此功能既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Bug Bounty Programs data" })

网关会自动选择合适的工具并填写参数。

More

• Docs and guides
• pipeworx.io

License

MIT