php邮件附件后门需先验证利用链再处置，常见于未过滤扩展名的mailparse解析漏洞，须检查上传目录可疑文件、扫描恶意函数、定位解析入口并修复白名单校验，否则删除无效。
PHP后门不是靠“删文件”就能解决的，尤其邮件附件触发的类型，往往已落地为隐蔽持久化后门（如写入wp-content、vendor/或伪装成日志文件），直接删错可能破坏业务或遗漏反弹连接点。
确认是否真有邮件附件触发的PHP后门
别急着删，先验证是否存在真实利用链。这类后门常见于：用户上传邮件附件（如.eml、.msg）后，服务端用mailparse或自定义解析器处理时，未过滤.php、.phtml等扩展名，导致附件内嵌脚本被保存并执行。
- 检查上传目录（如
uploads/、tmp/、wp-content/uploads/）是否有非图片/文档类文件：find /var/www -name "*.php" -o -name "*.phtml" -o -name "*.php5" 2>/dev/null | xargs ls -la - 重点看文件修改时间是否贴近某次邮件接收时间（
stat 文件名），以及是否属于www-data但无对应业务逻辑（比如wp-content/uploads/2024/06/xxx.php） - 用
grep -r "eval.*base64_decode\|system(.*\$_.*POST\|assert(" /var/www 2>/dev/null快速扫描可疑函数调用（注意：部分后门会用str_rot13或变量拼接绕过）
定位邮件附件解析入口点
后门能执行，说明解析逻辑存在缺陷。不修复入口，删完半小时就回来。
- 查邮件处理代码：搜索
mailparse_msg_parse_file、imap_body、fopen($_FILES、move_uploaded_file等调用，确认是否对$_FILES['attachment']['name']做过扩展名白名单校验（仅检查后缀不够，要校验finfo_fileMIME 类型） - 检查是否有临时解压/转存逻辑：比如收到
.zip附件后用exec("unzip -o ...")，且未限制解压路径——攻击者可构造../../../var/www/html/shell.php路径遍历 - 翻邮件队列日志（
/var/log/mail.log或应用层storage/logs/laravel.log），找附件名含.php但被成功入库/落盘的记录
安全删除 + 验证残留
删文件只是最后一步，重点是确认它没在内存、计划任务或数据库里留影子。
立即学习“PHP免费学习笔记（深入）”；
- 删除前备份可疑文件（
cp shell.php shell.php.bak），再用md5sum记录哈希，避免误删后无法溯源 - 检查
crontab -u www-data -l和/etc/cron.d/下是否有调用该PHP文件的定时任务 - 查数据库（尤其是
wp_options、settings表）是否存有base64编码的恶意payload，有些后门把核心逻辑存在数据库，文件只起加载作用 - 删完后，用
lsof -i :80 -a -p $(pgrep -f "php")确认Web进程没在读取已删文件（Linux下文件被进程占用时，rm只是unlink，内容仍在）
为什么删了还会回来？关键盲区在这儿
邮件附件后门最难缠的地方，是它常和合法功能耦合：比如CMS插件提供“导入邮件归档”功能，解析逻辑写死在vendor/某个第三方包里，你删了shell，但下次composer update又拉下来带漏洞的旧版本。
还有种情况是WebShell已获取数据库权限，通过SELECT ... INTO OUTFILE把自身重写进/var/www/html/.htaccess或index.php——表面删干净了，其实每次HTTP请求都在重建后门。
真正要盯住的，从来不是那个shell.php文件名，而是谁在调用它、它从哪儿拿到参数、它有没有能力改写其他文件。否则删十次，不如封一个mailparse函数调用点来得实在。
