Adobe Reader藏了7年API漏洞

全球超过6亿台设备安装的Adobe Reader，正被一个零点击漏洞撕开缺口。安全团队EXPMON上周捕获的攻击样本显示：用户双击打开PDF后，恶意代码在后台完成文件窃取、系统测绘、数据外传，全程无需任何弹窗或授权提示。

攻击链还原：从"可爱文件名"到系统沦陷

这份被上传至公共沙箱的恶意文档，文件名透着诡异的轻松感——"yummy_adobe_exploit_uwu.pdf"。攻击者显然深谙心理战术：用萌系命名降低用户警惕，同时用Base64编码把核心脚本塞进PDF的隐藏对象里。

传统杀毒引擎集体哑火。公开扫描平台的初始检出率低得可怜，恶意代码顺利混过静态特征检测。但EXPMON的行为分析系统捕捉到了异常：Adobe Reader的JavaScript引擎里，出现了高度可疑的API调用序列。

漏洞利用分为两个阶段。第一阶段是"踩点"：恶意代码调用util.readFileIntoStream()这个内部API，直接穿透沙箱防护，任意读取本地文件；紧接着通过RSS-addFeed()接口，把操作系统版本、语言设置、Reader版本号、PDF本地路径等元数据，神不知鬼不觉地传回攻击者服务器。

这些数据看似琐碎，实则是攻击者的"筛选器"。安全研究员justhaifei1分析，威胁团伙通过初始测绘判断目标价值——只有符合特定条件的机器，才会收到第二阶段的加密载荷。

第二阶段载荷：RCE与沙箱逃逸已验证可用

EXPMON的受控测试证实了最坏的情况。攻击者服务器返回的二次载荷经加密传输，专门规避网络层检测；本地解密后，可触发远程代码执行（RCE）和沙箱逃逸（SBX）。

这意味着什么？攻击链一旦跑完，攻击者能突破剩余的所有安全边界，获得机器的完全控制权。而这一切的起点，只是用户打开了一个PDF。

更棘手的是漏洞性质。util.readFileIntoStream()和RSS-addFeed()都是Adobe Reader内置的合法API，并非代码缺陷或内存损坏类漏洞。这种"功能滥用型"攻击面，传统补丁机制很难快速响应——Adobe不能简单禁用这些接口，因为正常业务流依赖它们。

零日状态：暂无补丁，防御靠"不打开"

截至发稿，Adobe尚未发布官方修复。justhaifei1确认该漏洞已通过负责任披露流程提交给Adobe安全团队，但补丁时间表未知。

企业安全团队的临时方案显得笨拙：禁用JavaScript执行、限制PDF来源、加强邮件网关过滤。但对普通用户而言，最有效的防御仍然是——别打开来路不明的PDF，哪怕文件名看起来人畜无害。

一个值得玩味的细节：攻击者选择的RSS-addFeed()接口，本是Adobe为"订阅PDF更新通知"设计的合规功能。把正经功能改造成数据外传通道，这种"借壳上市"的手法，比漏洞利用本身更难防御。

你的收件箱里，最近有没有收到过命名奇怪的PDF附件？