不能在运行中的Docker容器里升级PHP，必须更换基础镜像并重建容器；例如将php:8.2.30-apache改为php:8.2.35-apache，再构建运行；严禁在容器内用apt-get upgrade等命令修改，须验证版本、反序列化行为及错误日志，并同步检查框架与插件兼容性。
不能在运行中的Docker容器里“升级PHP”——这不是打补丁，而是换镜像。容器不可变，硬改会破坏一致性、埋下兼容隐患，还无法回滚。
核心操作：换基础镜像，重建容器
所有安全更新都依赖官方镜像同步。比如修复原生反序列化漏洞（CVE-2026-109618/19），PHP 8.2.30 需升至 8.2.35（发布于2026年10月20日）：
- 若用
Dockerfile：把FROM php:8.2.30-apache改成FROM php:8.2.35-apache，再docker build+docker run - 若用
docker-compose.yml：修改服务的image:字段，例如image: php:8.2.35-apache，然后执行docker-compose up -d --build - 不要用
apt-get upgrade php或类似命令进容器操作——这违反容器设计原则，且极易引发扩展缺失、路径错乱或权限异常
升级后必须验证的三件事
只改版本号不等于漏洞已修复，必须实测：
- 进新容器执行
php -v，确认输出含 8.2.35 且日期为 2026-10-20 或之后 - 构造恶意序列化字符串（如含
C:或自定义 gadget 类名），传给unserialize()——修复后应直接报Fatal error或静默失败，绝不能执行任意代码 - 检查 PHP 错误日志（
error_log或journalctl -u php-fpm），确认出现类似Serialization of 'Closure' is not allowed的拒绝提示
框架和插件也要同步检查
很多应用绕过底层限制，自己封装反序列化逻辑：
- WordPress：确认使用的是
wordpress:php8.2-apache或更高标签，并检查插件是否更新到兼容 8.2.35 的版本 - Laravel：查看
vendor/中是否有自定义反序列化调用，禁用或升级laravel/framework至 v10.42+（已适配该修复） - 任何手动调用
unserialize($_GET['data'])的代码，必须加白名单校验或改用json_decode
升级前临时缓解（仅限紧急兜底）
若因扩展兼容问题无法立刻切换镜像，可短期降低风险：
- 在
php.ini中设置unserialize_callback_func = ""，并确保__wakeup/__destruct不被自动触发 - 对所有用户输入的序列化数据，强制校验开头是否为
O:、a:、s:；拒绝含C:、O:24:"GadgetClass"等特征的字符串 - 禁用危险函数：
disable_functions = unserialize,eval,exec,passthru,shell_exec,system
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
