内容摘要：去年十月，一个叫"fanf"的漏洞编号在安全圈里炸了锅。不是因为它影响面有多广，而是因为发现它的人——一个ID叫"夜风"的独立研究者——在提交报告后等了整整四十七天，厂商才回了一封邮件，内容只有一句话

去年十月，安全一个叫"fanf"的漏洞漏洞编号在安全圈里炸了锅。不是安全因为它影响面有多广，而是漏洞因为发现它的人——一个ID叫"夜风"的独立研究者——在提交报告后等了整整四十七天，厂商才回了一封邮件，安全内容只有一句话："我们正在评估。漏洞"四十七天，安全够攻击者把利用代码写三遍，漏洞再顺手卖两轮。安全

fanf这个漏洞本身不复杂。漏洞某款企业级文件同步工具，安全在处理特定构造的漏洞路径时，会把用户可控的安全字符串直接拼进系统调用。没有过滤，漏洞没有转义，安全连最基本的路径规范化都省了。夜风给我看他的PoC时，我盯着那段不到二十行的Python脚本愣了几秒——它能在目标机器上以root权限写入任意文件。就这么简单，简单到让人怀疑厂商的代码审计是不是用骰子做的。

但真正有意思的不是漏洞本身，是它暴露的那条链条。夜风先走的是厂商的漏洞披露页面，填了表单，附了PoC视频。三天后收到自动回复，说"已收到，请耐心等待"。第七天他补了一封邮件，问有没有受理编号。没回。第十四天，他在推特上发了条含糊的推文，说"某同步工具有个洞，等厂商修"。厂商的社区经理看到了，私信他"请通过正规渠道反馈"。第二十一天，他通过CVE编号机构申请了CVE，fanf这个编号才正式落地。第四十七天，厂商终于确认漏洞存在，但补丁拖到第六十三天才发。

这中间有个细节值得琢磨。夜风说，他在第三十天的时候，把漏洞细节发给了一个做渗透测试的朋友，朋友转手就报给了另一家安全公司。那家公司当天就联系了厂商的竞争对手，问"你们想不想知道友商产品的一个高危洞"。商业情报的流转速度，比漏洞修复流程快了不止一个数量级。

我后来跟几个做漏洞挖掘的人聊过，他们说fanf这种事太常见了。厂商的安全响应团队往往只有两三个人，要处理所有产品的漏洞报告，还要跟法务、公关、开发扯皮。一个路径遍历漏洞，开发觉得"用户自己构造的路径，怪谁"，法务觉得"披露了会影响股价"，公关觉得"等补丁好了再发公告"。三方一扯，一个月就过去了。攻击者那边呢？一个脚本小子花三天就能把PoC改成武器化的利用工具，挂到暗网上卖五百美元。

更让人不舒服的是fanf的后续。补丁发布后，厂商的公告里只写了"修复了一个安全缺陷"，没提CVE编号，没提致谢，连漏洞类型都懒得说。夜风的名字自然也没出现。他倒是不太在意，说"反正CVE编号是我的，跑不掉"。但另一个研究者跟我抱怨过，他去年报了三个洞，两个被厂商压成了"功能改进"，一个直接回复"这不是安全问题"。那个洞能让攻击者绕过认证，厂商说"用户应该自己配置防火墙"。

安全漏洞这东西，从来不只是技术问题。fanf的代码修复可能只用了二十分钟，但让它从发现到修复走完流程，花了六十三天。这六十三天里，厂商在评估，攻击者在利用，研究者在等待，而那个路径拼接的代码，一直安安静静地躺在生产环境里，等着下一个不怀好意的人来敲它的门。

夜风后来把fanf的完整时间线写成了博客，末尾加了一句："下次再遇到这种事，我可能直接发推特。"厂商的社区经理点了赞。没人知道这是不是真心。