今天不少站长一早就来问：PHP 又出漏洞了，我这站要不要动？先说结论——据公开报道，这次是远程代码执行（RCE）漏洞，影响的是非默认配置的系统，补丁还没出，PHP 安全团队只放了缓解措施。默认配置的 LNMP 先别慌；但凡你改过 php.ini、调过 PHP-FPM 参数、或者在面板里开过非常规模块，花十分钟自查一下不吃亏。
我这台服务器算不算「非默认配置」？
这个判断比听起来麻烦。先跑 php -v 和 php -i | grep -i "loaded configuration"，确认线上跑的到底是哪个 php.ini。不少客户会问：我明明改了配置，怎么没生效？多数情况是改了 CLI 那份、没改 FPM 那份——宝塔面板里改的是 FPM 用的，命令行读的是另一条路径，两份经常不一致。
再对着这几条看：
- allow_url_include 是不是被人开过，默认应该是 Off
- disable_functions 是不是空的
- php-fpm 池的运行用户是不是统一的低权限账号，别拿 root 跑
- 上传目录、缓存目录有没有留着 .php 的执行权限
动手之前先把配置备份一份：cp /www/server/php/74/etc/php.ini /root/php.ini.bak，版本号按你实际的改。备份这一步我们几乎每次都强调，因为配置改崩、站点起不来的情况，回滚比排查快得多。
补丁没来之前，先动哪几处？
官方缓解措施的具体条目，以 PHP 安全团队的公告为准。下面是我们平时做加固的常规动作，作用是收窄暴露面，它不等于官方缓解方案，别拿它当免死金牌。
- 停掉没在用的 PHP 版本。面板里常留着好几个版本，只留站点在用的那个，其余一律不监听。
- 上传目录和静态资源目录禁止解析 PHP。Nginx 里加一段 location ~* ^/uploads/.*\.php$ { deny all; }，宁可写多不要写少。
- allow_url_include=Off；allow_url_fopen 如果业务没用到远程文件，也一起关。
- php-fpm 池走最小权限，打开慢日志和错误日志，真出事能翻到痕迹。
- 管理后台限制成固定 IP 访问，先用防火墙或面板的安全组挡一层。
改完执行 systemctl reload php-fpm，再用 phpinfo 页面确认生效。我们经常遇到一种情况：配置写对了，但面板上的重载按钮没点，隔天还以为已经堵上了。
这次为什么不能只盯 PHP？
据公开报道，AWS 提到相关漏洞在修补前四天就已出现攻击活动——也就是说你看到新闻那天，扫描流量可能已经跑过一轮了。同一天还有另一条：趋势科技 ZDI 团队疑似误将多份漏洞报告抄送到公开的 Linux Kernel Mailing List（Linux 内核邮件列表），其中两项远程代码执行漏洞评分高达 9.0 分（报道中的说法），部分漏洞当时尚未修复。
对做客户站的小团队，这就是两条提醒。一是别把「还没被打」当安全；二是内核和面板的更新得排进计划。内核更新跟不跟是个取舍：跟，可能踩到旧驱动或老程序不兼容；不跟，已知漏洞就一直敞着。比较稳的做法是测试机先升，观察一到两个业务周期再动生产。
要不要现在换服务器、换面板？
不用。漏洞在 PHP 这一层，换一台同样跑 PHP 的机器解决不了问题，只是花钱买个心理安慰。真正值得换的情况只有两种：你的 PHP 版本早就停止维护了，或者服务商连基本的安全更新都不给。其余时候，把上面几条做完更划算。
顺带说句合规：服务器放在境外不等于没有要求。境外节点我们一般只谈线路、时延、部署周期和合规责任，ICP 备案该按内地规则走的还得走，客户站上这条别打折扣。
微码盒的 WordPress主题、DedeCMS 模板和建站源码发布前会过一遍依赖检查，你要是在别处下的模板里带了来路不明的 PHP 文件，正好借这次清一遍。站内 WordPress教程、服务器知识库和宝塔面板建站教程里有对应的自查步骤，动手前扫一眼能少走弯路。
今天先把 php.ini 备份好，再决定改不改。顺序别反。
