2023年10月，WordPress插件WooCommerce的一个支付模块被爆出SQL注入漏洞。攻击者构造一个带单引号的参数，就能把整个数据库拖走。这个漏洞在GitHub上挂了三天，官方才发补丁。那三天里，暗网论坛上已经有人打包卖利用脚本，标价200美金。

这就是典型的PHP 1day。不是0day那么神秘，也没人给你留修复时间。补丁一出，攻击流量在24小时内暴涨——因为所有人都知道漏洞在哪了，而大量站点还没升级。

1day的本质是时间差

PHP生态有个特点：CMS、框架、插件层层嵌套。WordPress本身安全，但你装的某个三流插件可能三年前就没人维护了。补丁发布不等于修复完成。Cloudflare的统计说，一个高危PHP漏洞从补丁发布到全球80%站点完成修复，平均需要47天。47天，够写多少自动化扫描脚本了？

我去年帮朋友处理过一次入侵。他的站点跑的是ThinkPHP 5.0.22，一个2018年的老版本。攻击者用的是ThinkPHP 5.0.23修复的远程代码执行漏洞。日志里看得很清楚：扫描器先请求/index.php?s=index/\think\app/invokefunction，返回200，然后直接上传webshell。整个过程不到两秒。朋友问我怎么中的，我说你版本太老了。他说没收到更新提示。对，ThinkPHP 5.0早就停止维护了，哪来的提示。

写1day利用比你想的简单

很多人觉得漏洞利用是黑客专属。其实PHP 1day的利用门槛低得吓人。拿最常见的文件包含漏洞举例，补丁对比一下就能找到过滤逻辑的缺陷。比如修复前代码长这样：

$file = $_GET['file']; include($file);

修复后变成：

$file = $_GET['file']; if (strpos($file, '..') !== false) {  die('hack attempt'); } include($file);

你看，只过滤了..。那用绝对路径呢？/etc/passwd直接读。或者用php://filter流包装器，照样能读源码。这种补丁等于没补。写利用脚本？十行代码都用不了。

真实场景里的1day更脏

去年有个客户跑的是Discuz! X3.4。Discuz有个漏洞是后台任意文件删除，补丁加了文件路径校验。但校验逻辑写错了，只检查了./没检查../。攻击者从./../../etc/passwd这种路径绕过。更离谱的是，这个补丁发布后，官方论坛上有人贴出了绕过方法，帖子存活了六个小时才被删。六个小时，够全网爬虫抓走了。

PHP 1day的另一个重灾区是Composer依赖。你项目里引了monolog/monolog 1.x，某个版本有反序列化漏洞。补丁发了，你跑composer update，但另一个依赖锁死了旧版monolog。你手动改composer.json，结果测试环境过了生产环境炸了——因为生产环境PHP版本是7.1，新monolog要求7.2。最后你只能写个WAF规则临时挡一下。这种破事每个PHP开发者都遇到过。

怎么防

别指望厂商。自己盯CVE。订阅php-security邮件列表，或者用roave/security-advisories这个Composer包，它直接阻止你安装有已知漏洞的依赖。生产环境开open_basedir，禁用exec、system、passthru这些函数。WAF规则要针对具体1day写，别用通用规则——通用规则拦不住php://filter这种合法流包装器。

最关键的：别用停止维护的PHP版本。PHP 5.6的最后一个安全更新是2018年12月。现在2024年，你还在跑5.6，等于把大门钥匙插在锁上。升级会痛，但不升级会死。这话难听，但真实。