Laravel 10.x 无框架级邮件注入漏洞，问题源于开发者未校验用户输入；须严格验证邮箱、禁止用户控制邮件头、避免动态拼接内容、禁用 Mail::raw 接收用户输入。
Laravel 10.x 本身不直接存在“邮件注入漏洞”（Email Injection）的框架级缺陷，但开发者若不当拼接用户输入到邮件地址、主题或头信息中，就可能引发 SMTP 头注入（Header Injection）或收件人绕过等安全问题——这类问题常被统称为“邮件注入”，本质是不安全的输入处理，而非 Laravel Mail 组件的设计漏洞。
要真正修复，关键不是改框架，而是堵住你代码中可能被利用的入口点。以下是具体、可落地的防护措施：
✅ 严格校验和过滤收件人/发件人邮箱
不要直接将表单字段（如 request('to') 或 request('email')）传入 Mail::to() 或 Mailable 构造函数。
- 使用 Laravel 内置的
filter_var($email, FILTER_VALIDATE_EMAIL)做基础校验； - 更推荐用
Illuminate\Validation\Rule::email()或在 Form Request 中统一验证：
// 在自定义 Form Request 中
public function rules()
{
return [
'email' => ['required', 'string', 'email', 'max:255'],
];
}- 避免手动拼接
$message->to($userInput)，改用Mail::to($validatedEmail)—— 确保变量来自验证后数据。
✅ 禁止用户控制邮件头字段（Subject、From、Reply-To 等）
Laravel 的 Mailable 类中，subject()、from()、replyTo() 等方法接受字符串参数，若传入未过滤的用户输入，攻击者可能注入换行符（\r\n）伪造头信息，例如：
test@example.com%0D%0ABcc:admin@internal.com
→ 解码后变成：
test@example.com Bcc:admin@internal.com
修复方式：
- 所有头信息字段（尤其是
subject）必须做字符白名单过滤或长度+内容限制； - 推荐使用
Str::slug()或正则清理（仅保留字母、数字、空格、标点）：
use Illuminate\Support\Str;
$cleanSubject = Str::limit(
preg_replace('/[^\p{L}\p{N}\s.,!?-]/u', '', $request->input('subject')),
100,
'…'
);- 不要将用户输入直接用于
->from($request->email)；固定发件人（如noreply@yourdomain.com），用->replyTo($userEmail)代替。
✅ 不在 Mailable 的 build() 中动态拼接 HTML/Text 内容
避免这样写：
public function build()
{
return $this->view('emails.welcome')->with([
'content' => '<p>' . request('message') . '</p>', // ❌ 危险！XSS + 潜在头注入风险
]);
}- 应始终对用户提交的内容做输出转义：在 Blade 模板中用
{!! !!}前必须确认已净化，否则优先用{{ }}； - 如需富文本，用
html_entity_decode()+strip_tags()+Purifier（如mews/purifier）过滤<script>和危险属性。
✅ 禁用原始邮件构造（Mail::raw）接收用户输入
Mail::raw() 会跳过 Mailable 的安全封装，极易出问题：
Mail::raw(request('raw_content'), function ($m) { // ❌ 绝对禁止
$m->to('admin@example.com');
});- 删除所有类似用法；
- 替换为标准
Mailable类，并确保所有动态内容经验证、过滤、转义三重处理。
不复杂但容易忽略。
