PHP两项9.2分漏洞：Docker容器更新与版本核验教程

PHP已发布CVE-2026-109618、CVE-2026-109619两项漏洞的安全更新，CVSS 4.0评分均为9.2。Docker部署的站点需要检查运行时，但执行完docker compose pull，并不能说明网站已经用上修复版本。

本文面向直接使用维护者PHP镜像的Compose项目，按"盘点版本---确认镜像---更新容器---验收请求"操作。自建应用镜像需要先更新基础镜像并重新构建，不能直接替换成空白PHP镜像。

以下命令依据PHP、Docker官方文档整理，未做漏洞复现、镜像拉取或生产更新；目标标签的发布与可获取状态需单独确认。

一、按分支确认本次修复版本

两项漏洞分别涉及内存不足时的请求清理，以及跨请求残留状态造成的释放后使用，可能导致未认证远程代码执行。PHP公告将处理Web请求的PHP安装列入核查范围，包括FPM、Apache mod_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

先在原分支内核对修复，再评估跨分支迁移。发行版或LTS供应商可能回补补丁，要核对其安全公告和软件包修订，不能只按php -v的版本字符串判断。

配置缓解不能完整替代更新。PHP 8.1及更早版本已不再接受常规上游维护；本次针对7.4、8.0、8.1提供的最小源码回补，不等于恢复维护，也不意味着对应容器镜像已发布。

二、在原Compose项目中盘点实例

先找到实际部署目录、PHP服务名和原发布命令。下面示例使用Bash，在同一终端逐段执行。先设置项目目录和服务名；PHP_COMPOSE数组必须沿用原项目全部-f、-p、--env-file参数，原部署没有时才保留默认值。

bash 复制代码

: "${PHP_PROJECT_DIR:?请先设置原项目目录}"
: "${PHP_SERVICE:?请先设置实际PHP服务名}"
cd "$PHP_PROJECT_DIR" || exit 1
PHP_COMPOSE=(docker compose)
"${PHP_COMPOSE[@]}" ps
"${PHP_COMPOSE[@]}" images "$PHP_SERVICE"
"${PHP_COMPOSE[@]}" exec -T "$PHP_SERVICE" php -v

盘点结果记录服务名、容器ID、镜像引用、PHP版本和公网暴露情况。exec输出是容器内CLI的版本，用于初步定位。Web服务、队列和定时任务应逐项清点，HTTP攻击路径与纯CLI任务的风险分别判断。

更新前保留当前部署配置、镜像标识和业务检查结果。回滚路径也要提前核对；退回旧镜像会重新暴露已知风险，出现兼容问题时应同时评估临时隔离等处置。

三、确认维护者镜像内容，再准备拉取

上游PHP修复发布后，镜像维护者还需要构建对应制品。核对维护者说明、完整标签、FPM或Apache变体、基础系统和CPU架构，避免为了追版本换掉原应用依赖。不要用latest代替版本判断，也不要按修复版本号猜一个尚未确认存在的标签。RC或测试标签不能代替已确认纳入修复的稳定制品。

毫秒镜像（1ms.run）在这一步提供镜像获取与分发入口。Docker Hub的PHP官方镜像可按docker.1ms.run/library/php:完整标签获取；入口能承接拉取，补丁内容仍由维护者制品及后续运行核验确认。

先设置维护者已确认含修复的PHP_FIXED_TAG，再拉取并记录本机对应平台的镜像信息：

bash 复制代码

: "${PHP_FIXED_TAG:?请先设置维护者确认含修复的完整标签}"
PHP_IMAGE="docker.1ms.run/library/php:${PHP_FIXED_TAG}"
docker pull "$PHP_IMAGE"
docker image inspect "$PHP_IMAGE" --format \
  'ImageID={{.Id}} OS={{.Os}} Arch={{.Architecture}} RepoDigests={{json .RepoDigests}}'

拉取失败应停在这里排查网络、权限、路径和标签可用性。镜像更新时间本身也不能证明已纳入指定修复。

四、修改原配置并重建PHP服务

在原Compose文件中，仅将目标服务的image改为确认后的完整地址，保留环境、网络、挂载、启动命令及健康检查。若原来固定了digest，也要更新引用。以下只展示需要修改的字段，不能拿它覆盖完整项目：

yaml 复制代码

services:
  php:
    image: docker.1ms.run/library/php:${PHP_FIXED_TAG:?请设置已确认标签}

php需替换为实际服务名，并把PHP_FIXED_TAG设为原项目能读取的环境变量，例如在执行前导出。检查解析后的镜像列表，确认没有误用旧环境文件：

bash 复制代码

export PHP_FIXED_TAG
"${PHP_COMPOSE[@]}" config --images
"${PHP_COMPOSE[@]}" pull "$PHP_SERVICE"

核对输出确实为目标镜像后，在维护窗口执行原项目发布流程。下面命令会停止并重建选定服务的容器，需要提前安排业务影响：

bash 复制代码

"${PHP_COMPOSE[@]}" up -d --no-deps --force-recreate "$PHP_SERVICE"

pull只下载；restart仍重启原容器；up负责应用配置和镜像变化。这里用--no-deps限定范围，依赖服务如需更新，应另按项目流程处理。不要用down -v作为安全更新步骤。

五、逐个容器核对Image ID和PHP

更新后获取目标服务的运行容器，避免只看本地镜像列表。下面逐个输出容器使用的镜像引用、Image ID和CLI版本：

bash 复制代码

PHP_IDS=$("${PHP_COMPOSE[@]}" ps -q "$PHP_SERVICE")
test -n "$PHP_IDS" || { printf '没有找到运行容器\n' >&2; exit 1; }
while IFS= read -r PHP_CONTAINER; do
  docker inspect --type container "$PHP_CONTAINER" --format \
    'Container={{.Name}} ImageRef={{.Config.Image}} ImageID={{.Image}}'
  docker exec "$PHP_CONTAINER" php -v
done <<< "$PHP_IDS"

容器的.Image可与本机目标镜像.Id核对；仓库digest是另一类标识，不要与Image ID直接比较。标签字符串相同，也不能证明运行中的容器已更新。

FPM或Apache处理Web请求时，还要通过受控内部诊断确认实际Web运行时版本、SAPI及请求落到的实例。不要将CLI版本当成Web版本的全部证据，也不要为了验版本在公网长期保留phpinfo()页面。

六、用业务验收完成本次更新

版本核对完成后，再检查关键页面、登录、上传及项目使用的扩展，保存结果；队列消费者和定时任务如使用同一运行时，也分别确认更新状态。

工单证据	应记录的结果
修复依据	CVE、PHP分支、供应商补丁说明
目标制品	完整标签、平台、digest和本机Image ID
运行实例	容器ID、实际Image ID、Web及CLI核验结果
业务验收	检查时间、关键功能结果、剩余问题

下载完成、容器重建和业务验收各有独立证据。把工单关闭在实际请求已使用修复运行时的位置，才能交接这次PHP安全更新。

事实核验：2026年10月21日22:01（北京时间）。依据PHP正式安全公告、两份官方漏洞公告与Docker CLI文档整理；发表前复核公告变化和目标镜像状态。