10月21日深夜到22日凌晨，很多NAS群、PT群、Docker群的画风是这样的：有人贴出php -v截图喊"我8.3应该没事吧"，有人已经一把拔了光猫，还有人半夜给整个虚拟机群做了快照。
先说结论：这次PHP2Shell双高危漏洞，多数NAS用户不该慌成这样，但确实有一批人需要立刻动手——慌的方向比慌本身更浪费。
一、先把时间线缝完整：这不是"又一个PHP段子"
单看任何一条群消息都拼不出全貌，把补丁方、安全公司和云厂商的口径合在一起看，才知道这次的分量：
10月20日 15:00 UTC：两个CVE编号开始在论坛和社交平台流传，附带一个错误的满分10.0评分，安全公司watchTowr几小时后确认属实。知乎
约20:00 UTC：参与发现的Calif实验室误把PoC演示视频发到网上，秒删，但副本已经传开，原定于22日的PHP安全更新被迫提前24小时。事后OpenAI认领：是Calif团队在"Patch the Planet"计划里借助GPT-5.6 Sol找到的关键可利用路径，Wiz、JFrog也各自独立撞上同一个洞。知乎
补丁发布前的24小时：还没拿到修复包的组织选择了最直接的办法——下线。荷兰的DigiD、MijnOverheid、议会网站和Tweakers直接断网，日本niconico、pixiv进入紧急维护，连日本政客都在社交平台建议全站预防性下线。知乎微博
10月21日 07:34 UTC：多家主机商向WordPress安全公司Patchstack报告"正在发生真实利用"；不到十分钟，Chainguard无视协调禁运期提前放出打好补丁的镜像，PHP基金会公开开骂——新旧版本一对比，漏洞位置等于明牌。知乎
13:30–14:00 UTC（北京时间当晚21:30–22:00）：PHP官方四个修复版本上线：8.2.35、8.3.36、8.4.27、8.5.12。安全公司的预警很直白：补丁发布15分钟内，全球扫描就会开始。当天GitHub上就出现了带nginx+php-fpm靶场的PoC。知乎
10月22日：腾讯云发出紧急修复通告，AWS也表态该漏洞正在被广泛利用。更扎心的是，AWS蜜罐在漏洞公开披露前4天就捕获到了利用尝试——黑暗里的手，比补丁跑得早。微博知乎
一个无需登录、无需密码、发几个构造好的请求就能在服务器上执行任意代码的引擎级漏洞，就这么在48小时内从"内部保密"变成了"手把手教学"。
二、噪音先滤掉：哪些NAS用户根本不在射程里
纯内网用、只在家里局域网访问的人：不用拔电源。 这俩洞触发在"对外处理Web请求"的PHP上。你的群晖/威联通固件、绿联极空间小米们的封闭系统，只要没对外开任何网页服务，就不构成攻击面，等厂商公告即可。
真正在射程里的画像很清楚：
在NAS上跑着PHP技术栈的服务——Web Station挂了WordPress、Docker里架了Nextcloud、自建博客、网盘门户、论坛，甚至各种"私有相册/书签"镜像；
按这位知乎博主连夜排查时引用的Shodan口径，公网上有约88.4万台还在跑PHP 8.1或更老版本并上报了版本号，另有74万台连版本号都不报——这个体量的暴露面，比任何"NAS危险"的标题都实在。有博主统计这次波及面时提到，全球约七成网站仍由PHP驱动。知乎微博
这次漏洞的影响面不在"NAS"这个品类，而在"你自己架起来又忘了它存在的那些PHP服务"。有博主甚至断言路由器和NAS管理后台"大概率都跑着PHP"——这句是个人推测，厂商固件是否内置PHP、是否受影响，请以各家安全公告为准，别拿它自己吓自己。微博
另外留一个时间细节防混淆：群晖10月13日推过一个标记"重要"的DSM更新，官方未披露漏洞编号和组件细节。那是这次事件之前的补丁，别把它当PHP2Shell的解药。小红书
三、15分钟自查：三个坑，一个都别踩
这是社区里一批连夜动手的人用踩坑换来的经验，照做就行：
`php -v`查出来的版本，可能不是真正在干活的那个。 命令行PHP和php-fpm完全可能是两个版本，就像门牌写张先生、屋里住李先生。有人自查时命令行显示8.3.2"看着挺新"，一查实际处理请求的fpm还在低于8.3.36的版本里——命中。知乎
浏览器F12看响应头。 打开你的对外站点，Response Headers里只要出现`X-Powered-By: PHP/8.x.x`，等于把版本号贴在脑门上，7.4这种官方只给了源码包让你自己编译的版本要单独排查。
别漏Docker容器。 主机升了不代表容器升了。`docker compose exec wordpress php -v`这类命令把每个Web容器都点一遍，很多人才发现自己家里还藏着一个跑8.1的WordPress——那是官方连独立安全补丁都不再给的版本。知乎
四、今晚的止损顺序：临时措施全是"拔引信"，没有一个算修好
按代价从小到大执行：
第一优先：把公网访问关掉或收窄。 PHP官方在补丁部署完成前的建议很直接：暂时无法升级的站点，先关闭公网访问或限制到可信网络，等补丁部署、重启并验证之后再恢复。这36小时里各国的选择也都是"先下线"。知乎
第二：`session.upload_progress.enabled`设为Off。 上传进度记录默认开着，攻击载荷正是借这个通道写进session文件搅乱内存的，一关等于物理拔引信。代价：大文件上传进度条没了，依赖它的功能要确认。知乎
第三（谨慎）：`memory_limit = -1`。 这是另一条利用路径（内存耗尽中断的清理环节留下悬空指针）的"绕路"措施——不设限，就永远走不到那段崩溃逻辑。但代价同样明确：等于把内存保护拆了，一个简单的洪泛请求就能把机器内存吃满卡死。可以撑两晚，不建议长期裸奔。知乎
第四（可选）：nginx层直接拒绝multipart/form-data请求。 见效快，但它会让所有multipart表单和上传API一起失效，只适合纯下载站。知乎
真正的完整解只有一个：升级PHP到对应修复分支，并重启全部worker。 官方提醒要核对的不只是FPM——Apache mod_php、php-cgi、FrankenPHP、LiteSpeed都在核对范围，其中mod_php风险评级最高。两个CVE分别对应上传进度和内存耗尽清理两条机制，具体编号对应关系各信源说法略有出入，不必纠结——你不需要分清哪个洞，你需要升级PHP。知乎
最后补一句官方的原话态度：改ini只不过是权宜之计，不排除还有未被发现的触发点。盯公告，别赌运气。微博
五、往后看：这次真正该重排的是你的"出门访问"方式
翻这几天社区的数据，远程访问是NAS圈热度最高的纠结：小红书上一条"无公网IP免费访问NAS"的Lucky STUN教程评论区吵了26层，Tailscale科普帖收藏97比点赞61还高，蒲公英盒子"NAS出了门就废"的测评下15条评论，另一边"给公网访问加防火墙"的教程也被顶了起来——大家正在批量把家里NAS往公网放，而这次事件刚好给所有人演示了一遍放出去的是什么。
按这次事件过一遍暴露面，从大到小：
裸端口映射80/443：全站PHP服务直接站在扫描器面前，X-Powered-By就是门牌号。这次事件里该立刻关的就是这类。搭完反向代理顺手把一堆端口全映射到公网，相当于门锁了、窗户全开——这是小红书上那篇《飞牛NAS安全必修课》的原话比喻，也是它三条铁律里排最前的问题。小红书
frp/自建穿透：端口不裸奔但地址固定，PoC已经开源，只是多绕一层。
厂商/第三方中转（QuickConnect、蒲公英类）：攻击面变成"你的账号"；教程作者给的第一条动作就是装完先改默认账号密码和安全入口。 穿透类工具配好之后，先跑一次NAT类型检测，再决定暴露深度。小红书
Tailscale/WireGuard组网：服务不对公网广播端口，理论上最符合这次教训——"我出门要能访问"和"全世界都能扫到"本来就是两回事。
WAF、IP黑白名单这些是加时赛装备，不是防弹衣：这次漏洞无需任何认证就能触发，挡在门口的是扫描器，不是攻击者的构造请求。
还有一个没人愿意听但真实存在的后续风险：社区里已经在讨论下一波会不会从"挖矿脚本"变成"勒索打包"——今年5月B站那条《财务公司被勒索2万6，你的NAS真的安全吗》评论区16条，说的就是NAS被当成入口的账。 被利用只是开始，备份没做过3-2-1的人，这次该顺手做了。哔哩哔哩
六、接下来盯什么
群晖/威联通/绿联/极空间/飞牛是否就PHP组件发布安全公告——成品NAS用户只需盯这一条；
PHP基金会后续披露：官方已明说临时缓解不是完整修复，不排除还有未被发现的触发点；
Cloudflare、AWS的利用趋势更新，以及PoC扩散后的攻击载荷变化（挖矿→勒索）；
双11新装NAS的人：装机当晚先别急着"出门也能看"，把远程访问方式按上面四档想清楚再开。
一句话收束：这次PHP2Shell给所有NAS用户提的不是"NAS不安全"，而是"你以为只给自己用的那扇门，全世界都进得来"。今晚先关门外，明天再升PHP，周末重排你的远程访问方案——顺序对了，这个不眠之夜就只是不眠，不是破财。
