10月21日，PHP官方披露两个严重远程代码执行漏洞（CVE-2026-109618 / CVE-2026-109619），该漏洞位于PHP运行时底层，非Drupal本身代码。即便Drupal核心与所有贡献模块均已更新至最新安全版本，只要底层PHP版本处于受影响范围，公网环境下就存在未认证远程代码执行风险。成都长风云Drupal开发团队已完成正在运维的网站的升级，结合Drupal升级的过程，我们总结了官方版本兼容规范以及一些我们的心得体会，形成一套可用的升级方案，适合企业官网、政务与信创类Drupal站点运维参考。
一、PHP漏洞风险说明
PHP 核心被曝出两个严重的远程代码执行（RCE）漏洞：CVE-2026-109618、CVE-2026-109619，PHP 官方安全公告评定为 CVSS v4.0 9.2（严重）；
watchTowr 已确认两者均为 RCE——攻击者可直接拿到服务器 shell；
PHP官方补丁于北京时间（10 月 21 日，周三）22:00 发布，修复 8.2 / 8.3 / 8.4 / 8.5 四个分支。
受影响PHP分支及最低安全基线版本如下：
- PHP 8.2：需要升级至 8.2.35 及以上
- PHP 8.3：需要升级至 8.3.36 及以上
- PHP 8.4：需要升级至 8.4.27 及以上
- PHP 8.5：需要升级至 8.5.12 及以上
PHP 8.1及更早版本（7.x、5.x）早已停止官方维护，不会收到本次漏洞补丁。部署这类版本的Drupal站点，已经没有直接修复通道，仅能依靠网络隔离、访问控制做临时防护，长期必须规划整体迁移。
常见运行模式，包括PHP-FPM、mod_php、CGI、FrankenPHP均受该漏洞影响，并非Drupal独有，所有基于PHP的Web应用都会面临相同威胁。
临时缓解仅作为应急手段，无法彻底封堵漏洞：收紧外网访问策略、WAF拦截异常上传与POST请求、禁用危险系统调用函数、缩小网站目录写入权限。根治手段只有升级PHP至安全版本。
二、Drupal版本与PHP基线版本兼容关系
Drupal对PHP运行环境存在严格依赖，盲目跨大版本升级PHP，可能引发白屏、500错误、Composer依赖报错、视图和自定义模块失效等问题。优先选择同分支小版本补丁，兼容性风险最低。
- Drupal 10：最低支持PHP 8.1，推荐8.2~8.4；安全基线 8.2.35 / 8.3.36 / 8.4.27
- Drupal 11：最低支持PHP 8.3，推荐8.3~8.5；安全基线 8.3.36 / 8.4.27 / 8.5.12
- Drupal 12：最低支持PHP 8.4；安全基线 8.4.27 / 8.5.12
- Drupal 9：已经终止支持，最高仅适配PHP 8.1，无法修复本次漏洞，建议尽快迁移
- Drupal 7：早已EOL，仅适合纯内网隔离场景，公网暴露风险极高
很多存量政企Drupal 10站点长期运行在PHP8.2低版本，恰好落在漏洞影响区间。这类站点优先做8.2分支小版本升级，不建议直接跳转到8.3、8.4大版本，避免大量老旧贡献模块出现兼容异常。
三、标准化升级流程：先验证，再上线，保留回滚路径
实操顺序：完整备份 → 预发环境复现生产数据与配置 → 预发升级PHP并做兼容性检测 → 同步Drupal安全更新 → 业务功能回归测试 → 低峰窗口灰度上线 → 日志监控 + 回滚待命
线上环境禁止直接先行升级PHP，自定义模块、自研主题里的弱类型写法、废弃API调用，在新版本严格报错机制下很容易直接抛出致命错误。
1. 升级前全量备份
# 代码目录备份 rsync -av /var/www/drupal /backup/drupal_$(date +%Y%m%d) # 数据库备份 drush sql-dump --result-file=/backup/sql/drupal_$(date +%Y%m%d).sql # PHP相关配置备份 cp -r /etc/php /backup/php_config_$(date +%Y%m%d)
同时记录当前PHP版本、Drupal核心版本，作为回滚对照基准。
2. 预发布环境兼容性校验
预发环境需要同步生产代码、数据库、php.ini、pool池配置，保证环境一致性。升级PHP之后清理缓存，使用drupal-check工具扫描自定义模块与主题代码，排查废弃接口、参数不匹配、类型错误等问题。
drush cr composer require --dev mglaman/drupal-check vendor/bin/drupal-check web/modules/custom web/themes/custom
进入后台【报告 - 站点状态】，检查PHP扩展依赖：PDO、XML、GD、缓存扩展等是否正常加载，确认无持续性报错。
3. 同步Drupal核心与贡献模块安全更新
虽然本次漏洞根源不在Drupal，但底层安全整改时，同步拉取Drupal官方安全更新，可以规避叠加风险。标准Composer项目更新命令参考：
composer update drupal/core --with-dependencies composer update --no-dev drush updatedb drush cr
更新完成后，对照Drupal安全公告SA系列条目确认，不要只依靠版本号判断安全状态。
4. 业务回归测试要点
重点覆盖文件上传、Webform表单、Feeds数据导入、视图展示、权限校验、REST接口、定时Cron任务，文件上传链路是RCE攻击高频入口，需要重点复测。
5. 生产上线与回滚操作
选择业务低峰时段操作；容器化环境不建议在容器内部就地升级，优先重建基于安全PHP版本的基础镜像滚动发布；物理机或者虚拟机环境可以分批节点验证。升级完成重启php-fpm，单纯reload不一定清空opcache缓存。
systemctl restart php8.2-fpm drush updatedb && drush cr
回滚逻辑：出现大面积异常时，切回原有PHP安装包与配置，重启服务；如果数据库执行了更新脚本，导入升级前备份SQL，再定位兼容问题。
四、不同站点场景差异化处置建议
- Drupal10 + PHP8.2存量站点：首选升级至8.2.35，改动最小，业务中断风险可控，不盲目升级大版本
- Drupal11 + PHP8.3：升级至8.3.36，Drupal11原生对PHP8.3支持稳定，可同步评估后续迁移8.4的计划
- Drupal7 / Drupal9 公网站点：没有可用补丁，短期收紧访问、关闭上传、WAF强防护，中长期输出迁移方案
- Docker/K8s容器集群：镜像版本化管理，保留旧镜像，故障时快速切换
五、配套加固策略，适配等保、信创项目
php.ini层面基础加固：禁用系统执行类函数，配置open_basedir限制跨目录访问，非必要站点关闭文件上传，关闭allow_url_include。
disable_functions = system,exec,passthru,shell_exec,popen,proc_open allow_url_include = Off
Drupal侧加固：匿名用户禁止文件上传；上传目录独立配置，禁止解析PHP；管理员账号启用二次验证，强口令策略；开启日志并接入审计平台，监控异常文件写入与后台登录行为。
服务权限层面：PHP-FPM使用独立低权限用户运行，定期WebShell扫描，收缩服务器对外开放端口。
六、运维高频疑问
Q：Drupal已经是最新安全版，是不是可以不用升级PHP？
A：不行。漏洞属于PHP底层运行时缺陷，和Drupal应用代码无关，Drupal本身无法拦截该攻击。
Q：使用虚拟主机、宝塔面板，无法自行编译升级PHP怎么办？
A：联系服务商要求升级底层PHP版本；暂时无法整改的阶段，限制公网访问、前置WAF防护，评估临时下线风险。
Q：升级后页面出现大量Deprecated警告，是否需要紧急处理？
A：警告不会直接造成漏洞，但后续PHP大版本会转为致命报错。生产环境可以临时关闭错误展示，在预发环境分批修复自定义代码。
七、我们完成的升级案例
Drupal升级">
七、小结
这次漏洞再次说明Drupal安全不能只考虑核心和模块更新，PHP、Web服务、操作系统、数据库共同组成安全底座。
提前预防远比亡羊补牢重要，日常运维升级是确保网站安全运行的最低成本的手段，远比遭到攻击后查找后门、植入代码方面快捷。
