用PHP搭的网站这次是否受影响，取决于服务器上PHP是不是在处理网页请求，而不太取决于你的代码写得好不好。 PHP在10月20日被曝出两个远程代码执行漏洞，编号 CVE-2026-109618 和 CVE-2026-109619，官方给的 CVSS v4.0 评分是 9.2 分，安全圈叫它"PHP2Shell"：攻击者不用账号密码，向网站发一个特殊构造的请求，就可能让服务器执行任意代码。官方口径同样直接：所有处理网页请求的 PHP 都在风险范围内，PHP-FPM、Apache modphp 这些常见运行方式都算，其中 modphp 风险最高，PHP-FPM 也不安全。但"在风险范围内"和"已经被打进"是两回事，收口的动作也已经明确：PHP 基金会 10 月 21 日发布紧急安全更新，修复版本包括 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。知乎知乎知乎
"全球七成网站拉警报"的说法并非夸张，外媒报道中该漏洞潜伏多年，攻击者无需密码即可远程接管服务器，已导致英、日等多国政务网站被迫下线。连负责防黑客的机构也先动手避险：日本财务省停了官网的部分内容和服务，紧急检查服务器、安装修复。商业端同样在让步：受 PHP 全球安全漏洞影响，Sonos 在 App 内暂停了网易云音乐、QQ音乐、酷狗、酷我四项音乐服务。新浪微博知乎知乎
为什么没写上传功能也可能中招
Wiz用当时最新的WordPress、Drupal、Joomla镜像搭建测试环境，复现了无需登录的远程攻击，还验证了从内存中读取密码、令牌和API密钥的攻击路径，某些Apache加mod_php的部署里，攻击在网站自己的程序启动前就能发生。原因要回到漏洞的位置：它出在 PHP 自己身上，跟你的代码写得好不好没有关系，代码写得再规范也拦不住。知乎知乎
官方确认的攻击路径有两条：一条走文件上传进度跟踪功能，这个功能默认开启，哪怕网站代码从来没用过它也可能被触发；另一条只存在于 PHP 8.5，与新增的致命错误回溯功能有关。而且触发不需要大流量：一条披露的攻击路径中，不到8MiB的请求数据，处理时却足以耗尽PHP默认128MiB的内存额度。知乎知乎
版本才是最现实的分水岭：一半以上对外主机拿不到官方补丁
PHP 官方目前只维护 8.2、8.3、8.4、8.5 这四个分支，也就是说，PHP 8.1 及更早的版本，拿不到官方补丁。对更老的版本只做了有限的照顾：8.1 及更老的版本官方已经不再维护，只额外给 7.4、8.0、8.1 提供了源码补丁，7.3 及更老的版本连源码补丁都没有，只能迁移到新版本。知乎知乎
暴露在公网上的老版本比想象的多：据安全公司统计Shodan数据，10 月 20 日那天，对外暴露且 HTTP 头里报了 PHP 版本的主机大约 150 万台，其中报8.1或更老版本的约占59%。WordPress站点里还有一大把跑在7.4、8.0、8.1上，这批站点从此处在"漏洞公开、没有官方二进制补丁"的状态里。知乎
排查三步，五分钟内做完
第一步，确认服务器上有没有PHP——包括"装了但没用"的。宝塔用户在「软件商店-已安装」列表里搜PHP，系统包安装的跑一下`dpkg -l | grep php`（Debian/Ubuntu）或`rpm -qa | grep php`（CentOS/RHEL）。注意PHP装好之后会作为一个服务一直运行，用不到的版本也在监听。知乎
还有两个容易漏的点：phpMyAdmin本身就是PHP程序，装了它服务器就在用PHP；在Ubuntu上直接执行apt install php，系统默认会顺带装上Apache和mod_php，正好是官方认为风险最高的组合。知乎
第二步，确认版本。`php -v`或phpinfo逐个查出具体版本号，对照上面的修复列表；拿不准的可以用OpenAI发布的Codex检查skill帮网站运营者检查PHP版本、判断是否可能受影响，但它查的是PHP版本，不能替网站完成升级。第三步，确认运行方式：mod_php站点排在最优先，宝塔这类PHP-FPM环境紧随其后，用不到的PHP直接卸载最干净，卸载前先确认没有网站还在用这个版本。知乎
修：能升就升，升不动先堵门，但这些常见做法拦不住
升级的正确顺序是备份网站和配置，再升级PHP，重启php-fpm或Apache，最后把站点功能点一遍——跨版本升级会一次带来二十来个版本的附带改动。宝塔10月21日当天就发公告同步了4个官方修复版本，Linux面板还自行给7.4、8.0、8.1打包了修复版；但Windows版宝塔的8.1及更早版本目前还没有修复包，只能先按下文的方法修改配置临时缓解，然后尽快迁移到新版本。暂时升不动的，可以在配置里关闭session上传进度压风险，但要清楚PHP核心开发者Gina Peter Banyard的原话：唯一的缓解措施就是打补丁升级。知乎知乎
配置环节还有个实测的坑：只写进php.ini不够，站点根目录下一个.user.ini就能把它改回去，PHP-FPM必须在每个pool配置里用php_admin_flag锁死再重启，.user.ini才改不动。知乎
还有一批"看起来有用的防护"这次统统失效，别指望它们：WordPress 安全插件对此没用，包括开了 Extended Protection 的Wordfence，它靠auto_prepend_file加载，等它跑起来的时候，PHP早就把请求体解析完了；`file_uploads = Off`没用，PHP照样解析multipart请求体；`disable_functions`、上传大小限制、Laravel维护模式、应用层中间件、登录校验也都没用，它们全跑在PHP解析之后。WAF只在服务器不能被直接访问时有效，攻击者绕过域名直接打IP就失效；Cloudflare给使用其Web应用防火墙的免费和付费客户部署了紧急保护，但官方强调这只是临时措施，补丁出来就得安装。知乎知乎
修完别收工：攻击先于补丁出现，必须回查
Cloudflare首席技术官Dane Knecht在补丁计划发布前六个多小时就发帖：已经看到了早期攻击。更要命的是，亚马逊、watchTowr 等安全厂商都监测到了针对这两个漏洞的攻击尝试，而且攻击成功之后网站照样能正常访问，你很难察觉。所以升级之后，把自查时间往回推到10月20日15:00（UTC）前后，逐项过一遍：日志里有没有异常multipart请求和PHP-FPM worker崩溃，网站根目录、上传目录、插件目录有没有新增或改动的文件，有没有多出来的.user.ini、被改动的auto_prepend_file，cron和systemd里的新条目、陌生的SSH key，后台多出的管理员账号，以及PHP进程派生出sh、curl这类不该出现的子进程。真查到东西，处理顺序只有一种：先断网隔离，保住 Web 和 PHP 日志，然后重建服务器，把 PHP 用户能读到的所有密钥全轮换一遍，包括.env、数据库密码、API key。知乎知乎知乎
这次和以往最大的不同，是锅不在网站代码也不在插件，而在PHP引擎自己。还停在8.1或更老版本的站点，与其等风头过去继续裸奔，不如趁现在迁到受支持的分支。官方也特别强调，目前没有任何配置能完全替代升级，升级是唯一安全的选择。另据OpenAI预告，PHP只是团队已发现、正在修复的多项重大漏洞之一，未来几个月这类发现预计还会显著增加——平时把"服务器上装了什么、各是什么版本"这张清单维护住，下次就不用连夜从头排查。知乎知乎
