PHP 8.4.14 是当前最新稳定版（2025年10月23日发布），不包含文件上传后缀绕过修复，因该问题属业务逻辑缺陷而非PHP内核漏洞；正确防御需弃用$_FILES['name']后缀、服务端重命名、finfo校验内容、Web服务器禁用上传目录脚本解析。
PHP 8.4.27 并未发布，也不存在针对“上传文件后缀绕过漏洞”的专项修复。当前 PHP 官方最新稳定版是 PHP 8.4.14（发布于 2025 年 10 月 23 日），而 8.4.27 属于虚构版本号，无对应 CVE、补丁或 changelog。
PHP 本身不校验上传文件后缀
所谓“后缀绕过”，从来不是 PHP 解析器或 $_FILES 机制的漏洞，而是业务代码误用 $_FILES['xxx']['name'] 做唯一判断导致的逻辑缺陷。PHP 的 move_uploaded_file() 只关心临时文件路径是否合法、目标目录是否可写，完全不解析或验证原始文件名里的扩展名。
- 攻击者传
shell.php.jpg，服务端若只截取pathinfo($_FILES['f']['name'], PATHINFO_EXTENSION)得到jpg就放行，实际却保存为shell.php—— 这是业务层信任了不可信输入 -
$_FILES['f']['type']更不可靠，它来自 HTTP 请求头Content-Type，客户端可任意伪造 - PHP 的
getimagesize()或finfo_open()能识别真实文件类型，但必须主动调用，且仅用于内容检测，不能替代后缀白名单
真正有效的后缀控制必须在业务层实现
绕过问题的根因是“校验点错误”，不是 PHP 版本低。无论你用 PHP 7.4 还是 8.4.14，只要逻辑写错，一样被绕过。正确做法是：
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- **弃用
$_FILES['x']['name']中的后缀**：它只是客户端建议名，不具权威性 - **生成服务端可控的文件名**：如
uniqid() . '.' . $allowed_ext，后缀从白名单中严格选取 - **强制指定 MIME 类型与存储路径分离**：上传后立即用
finfo_open(FILEINFO_MIME_TYPE)检查内容，不匹配则拒绝保存 - **Web 服务器层拦截可执行后缀**：Nginx 配置中禁止
.php、.phtml等后缀在上传目录被解析，例如：location ~* ^/uploads/.*\.(php|phtml|phar|sh|pl|py)$ { return 403; }
为什么升级到 8.4.14 仍不能解决这个问题
PHP 8.4 系列的更新重点在语言特性（如属性钩子、readonly class）、JIT 稳定性（CVE-2026-44927/44928）、OPcache 优化和扩展行为修正（如 ext-phar 循环软链接修复），但从未、也不会介入应用层的文件上传策略。官方明确将文件校验视为“开发者责任”，而非运行时义务。
立即学习“PHP免费学习笔记（深入）”；
- 如果你依赖
is_uploaded_file()或move_uploaded_file()的返回值来判断“文件是否安全”，那是对函数语义的误解——它们只验证是否为本次上传的临时文件，不涉及内容或命名 - PHP 8.4.14 中
phar扩展修复的是phar_get_link_source()的无限递归崩溃（CVE-2026-7260），和上传后缀无关 - 所有声称“新版 PHP 自动过滤危险后缀”的说法，都混淆了 Web 服务器配置、框架中间件和 PHP 内核的职责边界
最易被忽略的一点：即便你做了完整校验，若上传目录恰好有 .htaccess 文件允许解析 .jpg 为 PHP（或 Nginx 的 fastcgi_split_path_info 配置错误），后缀白名单依然形同虚设。防御必须贯穿文件存储、Web 服务、操作系统三层面，不能指望一个版本号包打天下。
