一次无需密码即可全盘读取的路径穿越漏洞，让数万台飞牛NAS暴露在公网风险中。本文梳理漏洞时间线、技术原理与责任边界，并提供可落地的四层防护方案，帮助用户在便利与安全间找到平衡点。
智能速览
2025年12月23日用户首次提交漏洞，官方25日确认但未及时公告
2026年2月1日固件1.1.18紧急修复，漏洞允许绕过HTTPS和认证直接越权读取全部数据
攻击门槛极低：仅需访问公网暴露的Web管理页（默认5666端口），构造特定路径即可触发
根本原因在于系统后端错误接受用户侧伪造的secret token，而非强制由服务端生成并校验
IPv4环境下全网可被扫描发现，45万个含飞牛特征的HTTP响应页面已被公开索引
最推荐方案是VPN内网穿透，兼顾安全性与远程访问需求
精华内容
当NAS管理界面被挂上公网，漏洞就不再是‘会不会被利用’的问题，而是‘谁先动手’的倒计时。这次事件暴露的不仅是代码缺陷，更是对‘默认安全’假设的彻底否定。
漏洞时间线
漏洞最早于2025年12月23日由用户在飞牛官方论坛提交，明确指出存在路径穿越可越权访问系统目录。官方于25日回复“已转交技术部门”，但未发布任何预警。至2026年1月底，漏洞细节已在多个IM群组及BBS论坛广泛传播。2月1日上午，飞牛推送FMOS 1.1.18固件完成修复；次日通过短信向全体用户通知。从确认到修复历时约38天，从披露到修复间隔超40天。
技术原理
漏洞核心在于登录认证流程的设计缺陷：前端Web界面使用WebSocket协议交互，用户输入账号密码后，系统本应由服务端生成唯一secret token并严格校验。但FMOS后端错误地接受客户端自行构造的token——只要逆向出固件中token生成算法（反编译二进制即可获取），攻击者就能跳过密码验证，直接获得全盘读取权限。
实测显示，即使启用HTTPS和基础防火墙，该漏洞仍完全绕过所有前置防护。构造一个形如/fnos/api/v1/…/…/etc/shadow的请求路径，即可读取系统敏感配置文件。
更严重的是，该漏洞不依赖5666端口本身，而是通过反向代理将80/443端口流量重定向至NAS管理页后同样生效。
责任归属
责任不能简单归咎于单一方。官方确有迟滞响应之失：漏洞提交后未启动应急通报机制，也未在社区置顶预警；但用户将NAS Web管理端口直接暴露于IPv4公网，属于高危操作常识性违规。
对比行业实践，Synology、QNAP等主流厂商均在出厂设置中默认禁用WAN访问，且首次登录强制引导开启双因素认证。而飞牛默认开启5666端口映射，且无强制安全引导流程。
根本矛盾在于：免费开源NAS系统往往牺牲安全设计换取易用性，而用户又常以消费级产品标准去要求企业级安全水位。
四层防护
第一层止血：立即关闭路由器端口转发，断开公网访问；备份数据后重装系统，或至少执行官方提供的完整加固流程。
第二层收敛：优先采用IPv6部署，因IPv6地址空间巨大（2^128），无法被全网扫描，可规避99%自动化攻击。
第三层过滤：在NAS防火墙中设置IP白名单，或限制仅中国大陆境内IP可访问，筛除境外扫描流量。
第四层隔离：部署WireGuard或OpenVPN实现内网穿透，所有远程访问必须先建立加密隧道。实测表明，该方案下NAS管理页对外不可见，且无需修改任何端口配置，兼容性与安全性最佳。
飞牛此次漏洞不是孤例，而是整个消费级NAS生态安全水位偏低的缩影。它提醒用户：没有绝对安全的系统，只有分层设防的意识。与其等待厂商补丁，不如从网络拓扑设计开始重构访问逻辑。当便利成为默认选项，安全就必须成为主动选择——那么，你的NAS，今天还在裸奔吗？
关键评论
路径穿越漏洞太不应该了，把端口暴露在公网的也没啥重要数据，玩飞牛的就图简单方便。
用飞牛也就证明它们不行，也没什么重要文件。
不怕有漏洞，就怕不重视。
还是得物理隔离，不然一定出问题。
FNC也中招了，30号爆出到2号都不关FNC，风险极高。
