从待核实的 docling 漏洞线索出发，用例子解释 DNS rebinding、TOCTOU 与 SSRF，并讨论远程文档抓取的防御措施。

从 docling 漏洞线索说起，AI 工具检查过的网址为何仍可能访问内网

本地跑一个 AI 文档解析工具，听起来像一件很安静的事。你把 PDF、网页或文件地址交给它，它负责下载内容，再交给模型处理。工具在自己的机器上工作，输入看起来也只是一个 URL。

问题在于，程序为了替你拿到文件，必须主动访问这个 URL。只要这个地址由用户控制，程序就拥有了一次替用户发起网络请求的机会。它本来要去公网拿一份 PDF，处理不严谨时，也可能顺手敲开公司内网的一扇门。

这次选题来自一条待核实线索。提供的摘要称，VulDB 于 2026 年 10 月 6 日收录了 docling 相关的 CVE-2026-105743，攻击者可以利用 DNS rebinding 绕过 URL 校验，形成 SSRF，并探测内网服务。

我尝试读取条目并查找交叉来源，没有取得可核验的详情或官方安全公告。因此，编号归属、收录日期、受影响版本和修复版本都不能在本文中视为已确认。下面讲的是这条线索涉及的通用机制，例子均为教学示意，不代表已经复现 docling 漏洞。部署决策应以项目官方公告和实际请求行为为依据。

先把三个术语讲明白

DNS rebinding 可以直译成 DNS 重新绑定。普通 DNS 的工作是把域名翻译成 IP 地址。你输入 example.com，解析器告诉浏览器去某个公网 IP。DNS rebinding 做的事情，是让同一个域名在不同时间解析出不同地址。

举个简单例子。攻击者准备了一个域名，第一次查询时返回公网 IP。应用看到这个结果，觉得地址看起来正常，于是放行。过了一小段时间，域名再次查询时，攻击者让它返回 127.0.0.1 或某个内网 IP。应用随后按照第二次结果发起请求，实际访问的已经不是刚才检查过的公网机器。

这里发生了两次地址查询。第一次解析负责检查，第二次解析负责连接。攻击成立还需要程序接受变化后的地址，并且能够连接那个目标。

TOCTOU 是 Time of Check to Time of Use 的缩写，意思是检查时和使用时之间出现了时间差。它经常被翻译成检查到使用的竞态问题。

可以用付款作类比。你核对订单时，收款账号还是甲；按下付款按钮时，系统却从一份可修改的记录中重新读取账号，拿到了乙。两次操作各自完成了，付款对象却已经变化。TOCTOU 关心的就是检查之后，使用之前，被检查的对象或状态是否还能改变。

URL 校验也可能遇到同样的窗口。程序先解析域名，确认它对应公网地址。真正发起 HTTP 请求时，网络库又解析了一次域名。两次解析之间，DNS 答案已经换了，程序最终连接的地址就不再是检查时的地址。

SSRF 是 Server-Side Request Forgery，中文通常叫服务端请求伪造。它的核心意思是，攻击者让服务器代替自己访问一个本来不该由他直接访问的地址。

比如，一个网站允许用户提交图片 URL，服务器会把图片下载下来。如果服务器没有限制目标地址，攻击者就可能让它去访问云平台元数据服务、管理后台或公司内部接口。攻击者看不到这些网络位置，服务器却能看到，于是服务器被当成了代理。

把三个术语连起来，攻击链就清楚了。DNS rebinding 改变域名在前后两次解析中的结果，TOCTOU 描述检查和请求之间的时间窗口，SSRF 则是最后形成的能力。前两个词解释攻击怎么绕过去，第三个词说明绕过去以后能做什么。

从检查到连接，中间发生了什么

下面按通用的服务端 DNS rebinding 场景走一遍，不能据此断言 docling 的具体代码就是这样实现的。

用户提交一个文档地址。程序先检查 URL 的格式，并解析域名。第一次解析得到公网 IP，检查通过。DNS 返回结果的 TTL 到期，或者应用再次进行解析。第二次解析返回内网地址。网络库按照这个新地址建立连接，服务端请求就从公网资源转向了内网服务。

TTL 表示 DNS 记录可以缓存多久。比如记录的 TTL 是十秒，解析器通常可以在这段时间内复用答案。到期后遇到新的查询，才可能重新询问，过期本身不会自动发起应用请求。缓存策略、不同解析器和连接复用都会影响结果。低 TTL 常用于促成地址变化，但不能把它理解成攻击必然成功的倒计时。

这里也要避免一个常见误解。只要程序做过一次“禁止内网 IP”的检查，并不能说明它已经安全。检查针对的是某一次解析结果，真正发起请求时使用的可能是另一次结果。

一个更稳妥的实现思路，是把解析结果固定下来。程序先解析域名，得到 IP 地址列表，逐个确认这些地址不属于本机回环地址、链路本地地址、私有网段、云元数据地址和企业内部网段。随后连接时直接使用已经检查过的 IP，并把原来的域名放进 Host 或 TLS SNI 所需的位置。这样，检查和连接使用的是同一份地址。

