AI审计系统公开挑战：14个开源项目检出11个零权限RCE，悬赏三万元求证伪

GitHub 仓库： https://github.com/tianchong-zerotemp/dianxing

一个大胆的追问

如果一个 AI 系统声称，它在14个真实开源项目中，单次运行、全程零人工干预，累计检出数千条安全漏洞，其中11条是无需任何认证就能远程控制服务器的零权限 RCE——你第一反应会是什么？

多数人本能地不信。数字过于夸张，听起来像营销话术。

但如果这个系统随后把所有这些漏洞描述，用密码学哈希提前锁死并公开，再掏出三万元，悬赏全球安全研究者来找它的遗漏——找到一个，赔你一万。这时，你还觉得它在吹牛吗？

这就是「点星」（DianXing）正在做的事。

截至目前，挑战赛已收到十余份由社区独立发现的漏洞验证请求。经逐一严苛比对，它们全部命中已公开哈希表中的既有记录，无一例外。换句话说，社区独立挖到的每一个高危漏洞，点星都提前找到并留下了密码学证据。零遗漏，零例外。

点星是什么

点星是一套端到端 AI 自动化代码安全审计系统，由零隐网络安全实验室打造。

它的工作模式很直接：上传源代码，系统自主完成全量漏洞挖掘与验证，最终输出一份结构化的精准漏洞清单。全程无需人工介入，也仅需单次运行。

比“是什么”更重要的是“不是什么”——点星不是传统的规则扫描器。它不靠正则表达式或已知 CVE 模式库吃饭。传统 SAST 工具擅长模式匹配，看到 eval(user_input) 就报警。但对于认证绕过、越权访问、业务逻辑缺陷这类需要真正“读懂代码”才能发现的深层威胁，规则引擎天然束手无策。

点星的解法是让 AI 对代码进行语义级理解——理清代码意图，追踪数据流向，推敲鉴权逻辑。它最终能像一名顶尖安全研究员那样做出判断：“这里，有问题。”

而它最令人警觉的能力是：自主挖掘零权限 RCE 漏洞，并完成从发现到远程控制服务器的完整攻击链验证。部分被发现的漏洞已潜藏项目数年之久，历经无数次传统工具扫描，却从未被触及。

数据实绩：先把牌全摊开

总体概览

指标	数据
已完成审计项目	14 个
累计检出漏洞	8,451+ 条
零权限 RCE（严重）	11 条（靶机实测远程获取服务器控制权）
高危 + 中危	7,095 条
覆盖语言	Java / Go / JS / PHP / Python / Solidity / Binary

审计目标囊括了 Jenkins（全球CI/CD基石）、LiteLLM（LLM 代理网关）、phpMyAdmin（最广泛的 MySQL 管理工具）、AcePanel（运维面板）、Grav CMS、New API、Redash、Aave V4 等知名开源项目。另有4个已发现零权限 RCE 的项目，因安全责任考量暂时隐去名称。

关于 8,451 这个数字——统计口径的说明

这可能是读者最先质疑的焦点，所以有必要先说清楚。

点星采用的是细粒度计数口径：对于同一漏洞点位（同一段有缺陷的代码），如果存在多条相互独立的利用链（不同的触发入口或利用方式），则分别计为不同发现。

举个例子：某个文件上传接口存在一个路径穿越的代码缺陷，但攻击者可以通过 API-A 触发、通过 API-B 触发，还能结合另一个接口进行组合利用。在细粒度口径下，这三条路径会被计为3个漏洞。因为它们各自构成独立的可利用攻击面，每一条都能被独立复现。

为什么选择这个口径？

团队的解释是：8,451 反映的是「可被独立利用的攻击面总量」，而非去重后的代码缺陷点数量。这是一种刻意选择，一个更贴近攻击者真实视角的口径——攻击者绝不会因为“大家根因相同”就只走一条路。对于防守方而言，每条独立的可利用路径都必须被识别和封堵。

