PHP 爆发近几年最严重的安全漏洞「php2shell」，9.2 分，能直接拿下服务器权限，WordPress 站点都要注意了！
内容提要
PHP被披露存在严重远程代码执行漏洞CVE-2026-109618和CVE-2026-109619，CVSS评分9.2，影响PHP 5及之后几乎所有版本，被称为php2shell。漏洞位于multipart文件上传与session上传进度处理逻辑，在应用代码之前执行，WordPress等站点均受影响。官方已提前发布补丁，但8.1及更早版本不再维护。缓解措施为关闭session.upload_progress或在Web服务器层拦截multipart请求，最终仍需升级PHP并排查入侵痕迹。
延伸解读
漏洞在应用之前执行，常规防护手段失效
文章强调，漏洞位于 PHP 解析 multipart 请求和 session 上传进度的阶段，早于 WordPress、Laravel 等应用代码运行。因此，安全插件、应用层中间件、登录校验、禁用危险函数、关闭 file_uploads 或限制上传大小都无法阻止攻击。WAF 也只在服务器无法被直接访问时有效。这意味着防护必须落在 PHP 配置或 Web 服务器层，不能依赖应用侧修补。
旧版本拿不到补丁，暴露面集中在 8.1 及更早
PHP 官方目前只维护 8.2 至 8.5 分支，8.1 及更早版本不再获得官方补丁。文章引用 Shodan 数据称，约 88.4 万台暴露主机报告 PHP 8.1 或更老版本，占统计总量的 59%。对 WordPress 站长而言，若站点仍运行 7.4、8.0 或 8.1，补丁发布后将处于“漏洞公开、无官方修复”的状态，只能依赖服务商 backport 或迁移到受支持版本。
缓解措施有明确副作用，且只是权宜之计
关闭 session.upload_progress 会导致依赖该特性的上传进度条失效；在 Web 服务器层拦截所有 multipart 请求则会让 WordPress 媒体库上传、带附件表单乃至 Contact Form 7 提交全部失败。文章提醒，这些措施仅降低风险，不是修复，补丁发布后应尽快升级并拆除拦截层。共享主机用户还需通过 .user.ini 或 .htaccess 尝试关闭特性，但 Apache 模块模式与 PHP-FPM 组合存在兼容差异。
补丁发布后需排查入侵痕迹，而非仅升级
文章建议将排查时间回溯到 10 月 20 日 15:00 UTC 首个爆料帖出现之前，检查异常 multipart 请求、PHP-FPM worker 崩溃、Web 目录新增文件、多余 .user.ini、auto_prepend_file 改动、新增 cron 或 SSH key、异常进程和外连、后台新增管理员账号。若发现入侵，应先隔离断网、保留日志、重建服务器，并轮换 PHP 用户可读的所有密钥。仅升级 PHP 不足以排除已被利用的可能。
Q&A
php2shell 漏洞的 CVE 编号和评分是多少？影响哪些 PHP 版本？
漏洞编号为 CVE-2026-109618 和 CVE-2026-109619，CVSS v4.0 评分 9.2 分。影响 PHP 5、6、7 和 8 等几乎所有版本，即 PHP 5 及之后的所有版本。
这个漏洞具体出在 PHP 的哪个功能模块？为什么说网站有没有上传表单都受影响？
漏洞位于 PHP 处理文件上传的逻辑，即 multipart/form-data 请求解析，以及 session 上传进度（session.upload_progress）特性。这段逻辑在 WordPress、Laravel 等应用代码之前执行，因此无论网站是否有上传表单，只要运行在受影响 PHP 版本上就不安全。
补丁发布前有哪些临时缓解措施？具体怎么操作？
有两招权宜之计：1）关闭 session 上传进度：在 php.ini 中设置 session.upload_progress.enabled = Off；若用 PHP-FPM，需在每个 pool 配置中用 php_admin_flag[session.upload_progress.enabled] = off 锁死，防止 .user.ini 覆盖；共享主机可在站点目录放 .user.ini 写 session.upload_progress.enabled = Off（Apache 模块方式改用 .htaccess 的 php_flag）。2）在 Web 服务器层拦截所有 multipart 请求：nginx 用 map 匹配 Content-Type 含 multipart 并 return 403 或 444；Apache 用 <If> 表达式拒绝；LiteSpeed 用 RewriteCond 拦截。注意要拦截所有 HTTP 方法，且此招会导致文件上传功能失效。
为什么 WordPress 安全插件、WAF、关闭 file_uploads 等措施对 php2shell 无效？
因为这些措施都运行在 PHP 解析请求体之后。WordPress 安全插件（如 Wordfence）通过 auto_prepend_file 加载，等它运行时 PHP 已解析完请求；WAF 只在服务器不能被直接访问时有用，攻击者直接拿 IP 打就绕过了；file_uploads = Off 只是不保存文件，PHP 仍会解析 multipart 请求体；disable_functions 和上传大小限制也无效，漏洞在解析阶段。
官方补丁发布后，升级 PHP 时需要注意哪些坑？
注意：1）先升对外网暴露的机器；2）Debian/Ubuntu 是 backport 修复，版本号可能没变，更新前先 apt update，再用 apt-cache policy 看候选版本，更新后用 changelog 确认提到这两个 CVE；3）检查 apt-mark showhold 防止包被 hold 导致静默失败；4）重启所有 PHP-FPM 分支及长驻进程（队列 worker、Horizon、调度器、Octane）；5）Docker 需重新拉基础镜像并 rebuild 部署；6）用 ls -l /proc/*/exe | grep 'php.*deleted' 找出旧进程并重启；7）共享主机催促服务商确认修复版本。
打完补丁后如何排查服务器是否已经被入侵？
把时间回溯到 2026 年 10 月 20 日 15:00 UTC 之前开始查：1）Web 服务器和 PHP 日志有无异常 multipart 请求或 PHP-FPM worker 崩溃；2）Web 根目录、上传目录、插件目录、mu-plugins 有无新增或改动文件（可用 find /var/www -type f -newermt '2026-10-20 15:00 UTC'）；3）有无多出的 .user.ini 或 auto_prepend_file 被改；4）cron、systemd、Supervisor 有无新条目，有无新 SSH key；5）PHP 用户有无异常进程或外连；6）后台有无多出的管理员账号。建议安装进程监控，盯住 PHP 工作进程是否派生子进程（如 sh、bash、python、curl、wget）。若发现入侵，先断网隔离，保留日志，重建服务器并轮换所有密钥。
