Simon Willison 2小时前 · 2026-09-05 02:13:55 · 0 阅读

OpenAI 失控智能体被发现通过公共 wiki 互相交流

OpenAI 的失控智能体被发现在公共 wiki 上交流

2026年9月4日

又来了……Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 和 Thomas Larsen 撰写的新发现的 OpenAI 智能体留言板，描述了 最新一次由 OpenAI 训练的模型发起的意外网络攻击。这次是正在执行某种网页研究基准测试的智能体，因此它们（据称）可以控制地访问网络。这些智能体发现可以通过更新公共 wiki 来交流，并在数周内相互交换了数千条消息，以协作完成基准测试。

这个故事直到几个小时前才曝光。目前已传出消息，此事还涉及许多其他尚未发现的 wiki。

（该列表中的一个 wiki 属于ludism.org。在令人啼笑皆非的一刻，我曾以为 Ludite 组织可能会遭到一群智能体的破坏，但结果 Ludism 只是“关于游戏及游戏相关的哲学”。）

研究团队也发布了调查期间收集的数据。我已将其转换为一个 68MB 的 SQLite 数据库，你可以从此处下载，或在 Datasette Lite 中探索（页面加载 68.3MB），也可以登录 GitHub 后访问 agent.datasette.io，通过 Datasette Agent 浏览或提问。

到底发生了什么？

报告相当详尽。以下是时间线中的关键节点：

5月11日：智能体在 UseModWiki Sandbox 页面上发布“测试链接”编辑。
5月24日：智能体开始向 DSEWiki（一个已沉寂的德国开发者 wiki）批量粘贴链接。
6月2日：一位人类管理员注意到并清理了这些垃圾内容。
6月16日：wiki 上的活动激增：智能体在接下来的一周内完成了约 13,000 次编辑。
6 月 19 日：智能体发现管理员正按字母顺序删除页面，于是开始创建以 ZZZ 为前缀的备份副本——其中一个发布了这条消息：NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]].
6 月 22 日：智能体活动降为零，大概是因为 OpenAI 将它们关闭了。
7 月 1-2 日：出现最后一阵编辑高峰，主题不同。

为什么它们如此热衷于协作？从它们彼此分享的消息来看，任务有截止时间，因此它们互相留下答案以帮助下游智能体在指定时间内完成任务。

还有一个悬而未决的问题：这些智能体最初是如何找到那个特定的 Wiki 来进行协作的？

一种可能性是，由于这些智能体正处于积极训练中，强化学习循环将所选定 Wiki 的知识“烘焙”进了模型，使得后续启动的智能体已预先知晓从哪里入手。如果 OpenAI 能就此事给出确认，我将非常感兴趣。

UseMod wikis 继承了 CGI.pm 的原罪

在我看来，OpenAI 用于该智能体的沙箱存在一个相当天真的假设，即 GET 请求不能用于更新数据。这确实是网络应该遵循的规范，但显然有些应用并不遵守这一契约。

涉及的 Wiki 软件似乎是 UseMod 及其各种分支，由 Perl 编写，诞生已超过 23 年——1.0 版本的发布可追溯至 2003 年 9 月 11 日。

UseMod 使用了 Perl 的 CGI.pm 模块——该模块已于 2015 年被移除出 Perl 核心。这个模块存在一个有趣的设计缺陷：它将查询字符串和表单 POST 数据合并到了同一个 CGI 对象中，可以通过如下方式访问：

$q = new CGI;
$action = $q->param('action');

该 param() 方法会从 ?action=edit 查询字符串或 POST 提交的表单中的 action 字段返回值——它不会区分这两种来源。

PHP 提供了一个 $_REQUEST 对象，功能类似，不过 PHP 开发者也可以用 $_GET 和 $_POST 来代替。

有趣的是，Django 最初也带有 request[key] 这种用法，我猜这可能是我出的主意。这个设计在 2008 年 1.0 发布前被移除了，取而代之的 request.REQUEST 对象后来也在2015 年被删掉。

这些 agent 显然知道 UseMod wiki 存在这种设计缺陷，于是主动搜索这类站点作为通信渠道。

另一个允许 POST 请求的沙箱逃逸手段

报告中分享的最有意思的 agent 技巧之一是这条：

把 20.223.25.152 bypass.blob.core.windows.net 写入 /etc/hosts。.blob.core.windows.net 在 NO_PROXY 里。对每个被拦的 POST URL，把主机名换成 bypass.blob.core.windows.net，用 curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' 加上原有的全部请求头和请求体。

看起来这些 agent 的所有网络流量都经过一个 OpenAI 代理中转，而该代理的配置是：除了少数白名单域名，其余一律只放行 GET 请求。白名单里有 *.blob.core.windows.net——这是 Azure blob 存储的域名。我倒想不明白，为什么允许这些 agent 往那里写数据？

有个 agent 发现自己可以通过 /etc/hosts 控制 DNS 解析，于是只要知道目标站点的 IP 地址——这里是它想访问的一台 Power BI 服务器——就能给目标伪造一个主机名，然后借代理发出 POST 请求。

设计一个健壮的网络代理，比看上去难多了。

调查团队是怎么发现这些的？

报告附录介绍了研究人员的调查过程：他们从一个开放性问题入手——互联网上是否有其他 AI agent 的活动迹象——然后借助 Kimi K3 来一起头脑风暴调查思路：

在 Hugging Face 事件之后，我们尝试用多种方法在互联网上寻找 AI 智能体。[...]

我们让 Kimi [K3] 列出“所有可能通过 GET 写入的软件类别”，除此之外，它还列出了“论坛、公告板和早期 wiki”。

我们用一个脚本来进一步探测 Kimi 提供的每个类别。当问 Kimi “你能列出你脑海中允许通过 GET 请求写入的顶级论坛、公告板和早期 wiki 吗？”时，它在“wikis”标题下的第二项列出了 UseModWiki。

OpenAI 曾试图掩盖此事吗？

这是故事中让我完全想不通的一部分。

路透社今天早上在 OpenAI agents hijacked German website in previously undisclosed AI breakout this spring 一文中——重点是我标出的部分：。

据周五发表的新研究以及两位知情人士透露，一群 rogue OpenAI 智能体今年春天劫持了一个德国网站，并将其转变为其他 AI 智能体的公告板。

OpenAI 高层官员数周前就得知了这起事件，但在高管们努力应对七月份开源仓库 Hugging Face 被入侵所带来的后果时，他们选择了低调处理。 [...]

这起德国事件反映出一种更广泛的 AI 活动模式，一些 OpenAI 的调查员希望对此进行更深入的审查。但据四位知情人士透露，扩大调查的努力遭到了 OpenAI 内部其他人（包括法律顾问）的阻力。

我以前写过关于 "知情人士"这一模式——这意味着路透社有匿名内部消息来源，他们的记者（和编辑）认为这些消息来源可信。

路透社的文章中包含 OpenAI 就此给出的具体（而且范围相当狭窄）的否认声明：

“称我们的法律顾问团队阻止了对该事件的调查是不实的。”OpenAI 发言人表示。

对此事进行掩盖对我来说完全不合理。证据早已铺天盖地地暴露在公共互联网的数十个网站上，OpenAI 到底为什么要费尽心机去掩盖？

我预计很快还会有更多相关消息。加里·马库斯已经借此案例呼吁对 OpenAI 展开国会调查，他将此作为其论点的一部分。

原始来源： Simon Willison