【0day占位】告别Sink-Driven：基于“模块化驱动+动态Prompt”的Dokploy双RCE挖掘纪实

写在前面： 这是一篇“占位”性质的随笔。近期，我利用AI辅助在Dokploy中挖掘到了两个鉴权失效而导致的RCE（远程命令执行）漏洞。目前漏洞已经提交并在官方的积极处理与修复流程中。出于负责任的漏洞披露（Responsible Disclosure）原则，本文不会包含具体的PoC、数据流细节或触发条件。

但在等待补丁发布的这段时间里，我想先分享一下这次挖掘背后的方法论变迁。在AI时代，我们可以解决掉大部分重复劳动，例如找sink点，以及编写测试脚本，比0day更珍贵的，是寻找0day的思维范式。

传统的代码审计习惯于全局搜索 exec、system、eval 等危险函数，然后逆向去寻找 Source（可控输入点）。但在现在的业务代码中，这种做法有两个致命缺陷： 第一，噪音实在太大。业务代码中充满了各种被层层封装、看似危险实则根本无法触达的死代码，或者是内部极其安全的正常调用。 第二，低垂的果实早已没了。那种一眼就能看出输入直通 exec 的单步明显漏洞，早被各种SAST工具和无数白帽扫得一干二净。

所以，我认为在利用AI辅助挖掘时，也必须摒弃这种思路。 如果你直接扔给大模型一段代码并Prompt说：“寻找命令注入漏洞”，它大概率只是在做一个“高级版的Grep”，然后给你返回一堆充满了幻觉的误报。AI的算力被白白浪费在了无意义的噪音排查上。（想看到自己的token被嘎嘎跑完吗）

于是我觉可以尝试以功能来驱动（Feature-Driven/Modular-Driven）。

很多高危漏洞，从产品设计的Day 1起，就在其业务逻辑中埋下了伏笔。有些功能模块从设计思路上来说，就注定伴随着极高危的底层行为。

以这次的目标 Dokploy 为例。在动手看代码之前，我利用AI（笔者使用的是Codex引擎+GPT-5.4 ）对 Dokploy 的核心业务场景进行了解析，整理出了以下几个核心模块：

• Terminal （终端交互）
• Docker Exec （容器内部命令执行）
• File Mount （文件系统挂载）
• Patch （补丁应用）
• Schedule （计划任务调度）
• Traefik Config （网关配置下发）
• SSH / Server （远程服务器管理）

为什么要单独把这些模块拎出来？因为我的眼里，这些功能本质上离真正的灾难只有一层窗户纸的距离。它们天生就极度贴近：

• 命令执行 (Command Execution)
• 文件写入/覆盖 (Arbitrary File Write)
• 远端控制 (Remote Control)

确定了高危模块后，就要谈谈这次挖掘最核心的方法论：动态Prompt（Dynamic Prompting），这其实是为了解决目前AI辅助挖洞的一个致命痛点。

用过AI挖洞的师傅都知道：AI 对于“多漏洞组合”的利用逻辑是非常弱的。

大模型可能很擅长发现局部的逻辑缺陷，比如它能一眼看出某个API路由的中间件配置错了，导致了权限缺失（Auth Bypass）。但问题是，AI的思维往往到此为止。它找到了鉴权失效，却不知道这个鉴权失效能造成什么进一步的影响。它无法像顶尖黑客那样，在脑海中立刻将“A处的权限绕过”与“B处的危险功能”拼图般结合起来。

这时候，就需要引入 动态Prompt 注入新的上下文。

当我们（或者AI）发现了一处鉴权失效后，我们不是让AI继续漫无目的地看代码，而是立刻切换Prompt的上下文，告诉它： “现在，假设你是一个未经身份验证的攻击者，你已经突破了刚才发现的API鉴权校验。请在这个新的权限上下文中，去审视xxxx代码块

这种“模块化驱动 + 动态Prompt”的组合，本质上是在做人工引导的漏洞利用链（Exploit Chain）编排。AI负责局部的高维理解和细微Bug发现，人类负责掌控全局的攻击路径。

我知道读到这里，很多师傅会觉得“裤子都脱了你给我看这个”。

那具体的漏洞触发点在哪？是哪个路由的鉴权被绕过了？AI在推演组合链时，给出的最惊艳的一段提示是什么？

很遗憾，现在暂时没办法分享。

希望官方能够处理速度加快，以此在此blog上分享出来