Email Injection in Fiber with Basic Auth

Email Injection in a Fiber application protected by Basic Auth occurs when user-controlled data is passed into email-related operations without proper validation or encoding, and the authentication layer does not prevent or detect manipulation of email headers. While Basic Auth secures the HTTP request with a username and password, it does not sanitize inputs that eventually reach mail servers or libraries. In Go Fiber, routes that accept user input for email headers or message fields—such as recipient, subject, or reply-to—can become injection points if the input is concatenated into raw email text or passed to an email library that interprets control characters like newline (\n) and carriage return (\r).

For example, consider a handler that builds a message using user-supplied fields without sanitization:

app.Post("/notify", func(c *fiber.Ctx) error {
    type RequestBody struct {
        Email string `json:"email"`
        Name  string `json:"name"`
    }
    var body RequestBody
    if err := c.BodyParser(&body); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid body"})
    }
    // Unsafe concatenation
    msg := "To: " + body.Email + "\nFrom: web@example.com\nSubject: Notification\n\nHello " + body.Name
    // Passing msg to an external mailer
    return c.JSON(fiber.Map{"message": "queued"})
})

If body.Email contains a newline such as attacker@example.com\nCC: victim@example.com, the resulting message may send copies to unintended recipients. Because Basic Auth only validates credentials and does not inspect or sanitize the request body, this header injection remains effective. Attackers can use this to spoof sender identity, send emails to hidden recipients, or perform phishing via compromised headers. The presence of Basic Auth may also give developers a false sense of security, leading them to overlook input validation in trusted-authentication contexts.

Additionally, if the application exposes an endpoint that accepts dynamic email templates or uses reflection to map JSON fields to mail headers, the risk increases. An OpenAPI spec with loose parameter definitions can unintentionally document or encourage accepting header fields that should be server-controlled. middleBrick’s OpenAPI/Swagger spec analysis would flag such risky endpoints by cross-referencing runtime behavior with spec definitions, identifying places where user input reaches mail-sending functions without strict allowlists.

In LLM-related endpoints, Email Injection can also manifest through prompt or output handling. For instance, if an API endpoint that integrates with an LLM copies user email input into system or assistant messages without escaping, it may enable prompt injection or header-like manipulation in downstream AI workflows. middleBrick’s LLM/AI Security checks specifically test for such leakage and injection paths, detecting cases where user data can influence prompts or outputs in ways that bypass intended constraints.

Because Email Injection relies on control characters to alter message routing, the vulnerability is protocol-level and not prevented by transport-layer protections like TLS. Even with Basic Auth ensuring only known users reach the handler, the application must enforce strict validation, avoid direct concatenation, and treat all user input as potentially malicious.

To remediate Email Injection in Fiber when using Basic Auth, ensure that any user-controlled data used in email headers is strictly validated, encoded, or replaced with server-side values. Basic Auth should continue to handle authentication, while the application layer must implement defense-in-depth for email construction.

Use allowlists for email formats and reject inputs containing control characters. For example:

import ("net/mail" "net/smtp" "strings")

func isValidEmail(email string) bool {
    _, err := mail.ParseAddress(email)
    return err == nil
}

app.Post("/notify", func(c *fiber.Ctx) error {
    type RequestBody struct {
        Email string `json:"email"`
        Name  string `json:"name"`
    }
    var body RequestBody
    if err := c.BodyParser(&body); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid body"})
    }
    if !isValidEmail(body.Email) {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid email address"})
    }
    // Safe construction: avoid concatenation of user input into headers
    msg := &smtp.Mail{ 
        // Use server-controlled or sanitized values
        Header: map[string][]string{
            "To":       {body.Email},
            "From":     {"web@example.com"},
            "Subject":  {"Notification"},
            "Reply-To": {"web@example.com"},
        },
        Body: strings.NewReader("Hello " + body.Name + ", this is a notification."),
    }
    // Passing structured mail object to a safe mailer prevents header injection
    return c.JSON(fiber.Map{"message": "queued"})
})

In this approach, mail.ParseAddress validates the email format and rejects strings containing newlines or unexpected headers. The email header fields are set explicitly by the server, not concatenated from user input, which prevents attackers from injecting additional headers such as CC, BCC, or Subject overrides. The Basic Auth middleware remains responsible for credential checks, while this handler focuses on safe data usage.

For applications that must reflect user input in headers, apply strict encoding: replace \n and \r and enforce a single email recipient per message. Avoid using reflection or dynamic header mapping unless the input domain is rigorously constrained. middleBrick’s CLI can be used in scripts to verify that no newline characters remain in email fields before deployment:

echo '{"email": "user@example.com\\nCC: attacker@example.com"}' | middlebrick scan http://localhost:8080/notify

While this command does not prevent the vulnerability, it helps identify risky patterns during testing. For ongoing protection, combine Basic Auth with robust input validation and server-controlled headers, ensuring that user data never directly shapes protocol-level metadata.