上传一个头像，文件服务器返回了 WebShell 的解析访问路径。这不是漏洞段子，是文件上周某开源 CMS 被曝出的真实漏洞：攻击者把 PHP 代码塞进 GIF 文件的注释段，文件上传接口只检查了 Content-Type 和文件头，解析解压后直接落到 web 目录，漏洞解析器照单全收。文件

文件解析漏洞的解析本质，是漏洞“校验”和“执行”发生在两个不同的时间、由两套不同的文件逻辑处理同一个文件。上传模块觉得它是解析个图片，解析引擎觉得它是漏洞个脚本。两边各说各话，文件中间的解析缝隙就是攻击面。

后缀名那点事，漏洞比想象中复杂

Apache 的 mod_mime 模块有个特性：文件名里可以带多个后缀，它会从右往左依次匹配。你以为上传的是 shell.php.jpg，Apache 看到 .jpg 不认识，继续往左看，发现 .php——好，交给 PHP 处理。Nginx 更离谱，早期版本配置 fastcgi_split_path_info 时，shell.jpg/x.php 这种路径会让它把 .jpg 当脚本执行。IIS 6.0 的分号截断、Windows 的 ::$DATA 流，每个平台都有自己的“方言”。

这些不是理论。2013 年 Apache 那个 CVE-2013-4365，就是 .php. 结尾的文件被当成 PHP 解析，因为 mod_mime 会忽略末尾的点号。修复方式也简单粗暴——直接拒绝所有带多个点的文件名。但很多老系统没跟上。

解析器本身也会“认错人”

PHP 的 exif_imagetype() 读文件头两个字节，GIF89a 就认作 GIF。攻击者写个 GIF89a<?php system($_GET['c']);?> 就绕过了。更隐蔽的是 phar:// 反序列化——一个 .phar 文件伪装成 .jpg，用 file_exists() 检查时，PHP 会触发 phar 元数据的反序列化，直接执行恶意代码。这个漏洞在 2018 年 BlackHat 上被公开后，大量 CMS 中招，因为没人想到文件存在性检查会触发代码执行。

我见过一个真实案例：某在线考试系统允许上传 .docx 作为答题附件。后端用 Python 的 python-docx 解析，但解析前先调了 zipfile.is_zipfile() 做校验。攻击者构造了一个 ZIP 炸弹——解压后 4GB 的 .docx，服务器内存直接爆掉。文件解析漏洞不一定是代码执行，拒绝服务同样致命。

为什么这类漏洞总也修不完

开发者的直觉是“我检查了后缀名，应该安全了”。但解析器不这么想。PHP 的 move_uploaded_file() 只负责移动文件，不关心内容；Web 服务器只负责按后缀名分发，不关心来源。每个组件都做了自己该做的事，合在一起就出了事。

更麻烦的是，文件解析漏洞往往藏在“正常功能”里。图片裁剪、PDF 预览、Office 文档转换——这些功能都需要服务端解析用户上传的文件。解析器本身的漏洞（比如 ImageMagick 的 ImageTragick）、解析逻辑的缺陷（比如路径穿越）、解析后的文件落盘位置，任何一个环节出问题，整个防线就垮了。

我的判断是：只要用户能上传文件，解析漏洞就永远存在。防御思路不是“彻底杜绝”，而是“限制后果”——上传目录禁止执行权限、解析服务跑在沙箱里、文件落盘时重命名并剥离原始后缀、用 Content-Disposition: attachment 强制下载而非内联渲染。这些措施不优雅，但管用。

最后说个细节：很多 WAF 会拦截 .php 后缀的上传，但放行 .phtml、.php5、.inc。Apache 的 AddHandler 配置里，这些后缀可能都被映射到 PHP 解析器。攻击者不需要发明新漏洞，只需要找到你没配好的那一个后缀。