PHP 8.4.27 不修复文件上传漏洞，因其属业务逻辑问题；必须手动加固：1. 用 finfo_file() 校验 MIME；2. 重命名并存至 Web 根目录外；3. 禁用上传目录 PHP 执行；4. 检查 open_basedir、disable_functions 和 upload_tmp_dir 配置。
PHP 8.4.27 本身不“修复”文件上传漏洞——它只是消除了 CVE-2026-109618 和 CVE-2026-109619 这两个远程代码执行漏洞，而文件上传漏洞属于业务逻辑层问题，与 PHP 版本无关。即使你已升级到 8.4.27，只要上传处理逻辑存在缺陷（如仅校验扩展名、未重命名、目录可执行），攻击者仍能上传 WebShell 并执行任意代码。
为什么升级到 PHP 8.4.27 后文件上传还是不安全？
PHP 版本升级解决的是解释器层面的 RCE 漏洞（比如通过恶意 Phar 触发内存越界），但不会自动加固你的 $_FILES 处理逻辑。文件上传漏洞本质是开发者未实施纵深防御：没有白名单校验、未剥离文件内容头、未禁用上传目录的脚本执行权限等。这些必须手动编码实现，和 PHP 版本号无直接关系。
PHP 8.4.27 环境下必须做的 4 项上传加固
在确认已运行 8.4.27 的前提下，以下操作缺一不可：
- 用
finfo_file()替代$_FILES['file']['type']做 MIME 类型校验——后者完全由客户端控制，可轻易伪造 - 上传后立即重命名文件，丢弃原始
$_FILES['file']['name']；推荐用bin2hex(random_bytes(16)) . '.jpg'格式 - 将文件保存到 Web 根目录之外（如
/var/www/uploads/），并通过代理脚本（非直接 URL 访问）提供下载 - 确保上传目录的父级目录（如
/var/www/uploads/）对 Web 进程用户（如www-data）仅有755权限，且 Apache/Nginx 配置中显式禁止该路径下执行 PHP：<Directory "/var/www/uploads"> php_flag engine off </Directory>
容易被忽略的 PHP 8.4 配置陷阱
PHP 8.4 默认启用 zend.assertions = -1（生产模式关闭断言），但这不影响上传逻辑；真正危险的是遗留配置：
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
-
open_basedir若未限制，攻击者可能通过路径遍历写入/var/www/html/shell.php -
disable_functions中若漏掉shell_exec,system,passthru,exec，上传的 PHP 文件一旦被执行，后果严重 -
upload_tmp_dir若设为 Web 可访问路径（如/var/www/html/tmp），临时文件可能被直接请求并解析
检查方式：运行 php -i | grep -E "(open_basedir|disable_functions|upload_tmp_dir)"，确认值符合预期。
最常出问题的地方不是版本够不够新，而是上传后的文件是否还能被 Web 服务器当 PHP 执行——只要这个没堵死，8.4.27 也救不了你。
