我是真没想到，日本首相高市早苗竟然会在推特上提及 PHP 漏洞。虽说这和日本大多数服务都采用 PHP 有关，但这也足够出圈的了。
| CVE | 成因 | 修复版本 |
|---|---|---|
| CVE-2026-109618 | memory_limit 用 longjmp() 中断请求，OOM 时请求状态只初始化了一半，shutdown 阶段误释放未初始化内存 | 8.3.36 |
| CVE-2026-109619 | worker 全局状态在请求结束后未重置，下一个请求在初始化前就访问了已释放内存 | 8.3.36 |
事件扩散开来之后，全世界的运维都在忙着升级，我有几个网站是用 WordPress 搭的，自然免不了要升级一番。
如果是以前在系统上直接装的 LNMP，那么升级编译 PHP 得耗费不少时间，中间网站肯定是会中断的。但我已经将服务器上的 WordPress 容器化了，此次升级可以说是「非常轻松」，足以证明当初容器化改造的决定无比正确。
升级步骤
我的 WP 站点用 docker compose，PHP 镜像是 php8.3-fpm-alpine，我只跑了几条命令就完成了升级：
# 查看当前 PHP 容器版本，确认版本低于 8.3.36
docker exec php容器名 php -v
# 拉取新的镜像（关键，up -d 不会帮你拉）
docker compose pull php容器名
# 重建（--no-deps 避免连带重启 db）
docker compose up -d --no-deps php容器名
# 如果有多个站点
docker compose up -d --no-deps \
php容器1 php容器2 php容器3
# 再次验证容器里的 PHP 版本，必须看到 PHP 8.3.36
docker exec php容器名 php -v除了大陆拉取 Docker 镜像不太顺利，可能需要配置镜像源以外，其他体验都非常赞。这种几条命令就完成升级的感觉，真的会上瘾，再也不想回到过去那种费时又费力的维护工作了。
如果你的服务还没有容器化，可以找时间评估可行性。如果可以的话，耕读君建议也将其容器化，一次折腾、终身受益。