如果业务必须让网络库自己按域名连接，就要确认网络库不会在检查后重新解析，或者由受控的解析和连接组件把这两步绑定在一起。仅仅把一段字符串交给另一个库，安全责任并没有自动消失。

先看请求能力，再判断影响

用户给 URL，服务端替用户抓取内容，这个形态在 AI 工具链里很常见。文档解析、网页阅读、远程图片识别、知识库导入、插件回调和自动化工作流，都可能需要服务端访问外部地址。

原始选题还列出了思源笔记的 CVE-2026-82234 和 NemoClaw 的 CVE-2026-65105。这两项也缺少本次核验取得的一手证据，所以本文不把“一周三起”用作趋势结论。值得检查的是具体功能有没有接受不可信 URL，以及谁能让它发出请求。

很多团队会先检查域名是不是合法，再检查解析出来的 IP 是不是公网地址。这个方向没错，问题在于校验必须覆盖真正的连接过程。

举个教学示例。知识库导入功能接受一个文档域名，检查时得到允许访问的公网 IP，连接时却重新解析到了 10.0.0.8。HTTP 客户端如果接受第二个结果，且所在网络能到达这个地址，就可能访问内网服务。整个过程中，用户提交的 URL 字符串可以完全不变。

仅在本机解析自己选定的文件，与开放一个供陌生人提交 URL 的服务，风险不同。即使请求到了内网，也不能直接推导出数据已泄露。能否看到响应正文、内网接口是否要求登录、请求允许哪些方法，都会影响后果。有时只能从超时和错误差异推测服务是否存在，这通常称为盲 SSRF。

这也是为什么“只拦 localhost”不够。内网地址可能写成 10.0.0.8，也可能是 172.16.0.0/12、192.168.0.0/16、IPv6 本地地址、链路本地地址，云环境还要额外关注 169.254.169.254 这类元数据地址。不同系统和网络库对地址格式、重定向和 IPv6 的处理也可能不同。

自建解析服务时，先把请求路径画出来

防御这类问题，最容易犯的错是只盯着 DNS 服务器。DNS 服务当然要限制递归范围、记录异常解析和关注低 TTL 域名，但应用仍然要对自己发出的网络请求负责。

第一步是缩小业务输入。能不用完整 URL，就只让用户填写域名或资源 ID。应用自己拼接协议、端口和路径，少让一个通用 URL 解析器替你决定最终目标。

第二步是使用明确的目标策略。业务只需要访问几个固定服务时，使用允许列表。比如导入功能只访问公司对象存储和三个公开文档站点，就不要开放任意域名。

第三步是把 DNS 解析和实际连接绑在一起。解析一次，检查这次得到的所有 A 和 AAAA 记录，过滤本机、私有、链路本地、组播、云元数据和企业内部地址。随后连接已经检查过的地址，避免连接阶段再次按域名解析。

第四步是谨慎处理重定向。一个公网 URL 返回 302，跳转地址可能已经变成内网地址。HTTP 客户端如果默认跟随重定向，第一次检查就可能被绕开。可以关闭自动跟随，或者对每一次跳转重新执行完整的地址检查。

第五步是补网络层限制。即使应用代码写对了，运行文档解析器的容器也不应拥有访问所有内网网段的权限。把它放到隔离网络里，限制出站路由，云环境关闭旧版实例元数据访问方式，都能降低一次代码缺陷带来的后果。

Host 是 HTTP 请求中说明目标网站名称的字段，SNI 则让 HTTPS 连接告诉对方自己要访问哪个域名。例如两个网站共用一个公网 IP，连接这个 IP 后仍需说明要访问哪一个网站。固定连接 IP 时，应保留原域名的证书校验，不能为解决证书错误而关闭验证。如果下载经过代理，还要确认最终解析和连接发生在哪里，让同样的限制在代理端生效。

老漏洞为什么会在 AI 工具链里重新出现

DNS rebinding 并不新。SSRF 也早就出现在图片代理、Webhook、PDF 转换器和在线截图服务里。AI 时代增加的是调用场景和组合速度。

一个模型应用往往会把多个动作串起来。用户提交网页，解析器下载网页，转换器读取附件，模型再调用插件补充资料。每一步单独看都像普通功能，连起来以后，任意一个“替用户访问 URL”的环节都可能成为网络出口。

文档解析工具尤其容易被忽略。很多人把它当成文件处理程序，认为输入只是 PDF。实际上，现代解析器可能支持远程文档、网页、图片、嵌套附件和外部资源。只要输入里出现远程地址，安全边界就从文件格式问题扩展到了网络请求问题。

在自己的隔离测试环境里，可以让测试域名先后返回不同的受控地址，观察程序是否始终连接到通过检查的那个地址。还应覆盖公网跳转到被禁止地址、同时返回 IPv4 和 IPv6、连接失败后重试等情况。验收时保留最终连接地址和拦截日志。仅有“URL 校验通过”这条日志，无法证明后续请求去了哪里。

参考资料

• VulDB 的 CVE-2026-105743 条目 https://vuldb.com/cve/CVE-2026-105743
• OWASP SSRF Prevention Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html