紧急：Magento2中的PHP安全漏洞

这不是普通的“有空再升级”提醒。PHP 官方在 2026 年 10 月 21 日发布紧急安全公告：两个漏洞都可能导致未经身份验证的远程代码执行，CVSS v4.0 评分均为 9.2。Magento 2 的前台、后台、REST、GraphQL、Cron 以及队列消费者通常都运行在 PHP 上，因此只要服务器对外处理 PHP Web 请求，就应立即检查。

先确认风险：不是只有 Magento 代码有问题才会中招

这次漏洞位于 PHP 核心，不是某个 Magento 扩展。受影响的运行方式包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。官方特别指出，mod_php 风险更高：已经有演示表明，恶意请求可能在应用代码开始执行前触发攻击。也就是说，WAF、Magento 表单校验或关闭某个模块都不能替代 PHP 升级。

• CVE-2026-109618：内存不足处理期间，PHP 内部请求数据可能只完成部分初始化，随后清理阶段把无效数据当成有效数据使用，造成内存破坏并可能发展为 RCE。
• CVE-2026-109619：属于请求的全局状态在底层内存释放后仍可能残留，后续请求被同一个 Worker 处理时，会在正常初始化重置之前使用这份陈旧状态。

安全版本：必须达到这些版本或更高

PHP 8.1 及更早版本已经不再由 PHP 项目正常维护。部分 Linux/LTS 厂商可能提供回补补丁，但必须向发行版或主机商确认具体软件包是否已包含这两个 CVE 的修复；无法确认时，应升级到 Magento 支持的 PHP 8.2/8.3/8.4 分支。

第一步：查清楚网站“实际”使用的 PHP

只运行 php -v 看到的是 CLI 版本，它可能与 Nginx/Apache 调用的 PHP-FPM 不是同一个版本。至少要把 CLI、FPM、Web Server 和 Cron 四处对齐。

php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'

# 查看正在运行的 FPM 与服务
ps -ef | grep '[p]hp-fpm'
systemctl list-units --type=service | grep -E 'php.*fpm'

# Nginx 站点实际转发到哪个 socket/端口
nginx -T 2>/dev/null | grep -n 'fastcgi_pass'

# Apache 是否加载 mod_php
apachectl -M 2>/dev/null | grep -i php

# Magento CLI 与平台依赖
bin/magento --version
composer check-platform-reqs

如果同一台机器有多个站点或多个 FPM Pool，要逐个检查。负载均衡后面有多台 Web 节点时，也要逐台核对，不能只升级其中一台。

Magento 2安全升级顺序

1. 先看兼容性。确认当前 Magento 版本支持的 PHP 主分支，检查 composer.json 的 PHP 约束，并列出 ionCube、支付、搜索、ERP 等扩展是否有二进制或版本限制。
2. 建立回退点。备份数据库、app/etc、composer.lock、PHP/FPM 配置和当前软件包清单。回退应切回已经打补丁的备用节点，不要长期回退到有漏洞的 PHP。
3. 在预发布环境升级。用系统发行版或可信 LTS 厂商的软件包，不要从不明仓库下载 PHP 二进制。
4. 对比扩展与配置。确认 bcmath、curl、dom、gd、intl、mbstring、openssl、pdo_mysql、simplexml、soap、sodium、xsl、zip 等 Magento 所需扩展仍被加载；检查 opcache、memory_limit、realpath_cache 等配置没有在包升级时被覆盖。
5. 维护窗口滚动上线。多节点先从负载均衡摘除一台，升级并验证后再逐台替换，避免新旧 PHP Worker 同时提供服务。

下面是常见发行版的检查与升级示例。软件包名称以你的仓库为准，执行前先查看候选版本，确认它包含安全修复：

# Debian / Ubuntu：先确认仓库候选版本
apt-cache policy php8.2-cli php8.2-fpm
sudo apt-get update
sudo apt-get install --only-upgrade php8.2-cli php8.2-fpm php8.2-common

# RHEL / AlmaLinux / Rocky Linux：先查看可用版本
sudo dnf --showduplicates list 'php*'
sudo dnf update 'php*'

# 重启对应 Worker（服务名按实际版本修改）
sudo systemctl restart php8.2-fpm
sudo systemctl reload nginx

# 再次确认 CLI 与 FPM
php -v
php-fpm8.2 -v 2>/dev/null || php-fpm -v

Magento 应用层建议在维护窗口执行：

bin/magento maintenance:enable
composer check-platform-reqs
bin/magento cache:flush
bin/magento indexer:status
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento maintenance:disable

如果本次只升级同一 PHP 小版本，通常不需要运行 setup:upgrade；只有 Magento 代码、模块或数据库 Schema 同时发生变化时才运行。不要为了“保险”在生产环境无条件执行一整套高风险部署命令。

暂时无法升级时，只能降低风险，不能视为已修复

PHP 官方明确说明：没有完整的替代缓解措施，升级才是安全方案。若确实需要几个小时准备维护窗口，可在服务器级配置中临时降低已知攻击路径：

; php.ini 或 FPM Pool 中设置，不能只在 Magento 代码里 ini_set()
session.upload_progress.enabled = 0

; 官方针对已确认路径给出的临时措施之一
memory_limit = -1

; 按业务尽量缩小，需上传文件的站点可根据实际设定
post_max_size = 32M
upload_max_filesize = 30M

; 仅 PHP 8.5
fatal_error_backtraces = 0

修改后必须重启所有 PHP Worker，并从反向代理层限制请求体大小、表单字段数量、multipart 部件数、Header 数量与嵌套深度。上述设置只是减少特定触发路径，不能保证站点安全，也不能替代补丁。

升级完成后怎么验证

• 从每一台 Web 节点核对实际 FPM 版本，确保均达到 8.2.35、8.3.36、8.4.27 或 8.5.12。
• 运行 composer check-platform-reqs，确认 PHP 扩展和版本约束全部通过。
• 测试前台首页、分类页、商品页、搜索、加购、登录、结账、支付回调、后台保存商品、REST 和 GraphQL。
• 确认 Cron、RabbitMQ Consumer、索引器使用的 CLI PHP 也已经升级，而不是继续调用旧路径。
• 观察 PHP-FPM、Nginx/Apache、Magento system.log 和 exception.log，重点看新的 Deprecated、TypeError、扩展加载失败、502 与 Worker 崩溃。
• 检查负载均衡节点清单，防止一台遗漏升级后仍随机接收流量。

发现异常请求怎么办

这两个漏洞可能在 Magento 应用代码运行之前触发，因此 Magento 日志没有记录并不能证明未受影响。若发现不明 Worker 崩溃、异常 OOM、可疑 multipart 请求、陌生进程或文件变更，应先隔离节点、保留 Web/FPM/系统日志和内存/磁盘证据，再更换凭证并从可信镜像重建。不要只删除可疑文件后继续上线。

结论：先确认 Magento 当前支持哪个 PHP 主分支，然后立即升级到该分支的安全版本。不要停留在 PHP 8.1 或更早版本，也不要把 WAF、关闭上传、清缓存当成修复。

需要Magento和PHP升级方面的帮助吗？

在未检查扩展和主题兼容性的情况下升级PHP，可能会导致结账流程中断。如果您需要协助测试，或希望在不影响网站正常运营的情况下安全升级Magento商店，请随时联系我们的团队。