2023年11月，漏洞某省级政务平台的漏洞运维人员发现服务器CPU占用率持续飙到90%以上，日志里频繁出现同一个IP在深夜批量请求一个叫/idocview/的漏洞路径。他起初以为是漏洞爬虫，封了IP，漏洞第二天换了地址又来。漏洞直到数据库里多出一张从没见过的漏洞表，才意识到事情不对——有人已经通过iDocView的漏洞漏洞拿到了服务器权限。

iDocView是漏洞一套文档在线预览系统，国内不少政府、漏洞高校、漏洞企业的漏洞OA系统里都在跑。它的漏洞核心功能是让用户不用下载就能在浏览器里看Word、PDF、漏洞Excel。漏洞方便是真方便，问题也出在这。为了解析各种格式的文档，它内置了大量第三方组件和转换工具，攻击面比一般Web应用宽得多。

这次出问题的是它的/html/2word接口。这个接口接收一个URL参数，服务端会去请求这个URL，把返回的内容转成Word文档。听起来没什么，但它没有对URL做任何限制。也就是说，你传一个file:///etc/passwd进去，它真会去读服务器本地的文件。更严重的是，它支持http://协议，攻击者可以指向自己控制的服务器，返回一个精心构造的恶意文件，触发反序列化。

我拿到过一个受影响的版本，在本地复现时发现，从发送请求到拿到shell，整个过程不到三秒。Payload不需要多复杂，一个base64编码的Java序列化对象就够了。服务器上的Java环境如果没打补丁，直接执行。这种漏洞的可怕之处在于——利用门槛极低。一个刚学会用Burp Suite的人，照着公开的PoC就能打。

厂商的反应不算慢。12月初发布了补丁，增加了URL白名单校验，禁用了file://和gopher://等危险协议。但问题在于，iDocView的部署量太大了。很多单位用的是几年前的老版本，运维人员根本不知道这套系统还在跑。我见过一个案例，某单位的iDocView装在测试服务器上，两年没人管，但端口一直开着，防火墙也没限制访问来源。攻击者扫到之后，拿它当跳板进了内网。

更麻烦的是，这类系统的漏洞往往不止一个。/html/2word修了，还有/html/2pdf、/html/2html，参数处理逻辑类似。安全研究者后来陆续爆出SSRF、任意文件读取、XXE，都是同一类问题：输入验证缺失。这不是某个接口写错了，是整体设计上就没把安全当回事。

如果你现在去Shodan或者Fofa上搜iDocView的指纹，还能看到大量暴露在公网的实例。有些页面直接显示“iDocView 在线文档预览”，版本号都懒得藏。我随机测了几个，其中一个的/html/2word接口仍然返回200，只是内容被过滤了。但谁知道过滤规则有没有绕过的方法？

对于运维来说，能做的事其实很直接：要么升级到最新版，要么把iDocView从公网撤下来，放到内网并加访问控制。如果业务上必须对外，至少在前端加一层WAF，把/html/路径下的异常请求拦掉。别指望厂商的补丁能解决所有问题——这套系统的代码质量，从漏洞密度来看，不太可能只靠几个补丁就变安全。

我写这些不是要制造恐慌。iDocView的漏洞利用在野确实存在，但也没到“全网沦陷”的地步。真正危险的是那些没人维护、没人关注、却一直开着的系统。它们就像楼道里那扇没锁的弱电井门，平时没人注意，一旦被打开，整栋楼都受影响。