Email Injection in Axum with Cockroachdb

Email Injection occurs when user-controlled input is directly concatenated into email headers or commands, allowing an attacker to inject additional headers or commands. In an Axum application using Cockroachdb as the backend, the risk arises when developer code builds email-related data (such as recipient lists, reply-to addresses, or email templates) by interpolating request parameters into SQL statements or application logic without proper validation or parameterization.

Consider a scenario where an endpoint accepts a user-supplied email query parameter to customize a notification and directly includes it in a SQL INSERT or UPDATE statement targeting a Cockroachdb table that stores user contact preferences. Because Cockroachdb is PostgreSQL-wire compatible, Axum often interacts with it using PostgreSQL drivers (e.g., tokio-postgres). If the developer builds the query via string concatenation, an attacker can supply a value like test@example.com\r\nCC: attacker@example.com. Cockroachdb will accept the statement as valid SQL, and the injected header may be stored as data. Later, when the application retrieves the value and uses it in an email-sending routine (e.g., via an SMTP client or a mail-sending library), the injected header can alter routing, enabling spoofing, header injection, or unintended multi-recipient delivery.

Another vector involves log or audit tables in Cockroachdb where Axum records email-related events. If user input is concatenated into a log message without sanitization, an attacker can inject newline characters and additional text that, when exported or viewed in monitoring tools, can simulate email headers. While Cockroachdb itself does not interpret these values as SMTP commands, the stored payload becomes a source for downstream processing, where the injected content can trigger injection at the email composition layer.

Because middleBrick scans the unauthenticated attack surface and tests input validation, it can identify such injection risks by probing endpoints that accept email parameters and inspect how values are stored and later used. The scanner checks for unsafe consumption patterns and input validation weaknesses across the 12 checks, highlighting cases where attacker-controlled data may traverse from the database into email contexts without sanitization.

Remediation centers on strict input validation, parameterized queries, and isolating user data from protocol-level constructs. Below are concrete Axum examples using a PostgreSQL-compatible driver to interact with Cockroachdb safely.

1. Use parameterized queries for all SQL operations

Never interpolate user input into SQL strings. Use prepared statements with bound parameters. This ensures that data values are never interpreted as SQL or command syntax, regardless of content.

use axum::{routing::post, Router};
use tokio_postgres::{NoTls, Client};

async fn create_user_pref(client: &Client, user_id: i32, email: &str) -> Result<(), Box<dyn std::error::Error>> {
    // Safe: parameterized query
    client.execute(
        "INSERT INTO user_preferences (user_id, email) VALUES ($1, $2) ON CONFLICT (user_id) DO UPDATE SET email = $2",
        &[&user_id, &email],
    ).await?;
    Ok(())
}

// In your handler:
async fn handler(
    user_id: i32,
    email: String,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    let client = connect_to_cockroachdb().await.map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    create_user_pref(&client, user_id, &email).await.map_err(|e| (StatusCode::BAD_REQUEST, e.to_string()))?;
    Ok(Json("OK"))
}

2. Validate and sanitize email inputs before storage

Apply allow-list validation for email fields. Reject or normalize inputs containing newline, carriage return, or unexpected headers. This prevents stored values from being repurposed in email-injection contexts later.

use validator::Validate;

#[derive(Validate)]
struct EmailPreference {
    #[validate(email(message = "must be a valid email address"))]
    #[validate(length(min = 5, message = "email too short"))]
    email: String,
}

// In handler:
async fn handler(
    pref: Json<EmailPreference>,
) -> Result<impl IntoResponse, (StatusCode, String)> {
    pref.validate().map_err(|e| (StatusCode::BAD_REQUEST, e.to_string()))?;
    let client = connect_to_cockroachdb().await.unwrap();
    create_user_pref(&client, 1, &pref.email).await.unwrap();
    Ok(Json("Stored"))
}

3. Contextual output encoding when using data from Cockroachdb in email templates

If you retrieve values from Cockroachdb and use them in email generation (e.g., via a templating engine), ensure the templating context treats them as plain text, not as header or command injection surfaces.

use askama::Template;

#[derive(Template)]
#[template(path = "notification.txt")]
struct NotificationTemplate {
    recipient: String,
}

// Safe rendering: recipient is treated as plain text, not parsed as headers
fn build_email(recipient: &str) -> String {
    let tpl = NotificationTemplate { recipient: recipient.to_string() };
    tpl.render().unwrap_or_else(|_| String::from("Error rendering"))
}

4. Use environment-controlled mailers, not raw user input in command construction

When sending mail, rely on established libraries that separate headers from body. Avoid building mail commands or SMTP streams by concatenating stored database values directly.

use lettre::message::Mailbox;

fn send_notification(email_addr: &str) -> Result<(), lettre::transport::smtp::Error> {
    let from: Mailbox = "notifications@example.com".parse().unwrap();
    let to: Mailbox = email_addr.parse().unwrap();
    let email = lettre::Message::builder()
        .from(from)
        .to(to)
        .subject("Notification")
        .body(String::from("Hello"))?;
    // Send via SMTP transporter...
    Ok(())
}

These practices align with how middleBrick evaluates input validation and unsafe consumption: by checking whether attacker-controlled data can traverse into sensitive contexts. The scanner does not fix the code, but its findings map to OWASP API Top 10 categories and provide remediation guidance to help developers apply these patterns.