php mail()函数易受头注入攻击，因其不校验参数直接拼接原始邮件头；攻击者通过注入\r\n可插入cc、bcc等新头或正文；须对$to、$subject及$additional_headers中所有用户输入严格过滤\r\n等控制字符。
PHP mail() 函数为什么会被头注入
因为 mail() 不校验参数内容，直接把传入的 $additional_headers 拼进邮件原始头里。攻击者只要在收件人、主题或自定义头字段里塞入 \r\n，就能强行插入新头（比如 Cc:、Bcc:、Subject:），甚至追加邮件正文。
典型触发点：用户提交的邮箱地址没过滤，直接拼进 To:；或从表单取值构造 From: 头时未清理换行符。
- 常见错误现象：
mail()发出多份邮件、收到“测试邮件”但自己没发过、日志里出现异常Cc: attacker@example.com - 关键原因：PHP 不对
$to、$subject、$additional_headers做任何转义，全靠开发者守门 - 注意：
mail()第二个参数$subject也参与头构造，含\r\n同样危险
怎么安全地构造 $additional_headers
不能拼接、不能信任用户输入。所有头字段必须单独生成，且逐个过滤换行符和控制字符。
- 用
str_replace()清除\r和\n：例如$clean_from = str_replace(["\r", "\n"], '', $_POST['from']); - 禁止用
addslashes()或htmlspecialchars()—— 它们不处理换行，且可能破坏邮件头格式 - 推荐组合：先
trim()，再str_replace()，最后用正则白名单收紧（如只留字母、数字、@、.、-） - 不要把多个头拼成一个字符串传给
$additional_headers；应统一用数组管理，再implode("\r\n", $headers)
替代方案：为什么建议跳过原生 mail()
原生 mail() 缺少内置防护、不可靠、难调试，且依赖本地 sendmail 配置。现代项目基本不该用它发用户邮件。
- 更安全的选择是
PHPMailer或symfony/mailer：它们默认对所有头字段自动转义，支持 SMTP 认证、DKIM 签名 - 如果必须用
mail()，至少封装一层：强制过滤所有头字段，拒绝含\r/\n的输入，并记录可疑请求 - 性能影响不大，但兼容性差——Windows 下
mail()基本不可用，而 SMTP 库跨平台一致
真实场景中容易漏掉的点
开发者常以为“只过滤 From 就够了”，其实所有可变头都得过一遍筛子，包括那些看似无害的字段。
-
Reply-To:、Return-Path:、X-Header:同样能被注入，别因名字带X-就放行 - 用户提交的昵称若用于
From: "昵称" <user></user>，引号内部分也要清理，否则"test\r\nCc: a@b.com"依然生效 - 用
mb_ereg_replace()替代str_replace()时，注意多字节编码下\r\n可能被拆开匹配失败
最麻烦的不是写过滤逻辑，而是记住：每个进入邮件头的字符串，不管来源多“可信”，都要当作潜在攻击载荷处理。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
