Frequently Reported Vulnerabilities

This page documents issues that are frequently reported in Logging Services software but are not considered vulnerabilities according to our threat model.

These reports often stem from valid concerns in specific contexts, but reflect common misunderstandings about how logging systems are designed to operate and what security guarantees they provide.

The goal of this FAQ is to:

  • Clarify common misconceptions

  • Explain why these reports fall outside our threat model

  • Help you make informed decisions when configuring logging

This document is not intended to dismiss security concerns, but to provide context and guidance. Depending on your environment, some of these topics may still warrant defensive configuration.

CWE-93: CRLF Injection

Apache Logging Services libraries (Log4cxx, Log4j, and Log4net) allow users to customize log output through a variety of layouts. A frequently reported issue is that CR (\r) and LF (\n) characters present in a log event can appear in the output, making it difficult to reliably delimit individual events when parsing.

In most configurations, this behavior is intentional and not considered a vulnerability within the defined threat model. The sections below cover the layouts for which this has most commonly been reported.

Pattern layout

Claim: Pattern layout is vulnerable to CRLF injection because it does not escape CRLF characters.

Pattern layout is an unstructured text format. It defines no fields, no delimiters, and no escaping rules, so it makes no attempt to neutralize control characters, including CRLF sequences. This means:

  • Log output will contain CRLF characters if they are present in the input.

  • The layout itself provides no output sanitization guarantees.

This behavior is by design and consistent with the layout’s purpose.

Why this is not a vulnerability

CRLF injection is a concern only when both of the following conditions apply:

  • Log output is consumed as structured data (for example, by an ingestion pipeline), and

  • Downstream consumers assume that the output has been sanitized.

Pattern layout guarantees only formatting, not safety or parseability. Tools such as Grok can parse Pattern layout output automatically, but only when the output consistently matches the expected pattern. Unescaped CRLF sequences can break that assumption.

If your logs are consumed in any of these ways:

  • Parsed automatically by a downstream tool

  • Ingested into a structured storage or SIEM system

  • Used in security-sensitive workflows

then avoid Pattern layout and use a structured layout instead, such as JSON or RFC 5424.

If you must use Pattern layout, sanitize all inputs explicitly, not just the log message. Common oversights include:

  • Sanitizing only %m (e.g. %enc{%m}{CRLF} in Log4j Core) while leaving other fields unescaped

  • The implicit %ex pattern specifier (exception stack traces), which are a frequent and overlooked source of CRLF characters

  • Seemingly "safe" values such as logger names, thread names, and log levels, which may contain unexpected data depending on your application

RFC 5424 layout

Claim: RFC 5424 layout is vulnerable to CRLF injection because it does not escape CRLF characters by default.

RFC 5424 layout is a structured format with well-defined fields and delimiters, enabling reliable and unambiguous parsing. However, per Section 8.2 of RFC 5424, the spec itself does not require escaping of control characters (including CRLF) in the PARAM-VALUE or MSG fields. Instead, responsibility for handling those characters is delegated to the transport binding in use.

For this reason, Log4j Core does not escape CRLF characters by default, and this is not considered a vulnerability.

Why this is not a vulnerability

The appropriate handling of CRLF characters depends on which transport protocol carries the log messages. RFC 5424 is used with several protocol bindings, each with different framing semantics:

UDP (RFC 5426)

Each message is transmitted as a self-contained datagram, so CRLF characters carry no special meaning and require no escaping.

TLS-encrypted TCP (RFC 5425)

The recommended transport for new deployments. Uses length-prefixed framing, so message boundaries are established independently of content. CRLF escaping is not required.

Legacy TCP (RFC 6587)

Uses LF as a message delimiter, so LF characters within a message must be escaped. This protocol is discouraged for new deployments due to known limitations.

Applying CRLF escaping unconditionally at the layout level would silently alter log content for transport bindings that do not need it. Defaulting to no escaping preserves the original log data while allowing each transport binding to apply the appropriate treatment.

RFC 5424 layout does support optional CRLF escaping, which you can enable explicitly when using a transport that requires it (such as legacy TCP over RFC 6587). Refer to the layout configuration reference for details.

If you are starting a new deployment, prefer TLS-encrypted TCP (RFC 5425), which avoids this concern entirely through length-prefixed framing.

CWE-35: Path Traversal

A frequently reported issue is the presence of unvalidated file paths in configuration files, such as file appender file names.

Claim: File appenders are vulnerable to path traversal because they accept unvalidated file paths.

Why this is not a vulnerability

Configuration files are trusted resources according to our threat model and must be protected accordingly. Given that trust, constraining the file paths they may contain provides no meaningful security benefit.

Limiting file paths to a specific directory would also introduce a chicken-and-egg problem: doing so would require an additional configuration resource to define the allowed directory, which itself would need to be trusted and protected. We do not establish a hierarchy of trust between configuration resources (environment variables, system properties, configuration files, and so on): they are all considered equally trusted.

Problematic contexts

While unvalidated file paths in configuration are not a vulnerability in themselves, they can become one when interpolation features (arbiters, lookups, etc.) are used to construct file paths dynamically.

This risk is compounded when interpolation occurs at runtime rather than at configuration time: for example, when appenders are created dynamically by Log4j Core’s Routing appender. In those cases, the interpolated values originate outside the configuration file itself and may originate from untrusted or attacker-controlled sources.

It is the user’s responsibility to ensure that the sources of any interpolated values used in file paths are trustworthy.

The trustworthiness of an interpolation source cannot be determined a priori by the Logging Services libraries, because it depends on the specific application and how it uses that source.

Consider ${ctx:…​} lookups as an example: some applications populate the thread context map exclusively with internally generated values (such as request IDs), while others may include user-provided data (such as HTTP headers). In practice, trustworthiness often varies even at the per-key level: some context map keys may be safe to use in file paths, while others may not.