PHP 8.3.36 是修复 CVE-2026-109618 和 CVE-2026-109619 的安全版本，二者属内核级远程代码执行漏洞，不依赖动态函数调用，而由 OOM 异常退出和全局状态残留引发，需确认真实生效、关闭 session.upload_progress 并清理遗留动态调用。
PHP 8.3.36 本身不是动态函数调用漏洞的成因，而是修复 CVE-2026-109618 和 CVE-2026-109619 的安全版本。所谓“动态函数调用漏洞”是常见误解——这两个漏洞不依赖于 call_user_func、eval、function_exists 等动态执行机制，而是在 PHP 内核处理请求时，由内存耗尽（OOM）或全局状态残留触发的底层 RCE，无需业务代码参与即可被利用。
所以问题核心不是“修复某个函数调用”，而是：你是否真的在运行 PHP 8.3.36？还是误以为升级到该版本就能自动解决所有动态调用风险？
确认你运行的是真实 PHP 8.3.36，而非“看起来像”
很多运维或 Docker 镜像存在版本“幻觉”：显示 php -v 是 8.3.36，但实际未生效或被覆盖。
- 检查 Web 服务器实际加载的 PHP 版本：
phpinfo()页面中 “Loaded Configuration File” 路径下的php.ini是否被重启后重载； - 确认 CLI 和 Web SAPI 使用同一套二进制：
which php与 Apache/PHP-FPM 进程中readlink -f $(which php)是否指向相同文件； - 某些发行版（如 Ubuntu）的
apt install php8.3默认安装的是旧缓存包，需先apt update并验证apt policy php8.3中候选版本是否为8.3.36； - Docker 用户注意：FROM php:8.3 默认拉取的是 latest tag，但官方镜像更新有延迟，应显式指定
FROM php:8.3.36-apache或FROM php:8.3.36-cli。
session.upload_progress 是关键攻击入口，必须显式关闭或加固
CVE-2026-109619 明确将 session.upload_progress 列为可利用路径，且该功能默认开启（session.upload_progress.enabled=On）。即使你升级到了 8.3.36，只要该配置仍启用，就仍在攻击面内——因为补丁只修复了状态残留逻辑，未禁用该功能本身。
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
- 最稳妥做法：在
php.ini或应用级配置中设为session.upload_progress.enabled=Off； - 若业务强依赖该功能（如大文件上传进度条），至少确保
session.use_strict_mode=1（防止会话 ID 被用户控制）和session.upload_progress.prefix使用随机前缀（避免预测会话键名）； - 检查所有
ini_set('session.upload_progress.enabled', '1')这类运行时开启调用，全部删除； - 注意：Nginx + PHP-FPM 场景下，该配置需在
php-fpm.conf或 pool 配置中用php_admin_value[session.upload_progress.enabled] = 0强制覆盖，避免被 .user.ini 绕过。
别把 disable_functions 当成救命稻草
这两个漏洞可在 disable_functions 生效前触发，官方已明确说明：“**没有能够完整替代补丁的配置缓解方案**”。实践中常见错误包括：
- 仅禁用
exec、system、shell_exec，却忽略pcntl_exec、proc_open等同样可用于派生进程的函数； - 在
php.ini中写了disable_functions = exec,system，但 Web 服务器使用了php_admin_value[disable_functions]覆盖，导致实际未生效； - 误以为禁用
eval就能防住所有代码执行——而本次漏洞根本不需要eval，它直接劫持 PHP 解释器自身的执行流程。
遗留项目里那些“看似安全”的动态调用仍要清理
虽然 CVE-2026-109618/109619 不靠 call_user_func 触发，但老项目中大量存在的动态调用仍是高危隐患，且可能被组合利用：
-
call_user_func($_GET['callback'])→ 改为白名单校验：in_array($_GET['callback'], ['json_encode', 'urlencode'], true)； -
include($_GET['page'] . '.php')→ 必须路径规范化+白名单映射，不能只靠basename()； -
unserialize($_COOKIE['data'])→ 替换为json_decode()，或使用__unserialize()+ 类白名单； - 所有
preg_replace('/.*/e', ...)（已被 PHP 7.3+ 移除）或mb_ereg_replace(..., 'e')必须彻底清除，它们在旧版本中等价于eval。
真正的难点不在“升到 8.3.36”，而在于确认它确实跑在所有请求路径上，且关键攻击向量（尤其是 session.upload_progress）已被切断。很多团队升级后仍被攻破，原因就是只改了版本号，没动配置、没查镜像、没审代码里的动态调用链。
