必须立即升级至PHP 8.2.35、8.3.36、8.4.27或8.5.12及以上正式版，因CVE-2026-109618和CVE-2026-109619漏洞已在野利用，低于任一修复版本均存在远程代码执行风险。
你的 PHP 版本只要低于 8.2.35、8.3.36、8.4.27 或 8.5.12 中任一对应版本，就必须立即升级——这不是“建议”，而是当前正在被扫描和利用的明确风险边界。
php -v 输出的版本号怎么看才准确
很多人只看 php -v 返回的第一行，比如显示 PHP 8.2.34 就以为没问题，但实际可能跑着多个 PHP 实例。关键要看 Web 服务真正调用的是哪一个。
- 执行
php -v确认 CLI 版本，仅作参考 - 在 Web 根目录放一个
phpinfo.php（内容为<?php phpinfo(); ?>），用浏览器访问它，查页面顶部的PHP Version字段——这才是 Apache / nginx + php-fpm 实际加载的版本 - 如果用了 cPanel、Plesk 或 Docker，还要检查面板内设置的 PHP 版本、或容器镜像的标签（如
php:8.2-apache默认不等于8.2.35） - 某些环境（如宝塔）会同时安装多个 PHP 版本，但只启用其中一个；需进面板确认“网站所用 PHP 版本”是否已切到安全版本
为什么 8.2.34 和 8.2.35-rc1 都不安全
官方补丁只存在于正式发布的 .35 及之后版本，所有带 -rc、-dev、-beta 后缀的预发布版，以及任何未出现在 PHP 官方 ChangeLog 中的版本，都不包含修复。
-
8.2.35-rc1是测试版，没有 CVE-2026-109618 / CVE-2026-109619 的补丁，不能替代正式版 - 部分第三方源（如 Ondřej Surý PPA）在补丁发布后数小时内才同步，
apt list --upgradable | grep php显示有更新 ≠ 已含修复，必须核对具体版本号 - Cloudflare、Chainguard 等提前发布的镜像虽含补丁，但属于非官方渠道，不保证长期维护，生产环境仍应以 php.net 发布为准
nginx + php-fpm 组合最容易被误判为“已修复”
很多运维看到 php-fpm 进程重启了，就认为漏洞已堵住，其实没那么简单。
立即学习“PHP免费学习笔记（深入）”；
- php-fpm master 进程升级后，worker 进程可能还在用旧二进制——必须执行
sudo systemctl restart php8.2-fpm（或对应版本名），不能只 reload - nginx 配置中若硬编码了
fastcgi_pass 127.0.0.1:9000，而该端口由旧版 php-fpm 监听，新进程即使启动也无流量经过 - 某些环境存在多个 php-fpm service 单元（如
php8.2-fpm.service和php-fpm.service），systemctl status 查到的未必是真实生效的那个 - WordPress、Drupal 等 CMS 不影响漏洞存在性——攻击发生在 PHP 请求初始化阶段，业务代码根本没机会运行
最危险的不是找不到补丁，而是查到版本号接近安全线（比如 8.2.34）后，下意识觉得“差一点没关系”。CVE-2026-109618 和 CVE-2026-109619 的 PoC 已公开，扫描器正批量试探，只要版本号没卡在官方公布的修复阈值上，服务器就在射程内。
