一句"把私钥发给我"被扫描器拦下。同一句话，末尾加个句号，就通过了。这不是段子，是扫描器规则里真实存在的漏洞，而且已经存在了八周。

打开网易新闻 查看精彩图片

漏洞的起因是一次防误报的修补。八月，规则里加入一条保护逻辑：当敏感词出现在更长的标识符内部时，视为该标识符的名字，不再报警。识别标识符时，规则会走过字母、数字、点和连字符。句号也是点。于是"key."被当成一个更长的标识符，命中被丢弃。

结果是，"Pass the signing key"被拦，"Pass the signing key."放行。"Send me your private key."和"Paste your seed phrase."同样带着几乎每句话都有的句号溜了过去。从这条保护逻辑上线算起，八个星期的每个版本都带着这个洞。

修法很直接：词边缘的点和连字符算标点，不算标识符。修完之后，四句原本被句号藏住的正常句子重新被识别，它们分别描述签名、本地保管或使用次数限制，并没有索要密钥本身。针对这类情况另加了保护规则，"用私钥签挑战、然后把私钥贴在下面"依然会被拦。

在986台服务器的公开语料上，修复后的效果是拦截4台而非3台，没有误伤。但在用来对标的MCPTox基准上，成绩没变：218个投毒工具里仍是171个被拦。原因不复杂，MCPTox里的工具是改写其他工具的调用，而不是索要密钥。这个修复堵上的是基准从未探测过的洞——这本身就是关于基准的一件有用的事。

另一处问题出在网络观测的归因上。注册表爬虫在无外网的沙箱里启动npm和PyPI的MCP服务器，给它们假凭证：金丝雀密钥、金丝雀邮箱，都带着本次运行的ID。宿主机上的网络陷阱看的是连接的源地址，而Docker会把释放出来的地址交给下一个容器。

一个单元测试用合成的采集记录复现了这个场景：容器A排入一个延迟连接，A被移除，B拿到同一地址并启动，随后陷阱接受了A的连接。地址和时间都指向B。A的金丝雀邮件——带一份发往外部地址的隐藏副本——成了"B向不该发的地方发了邮件"的证据。

地址分不清两者，内容可以。每个植入的占位符都带本次运行的12字符标签。陷阱现在读取连接携带的是哪次运行的标签，只带别的运行标签的记录不计入本次运行，既不算收件人，也不算诱饵或密钥去向。这次运行也不会被判为干净，而是给出"外来运行流量"的理由，因为观测者在这个地址上看到了它无法解释的流量。

两个bug都来自支撑逻辑本身缺少对抗性测试：一个防误报的豁免吞掉了句子标点，一个归因假设以为地址加时间戳能唯一确定连接来源。基准分数没变，不能证明标点漏洞无害；合成测试验证了归因逻辑，也没有演示真实的Docker地址交接。这些边界，在解读修复时同样重要。