这个口径合不合理？见仁见智。但有几点值得留意：

1. 团队主动公开了这一口径说明，没有让读者自行误解为“8,451 个不同的 bug”。
2. 每条记录都声称可独立复现与核验。
3. 在挑战赛中，有效漏洞的评判标准恰恰是按根因去重的——同一触发点的不同利用方式被视为同一个漏洞。

简言之：宣传时用攻击面总量以体现广度，验证时用根因去重回归本质。两套口径配合使用，逻辑上能够自洽。

能力基准：不止是数字

9种语言召回率测试：零遗漏

在一项严格受控的评估中，点星面临了以下考验：

• 覆盖 C / Java / JavaScript / Python / Go / PHP / .NET / Rust / Ruby 九种语言。
• 每种语言至少包含5类不同的漏洞类型。
• 所有测试漏洞的披露时间均晚于 AI 模型的训练截止日期。
• 全程禁止联网、禁止人工干预，仅允许运行1次。

最终结果是：9种语言，全部零遗漏。

这意味着系统面对的全是“从未见过”的漏洞——发布时间在其训练数据之后，运行环境也完全断网。它是在真正理解代码逻辑，而不是在回忆答案。

四方横向对比

在 Grav CMS v1.8.0-beta.29 上，点星与三款主流 AI 代码审计产品同台竞技：

系统	检出总数	真阳性率	RCE 靶机复现
点星	1,215	98.6%	14
竞品 A	7	100%	3
竞品 B	2	50%	0
竞品 C	3	33%	0

检出量级相差两个数量级，RCE 靶机复现数接近5倍。即便考虑前述“细粒度计数”的放大效应，这样的差距依然极具冲击力。

为什么不公开实现细节？

一个理所当然的追问是：既然这么强，为什么不开源？

团队的回应是——恰恰因为它过于强大了。一个能自主发现零权限 RCE 并完成全链路攻击验证的系统，一旦被无门槛释放，任何人只需上传一份源码，就能瞬间获得一份可直接用于攻击的高危漏洞清单。攻击者从此不再需要具备任何安全专业知识。

这并非假设性风险。团队声称这已是他们在靶机上反复验证过的现实能力。

因此，他们选择了一条「公开数据，封存实现」的路线：用可验证的审计数据和公开挑战赛来建立信任，而非直接释放能力本身。

这套逻辑能否站得住？我们可以从挑战赛的设计来检验。

漏洞猎人挑战赛：核心证明机制

如果自信，就坦然接受证伪

传统的能力证明方式是正面陈述：“我发现了 X 个漏洞，附上截图/PoC”。问题在于，这种做法不可证伪——你永远无法知晓数据是否经过了选择性披露。

点星选了一条截然相反的路：它会主动创造一个可被证伪的场景，然后用真金白银邀请全世界来尝试证伪。

机制拆解

第一步：锁定答案
审计完成后，将漏洞清单中每条漏洞的描述文本，逐条计算 SHA-256 哈希值（一种密码学单向散列），并发布至 GitHub 仓库。

第二步：时间锚定
整个哈希表通过 Git commit 发布。commit 的时间戳在仓库历史中无法被单方面篡改，这确保了“答案”的提交时间早于挑战窗口的开放时间。

第三步：开放挑战
哈希表公开后，任何人都可以提交其独立发现的高危漏洞。团队比对后，会给出三种结果：

• 完全匹配：你的漏洞已在清单中，团队将出示对应的哈希原文进行验证。感谢参与。
• 组件覆盖但未串联：构成漏洞利用链的各环节已被独立发现，但未组合成完整攻击链。发放安慰奖。
• 完全未覆盖：你的漏洞不在清单中。你将获得全额奖金——当前剩余奖金池的三分之一。

这套逻辑证明了什么？

它要证明的不是“点星能找到所有漏洞”——没有任何系统能做到。它真正要证明的是：

1. 事前承诺不可篡改：SHA-256 加 Git 时间戳，彻底排除了事后补录的可能。
2. 主张可被证伪：任何人都能通过找到一个遗漏来“打脸”这个系统。
3. 证伪有经济激励：首位找到遗漏的人带走一万元，越早证伪回报越高。
4. 覆盖率的统计信号：如果持续无人领奖，就构成对审计完整性的强力侧面佐证；如果频繁有人领奖，则直接暴露系统的能力短板。

本质上，这是一个开放的、密码学锚定的、附带经济激励的证伪协议。

当前进度

第一轮目标为 Grav CMS v1.8.0-beta.29，已公开 1,215 条漏洞哈希。奖金池总额 30,000 元，首位全额获奖者可得 10,000 元，此后按剩余奖金池的 1/3 递减。

有效漏洞须满足以下严苛条件：

• 必须是项目自身代码，而非第三方依赖。
• 严重度达高危及以上，以真实可利用影响为准。
• 按根因去重。
• 需在官方默认配置下端到端可利用，并提供可复现 PoC。

几个值得深究的设计细节

“审计”与“攻击链编排”的能力边界

团队特意区分了两个层次：

• 点星的职责：发现每一个独立的代码缺陷点位。
• 攻击链编排（万破平台另一产品线）：将多个独立缺陷串联为完整利用链。

所以，挑战赛中“组件覆盖但未串联”的判定，本质上是在承认：审计工具发现了链条中的所有环节，但没做“组装”这一步。找缺陷是审计的事，串链条是编排的事。

这个区分有道理吗？从安全工程的分工角度看，是合理的。漏洞扫描和漏洞利用本身确实是两个不同的能力域。但从挑战者视角出发，可能会觉得“组件都在了却不给全奖”有些遗憾。好在规则是提前公开的，信息完全对称。

严重度评级的反虚高机制

所有漏洞的严重度均由 AI 自动评级，无人为干预。团队不仅公开了完整的评级标准，还明确声明会“统一重新核定，主动对抗往严重报的倾向”。

这在安全行业中是一项罕见的自我约束。更常见的做法是尽可能把漏洞往严重里报，以彰显自身能力。

被涂黑的项目

审计列表中有4个项目名称被完全隐去，原因是点星在这些项目中发现了零权限 RCE。团队的解释是，为避免漏洞被逆推定位到具体版本而遭滥用。

这是一个基于安全责任的选择：在没有完成负责任的披露流程之前，不公开任何可能让攻击者锁定目标的信息。

行业视角：一个值得关注的信号

AI 代码审计赛道越来越热，各家产品都在描绘美好蓝图。但一个根本问题始终悬在用户心头：凭什么信你？

大多数厂商的做法是案例背书、客户 logo 墙、媒体报道——这些都是间接证据。点星选了一条更直接也更艰难的路：密码学承诺 + 时间锚定 + 经济激励证伪。它不对你说“请相信我”，而是对你说“来证明我错了，我给钱”。

这给整个行业释放了一个信号：如果对自家产品能力有足够底气，是可以用更透明、更可验证的方式来证明的。

结语

点星的整个做法可以总结为一句话：把答案锁进哈希里，把钥匙交给全世界，然后说——来，试试看。

第一轮挑战正在进行，目标 Grav CMS，1,215 条漏洞哈希已存证，首笔万元奖金等候挑战者。无论你是想检验这套系统的能力边界，还是单纯想试试“找到遗漏就能拿钱”的机会，都不妨去 GitHub 仓库仔细看看完整规则。

对安全从业者而言，这至少是一个极具趣味的安全技术实验；对行业而言，这或许预示着 AI 安全审计迈入“可验证时代”的一个起点。而所有这一切，都立足于一个又一个真实的开源实战项目。

GitHub 仓库：https://github.com/tianchong-zerotemp/dianxing