CVE-2026-34478: Log4j CRLF Injection Breaks the Trust Boundary in Syslog

CVE-2026-34478 is a Log4j Core vulnerability that can let attacker-influenced carriage returns and line feeds change the apparent boundaries of remotely transmitted log records. The underlying defect is unusually easy to underestimate: during a configuration API migration, several documented Rfc5424Layout attribute names stopped matching the names that affected Log4j releases actually recognized.

An administrator could therefore keep a configuration that looked correct, matched the documentation, passed deployment review, and allowed the application to start—while newline escaping or RFC 5425 framing was no longer operating as intended.

The result is not another Log4Shell. Apache has not described CVE-2026-34478 as remote code execution, JNDI injection, authentication bypass, or direct compromise of the Java process. Its primary risk is the integrity of the logging pipeline: one logical event can be made to resemble multiple Syslog records, fabricated records can enter downstream analytics, and security teams may make decisions from evidence whose boundaries have been influenced by an attacker.

Apache identifies Log4j Core versions 2.21.0 through 2.25.3 as affected, along with 3.0.0-beta1 through 3.0.0-beta3. Version 2.25.4 corrects the issue. Apache assigns a CVSS v4 score of 6.9 Medium, while NVD also publishes a CVSS v3.1 score of 7.5 High. Those labels come from different scoring versions and should not be treated as a contradiction or reduced to a single severity word. (NVD)

The operational question is not merely whether a software inventory contains an affected JAR. It is whether the application uses the affected layout, whether untrusted data reaches the message, whether the output crosses a stream-oriented transport, and whether the receiver can mistake embedded CRLF characters for record delimiters.

Technical Snapshot

フィールド	Practical answer
CVE	CVE-2026-34478
コンポーネント	Apache Log4j Core
Affected feature	Rfc5424Layout
Affected 2.x releases	2.21.0 through 2.25.3
Affected 3.x prereleases	3.0.0-beta1 through 3.0.0-beta3
Minimum fixed 2.x release	2.25.4
Apache CVSS v4	6.9 Medium
NVD CVSS v3.1	7.5 High
Weakness mappings	CWE-117 and CWE-684
Main input	CR, LF, or CRLF in attacker-influenced log content
Main failure	Documented security-related layout attributes are not recognized as intended
Main consequence	Forged record boundaries, misleading events, parser disruption, or loss of confidence in detection evidence
Direct SyslogAppender ユーザー	Apache states that they are not affected by this specific attribute incompatibility
Preferred remediation	Upgrade Log4j Core to 2.25.4 or a later maintained release and validate the actual wire format

NVD’s record maps the issue to improper output neutralization for logs and incorrect provision of specified functionality. Its CISA SSVC data, dated June 17, 2026, recorded exploitation as “none,” automatable as “yes,” and technical impact as “partial.” That entry is a dated assessment rather than a guarantee that no exploitation can occur or that defenders can ignore the vulnerability. (NVD)

What CVE-2026-34478 Is

At its core, CVE-2026-34478 is a delimiter-integrity vulnerability.

Applications usually perceive a log call as one event:

logger.warn("Authentication failed for user {}", suppliedUsername);

The receiving system may not see a Java method call, an object, or a structured event. It may see only a sequence of bytes arriving over a TCP connection. Something in the protocol must tell the receiver where one record ends and the next begins.

That boundary can be represented in several ways:

• A sender can prefix the record with its byte length.
• A sender and receiver can agree on a delimiter such as LF.
• A higher-level protocol can preserve message boundaries.
• A collector can apply multiline heuristics after receiving the stream.

If the selected boundary marker can also appear unescaped inside attacker-controlled message data, the receiver may be unable to distinguish data from structure. A newline that the application considers part of a username, URL, exception, or request field may be interpreted downstream as the end of the current record.

The next attacker-controlled bytes can then look like the beginning of another Syslog message.

This class of problem is captured by CWE-117. MITRE describes the weakness as a failure to neutralize special elements when writing logs, allowing attackers to forge or corrupt records, skew statistics, mislead interpretation, or interfere with automated processing. OWASP similarly advises neutralizing carriage returns, line feeds, and relevant delimiters before untrusted event data enters a logging format. (CWE)

The vulnerable application does not have to accept direct connections to its logging port. The attacker may only need control over something that the application records, such as:

• A username submitted to a login endpoint
• A User-Agent header
• A URL path or query parameter
• An API client identifier
• A failed validation value
• An exception message derived from an external response
• A message placed into a queue
• A tenant-controlled object name
• An MDC value populated from request context
• An email address, filename, or device label
• A remote service error copied into a local log message

This makes the trust boundary indirect. The attacker influences an application input; the application turns that input into a message; Log4j serializes it; the transport sends it; and a collector, parser, SIEM, or alerting system assigns meaning to the result.

CVE-2026-34478 sits at the serialization and transport boundary between those stages.

What CVE-2026-34478 Is Not

The vulnerability should not be described as a repeat of CVE-2021-44228.

Log4Shell involved Log4j message lookup functionality and JNDI behavior that could lead to remote code execution under affected conditions. CVE-2026-34478 concerns Rfc5424Layout, configuration compatibility, newline escaping, and message framing. Apache’s published description does not establish a path from this flaw to arbitrary Java execution. (Apache Logging Services)

It is also inaccurate to make any of the following assumptions without separate evidence:

• CRLF injection automatically gives an attacker access to the log server.
• An injected record automatically executes a command.
• Ignored useTlsMessageFormat configuration necessarily disables TLS encryption.
• Every application containing Log4j Core 2.21.0 through 2.25.3 is exploitable.
• Every Syslog deployment using an affected release is vulnerable.
• A forged line will be accepted identically by every collector.
• A successful injection will always be visible in the SIEM.
• A Medium score means the issue is operationally unimportant.
• A High score means every affected dependency requires an emergency internet-wide response.

The vulnerability’s practical impact is determined by the complete data path. In one deployment, an injected newline may be escaped by an upstream application layer and cause no observable change. In another, the receiver may store a malformed continuation line but refuse to interpret it as a new event. In a third, an attacker may generate a syntactically convincing second record that survives ingestion and changes an alert or investigation.

The same software defect can therefore produce different outcomes depending on configuration, receiver behavior, data sources, and the security function assigned to the logs.

How the Configuration Regression Was Introduced

The important historical detail is the migration of Rfc5424Layout configuration to a Builder implementation.

Apache’s fix pull request explains that Log4j 2.21.0 migrated the layout from a factory method to a builder. During that change, the names recognized by the implementation unintentionally diverged from the names documented for users. The later fix restored the documented names while preserving the names introduced during the migration as backward-compatible aliases. (ギットハブ)

The affected area included ordinary formatting options as well as attributes with direct security implications.

Documented attribute	Compatibility alias retained by the fix	目的
newLine	includeNL	Controls whether the serialized event ends with a newline
newLineEscape	escapeNL	Replaces newline characters found inside message content
useTlsMessageFormat	useTLSMessageFormat	Selects RFC 5425-style length framing
mdcIncludes	includes	Selects MDC keys included in structured data
mdcExcludes	excludes	Excludes selected MDC keys
mdcRequired	required	Identifies MDC keys expected to be present

The distinction between useTlsMessageFormat そして useTLSMessageFormat appears small to a human reviewer. It is not small to a configuration parser if only one exact plugin attribute is recognized.

The public GitHub issue that preceded the fix illustrates how the regression surfaced operationally. A user upgrading from Log4j 2.22.0 to 2.25.3 reported the following Status Logger message:

ERROR Rfc5424Layout contains an invalid element or attribute "newLine"

The user found that includeNL worked even though the documentation described newLine. The issue also noted that the breaking behavior was not reflected in the expected release documentation. (ギットハブ)

That example is useful for two reasons.

First, it shows that configuration warnings may have existed in affected deployments before the vulnerability received a CVE. Teams that collect Log4j’s internal status output may already have evidence pointing to an incompatible layout configuration.

Second, it demonstrates why “the service started successfully” is an insufficient security test. Logging systems frequently tolerate unrecognized attributes rather than terminating the entire application. Availability is preserved, but the operator’s intended safety property is not.

The fix was merged on March 24, 2026. Log4j 2.25.4 was released on March 28, and the CVE record was published on April 10. The release notes describe the restoration of documented Rfc5424Layout parameter names among a broader set of formatting and configuration corrections. (ギットハブ)

The Two Security-Relevant Failure Modes

Apache identifies two related ways in which the configuration incompatibility can undermine logging integrity.

Newline escaping silently stops working

The documented newLineEscape attribute tells Rfc5424Layout what replacement string to use when newline characters occur inside the message.

The official layout documentation describes newLineEscape as the string used to replace newline characters within the message. It separately documents newLine as the option controlling whether a newline is appended to the completed event. These are different controls: one handles message content, while the other affects record termination. (Apache Logging Services)

A simplified configuration may look like this:

<Rfc5424Layout
    appName="checkout-api"
    facility="LOCAL0"
    id="security"
    newLineEscape="\n"/>

An operator reading that configuration would reasonably expect line breaks inside the message to be rendered as visible escaped text rather than transmitted as control characters.

In affected releases, the documented name could be silently ineffective. The message might therefore contain raw CR, LF, or CRLF characters when it reached the output stream.

The security consequence appears when the transport or receiver treats a newline as a record delimiter. Instead of receiving one message whose text contains an unusual value, the collector may receive what appears to be two records.

The data flow can be summarized as follows:

The injected second line does not have to be perfect to cause damage. Depending on the receiver, it may:

• Become a fully parsed Syslog event
• Become a continuation event with inherited metadata
• Enter a fallback or unparsed index
• Cause the original event to be truncated
• Cause a parser to reject part of the stream
• Shift field extraction for later data
• Trigger a rule intended for another event type
• Reduce confidence in the surrounding evidence

RFC 5425 framing can be silently replaced by an unframed stream

Apache also states that the documented useTlsMessageFormat attribute was silently renamed. Users intending to use RFC 5425 framing could therefore be downgraded to an unframed RFC 6587-style TCP stream without newline escaping. (NVD)

The word “TLS” in the attribute name creates an important opportunity for misunderstanding.

This setting concerns the message format associated with Syslog over TLS, including length-based framing. Its failure does not, by itself, prove that the underlying socket stopped using encryption. A deployment can still have a TLS-protected connection while using an unexpected or unsafe application-level framing format.

The accurate description is therefore:

The configuration regression can cause a framing downgrade.

It should not automatically be described as:

The configuration regression disables TLS encryption.

Transport encryption, certificate validation, host verification, and message framing are related security controls, but they are not interchangeable.

A team validating CVE-2026-34478 should inspect both layers independently:

1. Transport security
   • Is the connection actually using TLS?
   • Is the certificate chain trusted?
   • Is the expected hostname verified?
   • Is the trust store appropriate?
   • Can the connection be redirected?
2. Message framing
   • Is each record preceded by an accurate octet count?
   • Does the receiver honor that count?
   • Are internal newlines escaped?
   • Does either side fall back to delimiter-based parsing?
   • Can one logical event produce multiple parsed records?

This distinction matters further because another Log4j vulnerability disclosed in the same release cycle, CVE-2026-34477, concerned an ignored hostname-verification configuration attribute in network appenders. A remote logging deployment could therefore require separate tests for encrypted transport, endpoint identity, framing, and content neutralization. Apache fixed both issues in 2.25.4. (Apache Logging Services)

Why TCP Does Not Preserve Log Record Boundaries

TCP provides an ordered stream of bytes. It does not tell the receiver that one application write equals one message.

Suppose an application sends two records:

record-one
record-two

The receiver might obtain them in one read:

record-onerecord-two

It might receive the first record across several reads:

rec
ord-
one

Or it might receive the end of the first record and the start of the second in the same read.

Correct framing must therefore be defined above TCP.

RFC 5424 defines the structure of a Syslog message, including fields such as priority, version, timestamp, hostname, application name, process identifier, message identifier, structured data, and message text. The protocol structure makes individual records interpretable, but a stream transport still needs a reliable method for determining how many bytes belong to each record. (IETFデータトラッカー)

RFC 5425 addresses Syslog over TLS and uses octet counting. A message is transmitted with a decimal length, a space, and then the exact number of bytes belonging to the Syslog message:

123 <134>1 2026-04-10T12:00:00Z host app 4242 AUTH - message bytes...

The receiver reads 123, consumes the following space, and then reads exactly 123 octets. A newline inside those 123 bytes is data rather than a boundary. RFC 5425 requires receivers to use the message length to delimit records. (IETFデータトラッカー)

RFC 6587 describes transmission of Syslog over TCP and discusses both octet-counting and non-transparent framing. In non-transparent framing, a trailer character—commonly LF—marks the end of the message. That design creates an ambiguity when LF is also permitted in the message content and is not escaped. (RFCエディター)

The issue can be expressed as a simple parsing problem.

A delimiter-based receiver may behave approximately like this:

for line in tcp_stream.split(b"\n"):
    parse_as_syslog_record(line)

If the sender produces:

<134>1 ... authentication failed for user alice
<134>1 ... authentication succeeded for user admin

the receiver sees two records. It cannot know whether the application intentionally emitted two events or whether the second line came from attacker-controlled data embedded in the first event.

Length-based framing instead behaves conceptually like this:

length = read_decimal_prefix()
read_one_byte_expected_to_be_space()
record = read_exactly(length)
parse_as_one_syslog_record(record)

The record can contain line breaks without changing its byte boundary, provided the sender calculates the length correctly and the receiver honors it.

Escaping remains valuable even with length framing. Downstream processors may later transform or re-export the message into delimiter-based formats, text files, terminals, CSV, or alert templates. Neutralizing control characters reduces the chance that ambiguity is reintroduced at another stage.

How a Log Injection Becomes a Detection Integrity Failure

Logging vulnerabilities are sometimes evaluated as if the only question were whether an attacker can make the text file look messy. Modern security pipelines assign far more authority to log records.

A record can determine whether:

• An account is locked
• A session is considered authenticated
• A transaction is escalated for review
• An IP address is blocked
• An incident receives a severity score
• A case is opened
• A response automation runs
• A user is reported as having changed a permission
• A control is considered operational
• An auditor accepts an activity trail
• Investigators reconstruct a sequence of actions

When an attacker can influence record boundaries, the vulnerability affects the assumptions behind those decisions.

Fabricated authentication outcomes

Consider an application that writes a warning after a failed login:

Authentication failed user=<supplied value> source=198.51.100.24

An attacker supplies a username containing CRLF followed by text that resembles a valid Syslog record:

alice<CR><LF><134>1 ... auth-service ... Authentication succeeded user=admin

The application made one failed-login log call. A vulnerable transport path might present two events to the receiver:

Authentication failed user=alice
Authentication succeeded user=admin

Whether the second event is fully accepted depends on the receiver’s syntax validation, field parsing, source attribution, and connection metadata. Even if it is not accepted as a perfect RFC 5424 record, it can still disrupt multiline processing or create an orphaned event.

The security impact is not that the attacker actually authenticated as an administrator. The impact is that the evidence may falsely say that such an authentication occurred.

This distinction is essential during response. An alert based on a forged record may still trigger disruptive containment, while an investigator who assumes every record is genuine may build the wrong attack timeline.

Corrupting thresholds and aggregations

Many detections do not operate on a single message. They aggregate:

• Failed logins per account
• Unique sources per identity
• Error rates per API route
• Privilege changes per session
• Administrative actions per tenant
• Transactions per device
• Denied requests before a successful request
• Security events per trace or correlation ID

Injected events can affect the numerator, denominator, grouping key, or event sequence.

For example, a rule may alert when five failed logins are followed by one success. A fabricated success event can create a false positive. An injected reset-like message can split a sequence and create a false negative. Additional benign-looking events can alter a statistical baseline.

A forged line does not need to bypass every field validation to matter. If the parser extracts only a timestamp, application name, event name, and username, those fields may be sufficient to affect a correlation query.

Polluting incident timelines

Investigators often sort records by event timestamps. An attacker-controlled second line may contain a fabricated timestamp earlier or later than the actual request.

This can make activity appear to have:

• Started before the attacker had access
• Occurred after containment
• Originated on a different host
• Been performed by a different service
• Followed a normal administrative action
• Happened outside the relevant retention window

Collectors may add an ingestion timestamp, but analysts sometimes prefer the event timestamp produced by the source. A comparison between source time and ingestion time can expose anomalies, yet not every investigation performs that comparison.

Manipulating source identity fields

RFC 5424 contains fields such as HOSTNAME, APP-NAME, PROCIDそして MSGID. If an injected line is parsed as a new event, the attacker may attempt to populate those fields with values associated with a trusted service.

A mature collector should bind events to transport-level metadata, authenticated certificates, known source addresses, or agent identities rather than trusting self-declared message headers alone. In practice, some pipelines preserve both sets of metadata, while others overwrite or normalize them.

That creates several possible outcomes:

• The attacker-controlled hostname is accepted.
• The collector replaces it with the connection source.
• Both values are stored in different fields.
• The event is routed based on the declared application name.
• The mismatch causes rejection.
• The event enters a generic parsing path.

Each outcome requires different detection logic.

Causing rejection rather than forgery

Not every useful attack needs to create a convincing fake event.

A malicious CRLF sequence can also produce malformed records that cause:

• Parser exceptions
• Partial batch rejection
• Dead-letter queue growth
• Unexpected multiline merging
• Truncation
• Field count errors
• Schema violations
• Index mapping failures
• Rate limiting caused by excess events
• Alert-processing delays

From a defender’s perspective, an availability problem in telemetry can be as important as a fabricated record. If an attacker can suppress or delay the logs needed to detect their activity, the pipeline’s security value is reduced even when no false event is accepted.

Damaging audit evidence

An audit log is useful only if its origin, order, content, and boundaries can be defended.

If a security team confirms that CVE-2026-34478 was reachable for a period, it should not automatically discard every event from that period. It should, however, record the limitation and identify which assertions require corroboration.

Evidence may be compared against:

• Reverse proxy access logs
• Identity provider events
• Database audit trails
• Cloud control-plane logs
• Endpoint telemetry
• Distributed traces
• Message queue records
• Local application logs
• Load balancer logs
• Packet captures
• Transaction databases
• Immutable object storage copies

The right conclusion is rarely “all logs are fake.” It is more often “the affected stream cannot independently prove record boundaries for attacker-influenced messages.”

Exposure Requires More Than an Affected Version

A dependency scanner can identify potentially affected Log4j Core releases. It cannot determine the entire exploit path.

A defensible exposure assessment should answer each of the following questions.

Question	なぜそれが重要なのか
Is log4j-core present at runtime?	The API package alone is not the affected component.
Is the runtime version between 2.21.0 and 2.25.3, or an affected 3.0.0 beta?	Other versions are outside the published affected range for this specific regression.
Is Rfc5424Layout instantiated directly?	The defect is specific to this layout configuration path.
Is Log4j’s SyslogAppender used instead?	Apache states that its users are not affected by this specific attribute incompatibility.
Is output sent over TCP or a TLS-protected stream?	Stream transports need explicit record framing.
Does the deployment expect RFC 5425 framing?	The ignored attribute may prevent the expected length-prefixed format.
Can untrusted data reach the message or relevant MDC fields?	Without an attacker-influenced value, practical injection risk is reduced.
Can that data contain CR or LF after application validation?	Upstream neutralization may prevent the dangerous bytes from reaching Log4j.
Does the receiver split records on newlines?	The parsing consequence depends on receiver behavior.
Does the receiver reparse injected data as RFC 5424?	A strict parser may reject input that a permissive parser accepts.
Are the logs security-critical?	Detection, audit, and response dependencies raise operational priority.
Are raw bytes retained?	Raw evidence makes validation and historical investigation more reliable.

A useful classification is:

Confirmed vulnerable path

A deployment is strongly exposed when all of the following are true:

• It runs an affected Log4j Core version.
• It directly uses Rfc5424Layout.
• It relies on one or both affected documented attributes.
• It sends logs over a stream-oriented network appender.
• Attacker-controlled content can contain CR or LF.
• The receiver uses delimiter-sensitive processing.
• A controlled laboratory test demonstrates that one log call creates multiple apparent records or otherwise corrupts parsing.

Potentially exposed path

The application uses an affected version and layout, but one or more runtime facts remain unverified. Examples include an unknown receiver framing mode, uncertain input normalization, or incomplete production configuration visibility.

This state should trigger testing, not an unsupported declaration that the vulnerability is exploitable.

Version-only finding

A scanner finds the affected JAR, but the application does not use Rfc5424Layout, or the logging path cannot be established.

The component still requires normal patch governance, especially because the same release range contains other corrected Log4j issues. The result should not be represented as a confirmed CRLF injection path.

Not affected by this CVE

例を挙げよう：

• Log4j Core 2.25.4 or later, assuming the deployed artifact is genuinely updated
• A version before 2.21.0, for this specific regression
• No use of Rfc5424Layout
• Exclusive use of the configuration path Apache explicitly identifies as unaffected
• No attacker-influenced content reaching the output
• An independently verified framing and escaping path that cannot be altered by the affected configuration behavior

“Not affected by this CVE” does not mean “secure against all Log4j vulnerabilities.” Older versions may carry unrelated and potentially more severe issues.

A Safe Local PoC for Understanding Record Splitting

The following demonstration is intentionally limited.

It does not connect to a remote host, scan a service, instantiate a vulnerable Log4j release, or provide an exploitation chain. It operates only on local Python strings and models the boundary problem that defenders need to understand.

The example assumes:

• One application log call
• A message containing controlled CRLF
• A sender that is supposed to replace newlines
• A receiver that splits a byte stream on LF
• A Boolean switch representing whether the configured escape is actually recognized

#!/usr/bin/env python3
"""
Local educational demonstration of delimiter collision.

This code does not use Log4j, open a network socket, or target any system.
It models how one logical message can become two apparent records when
CRLF characters remain unescaped in a newline-delimited stream.
"""

from dataclasses import dataclass


@dataclass(frozen=True)
class LabResult:
    serialized: bytes
    parsed_records: list[bytes]


def neutralize_line_breaks(message: str, replacement: str) -> str:
    """
    Replace CRLF first, then standalone CR and LF.

    The order matters because replacing LF first would leave the CR from
    a CRLF pair behind.
    """
    return (
        message
        .replace("\r\n", replacement)
        .replace("\r", replacement)
        .replace("\n", replacement)
    )


def serialize_event(
    message: str,
    *,
    configured_escape: str,
    escape_attribute_recognized: bool,
) -> bytes:
    """
    Build a harmless toy Syslog-like record.

    The Boolean simulates the difference between an intended configuration
    being applied and being silently ineffective.
    """
    if escape_attribute_recognized:
        safe_message = neutralize_line_breaks(
            message,
            configured_escape,
        )
    else:
        safe_message = message

    header = (
        "<134>1 2026-04-10T12:00:00Z "
        "lab-host auth-lab 4242 AUTH - "
    )

    return (header + safe_message + "\n").encode("utf-8")


def parse_newline_delimited_stream(stream: bytes) -> list[bytes]:
    """
    Model a simplistic receiver that treats LF as a record boundary.
    Empty trailing elements are removed for clearer output.
    """
    return [record for record in stream.split(b"\n") if record]


def run_case(recognized: bool) -> LabResult:
    controlled_message = (
        "login failed for user alice"
        "\r\n"
        "<134>1 2026-04-10T12:00:01Z "
        "lab-host auth-lab 4242 AUTH - "
        "login succeeded for user admin"
    )

    serialized = serialize_event(
        controlled_message,
        configured_escape=r"\n",
        escape_attribute_recognized=recognized,
    )

    return LabResult(
        serialized=serialized,
        parsed_records=parse_newline_delimited_stream(serialized),
    )


def print_result(label: str, result: LabResult) -> None:
    print(f"\n=== {label} ===")
    print(f"Raw bytes: {result.serialized!r}")
    print(f"Apparent record count: {len(result.parsed_records)}")

    for index, record in enumerate(result.parsed_records, start=1):
        print(f"Record {index}: {record.decode('utf-8', errors='replace')}")


def main() -> None:
    vulnerable_model = run_case(recognized=False)
    fixed_model = run_case(recognized=True)

    print_result(
        "Escape configuration not applied",
        vulnerable_model,
    )
    print_result(
        "Escape configuration applied",
        fixed_model,
    )


if __name__ == "__main__":
    main()

Expected behavior:

=== Escape configuration not applied ===
Apparent record count: 2
Record 1: <134>1 ... login failed for user alice
Record 2: <134>1 ... login succeeded for user admin

=== Escape configuration applied ===
Apparent record count: 1
Record 1: <134>1 ... login failed for user alice\n<134>1 ... login succeeded for user admin

The vulnerable model produces two apparent records because the receiver treats LF as structure. The fixed model produces one record because CRLF is represented as ordinary visible characters inside the message.

This PoC teaches four defensive lessons.

First, the dangerous behavior can arise without code execution. The receiver’s interpretation is the security boundary.

Second, the application’s number of log calls is not necessarily the collector’s number of events.

Third, inspecting a rendered SIEM event may hide the transformation. A UI may normalize line breaks, merge events, or omit raw bytes.

Fourth, testing should compare the full path:

Application call count
        versus
Serialized frame count
        versus
Collector raw record count
        versus
Parsed SIEM event count

The toy model is not proof that a particular production system is exploitable. A production finding requires an isolated reproduction using the organization’s actual Log4j version, configuration, appender, receiver, parsing policy, and data flow.

Finding the Affected Component in Real Applications

Java dependency visibility is rarely as simple as reading one pom.xml.

The runtime component may come from:

• A direct Maven dependency
• A transitive dependency
• A Gradle platform
• A vendor-provided application
• A shaded or fat JAR
• An application server shared library
• A container base image
• A manually copied JAR
• An agent or plugin
• A test dependency accidentally packaged into production
• A separately mounted runtime directory

Maven dependency inspection

From a Maven project:

mvn -q dependency:tree \
  -Dincludes=org.apache.logging.log4j:log4j-core

To include omitted conflict details:

mvn dependency:tree \
  -Dverbose \
  -Dincludes=org.apache.logging.log4j

The output should identify the selected runtime version rather than merely every version requested by every dependency.

For a packaged application, inspect the artifact itself:

jar tf target/application.jar \
  | grep -Ei 'log4j-(core|api).*\.jar|Log4j2Plugins\.dat'

Spring Boot and other executable JAR formats often place dependencies under directories such as BOOT-INF/lib.

jar tf target/application.jar \
  | grep 'BOOT-INF/lib/log4j-core'

Gradle dependency inspection

For Gradle:

./gradlew dependencyInsight \
  --dependency log4j-core \
  --configuration runtimeClasspath

A broader view can be obtained with:

./gradlew dependencies \
  --configuration runtimeClasspath

The first command is usually more useful because it explains why a particular version was selected.

Container and filesystem inspection

Inside a container image or extracted root filesystem:

find / \
  -type f \
  \( -iname 'log4j-core-*.jar' -o -iname '*log4j*core*.jar' \) \
  2>/dev/null

For an OCI image, teams can also inspect the software bill of materials generated by their approved container tooling. An SBOM is a useful starting point, but it cannot determine whether Rfc5424Layout is active or whether a remote receiver is delimiter-sensitive.

Confirming the loaded version

The version present in the source repository may differ from the version loaded by the running JVM. Where operational policy permits, teams can inspect:

• JVM startup classpaths
• Application diagnostic endpoints
• Java agent inventories
• Container filesystem layers
• Process-opened files
• Deployment manifests
• Build provenance
• Runtime dependency reports

A complete vulnerability ticket should distinguish among:

Declared dependency
Resolved build dependency
Packaged dependency
Deployed dependency
Loaded runtime dependency

Only the last two establish what the production application actually uses.

Locating Rfc5424Layout Configuration

Once the affected component is confirmed, search the effective configuration.

The configuration may be expressed as XML, JSON, YAML, properties, Java code, or a generated template. It may also be supplied through an environment-specific overlay that is absent from the main repository.

A broad repository search can begin with:

rg -n \
  --glob 'log4j2*.xml' \
  --glob 'log4j2*.json' \
  --glob 'log4j2*.yaml' \
  --glob 'log4j2*.yml' \
  --glob 'log4j2*.properties' \
  'Rfc5424Layout|newLineEscape|escapeNL|useTlsMessageFormat|useTLSMessageFormat|includeNL|Syslog|Socket'

Search all configuration-like files when naming conventions are inconsistent:

rg -n \
  'Rfc5424Layout|newLineEscape|escapeNL|useTlsMessageFormat|useTLSMessageFormat' \
  .

For deployed containers:

find /app /opt /etc \
  -type f \
  \( -name '*.xml' -o -name '*.json' -o -name '*.yaml' \
     -o -name '*.yml' -o -name '*.properties' \) \
  -print0 2>/dev/null \
  | xargs -0 grep -nE \
      'Rfc5424Layout|newLineEscape|escapeNL|useTlsMessageFormat|useTLSMessageFormat'

Review Java-based configuration as well:

rg -n \
  'Rfc5424Layout|newBuilder|setNewLineEscape|setUseTlsMessageFormat' \
  --glob '*.java' \
  --glob '*.kt' \
  .

The search result must be interpreted carefully.

Direct Rfc5424Layout use

A configuration such as the following deserves immediate review when paired with an affected release:

<Socket
    name="REMOTE_SECURITY_LOG"
    host="log-collector.internal.example"
    port="6514"
    protocol="SSL">

    <Rfc5424Layout
        appName="identity-api"
        facility="AUTH"
        id="security"
        newLineEscape="\n"
        useTlsMessageFormat="true"/>
</Socket>

Both security-relevant documented attributes appear, so a team should verify whether the affected runtime recognized them and what bytes were actually emitted.

SyslogAppender use

A configuration using Log4j’s SyslogAppender must be classified differently:

<Syslog
    name="REMOTE_SYSLOG"
    host="log-collector.internal.example"
    port="6514"
    protocol="SSL"
    format="RFC5424"
    appName="identity-api"
    facility="AUTH"/>

Apache explicitly states that users of SyslogAppender are not affected by CVE-2026-34478 because its configuration attributes were not modified by the relevant migration. (NVD)

That statement should prevent false positives for this specific issue. It should not prevent review of other vulnerabilities, including the neighboring TLS hostname-verification defect.

Generated and centralized configurations

In larger organizations, the repository may contain only a template:

logging:
  remote:
    enabled: ${REMOTE_LOGGING_ENABLED}
    format: ${REMOTE_LOGGING_FORMAT}

A deployment tool may generate the final Log4j configuration at startup. Reviewers should obtain the rendered file from the running environment rather than inferring behavior from the template.

Similarly, platform teams may inject appenders through:

• Kubernetes ConfigMaps
• Helm values
• Sidecar agents
• JVM system properties
• Spring configuration
• Environment variables
• Vendor-specific bootstrap scripts
• Shared application server settings

The effective configuration is the artifact that matters.

Identify Attacker-Controlled Data That Reaches the Log

A vulnerable layout is not enough. An attacker needs a way to introduce meaningful CR or LF characters into data that reaches the serialized event.

Map the input sources explicitly.

Input source	Typical logging path	Questions to test
HTTP request header	Access, authentication, or error log	Does the framework reject CRLF before application code?
URL parameter	Validation warning or business event	Is decoding performed before logging?
Username or email	Authentication and account logs	Are control characters allowed, normalized, or escaped?
API JSON field	Structured business event	可能 \r または \n become actual characters after JSON decoding?
Filename	Upload or malware-scanning log	Does the storage layer normalize the name?
Queue message	Consumer error log	Can an untrusted producer insert control characters?
External API error	Exception or integration log	Is the remote response copied verbatim?
MDC field	Request context and correlation	Does the layout encode MDC separately from free text?
Database value	Administrative or audit event	Was the value originally supplied by a tenant or user?
Device name	Fleet or IoT logs	Can managed devices choose arbitrary labels?

Do not assume that an HTTP server’s rejection of raw CRLF eliminates every path.

Control characters may enter through:

• JSON escape sequences decoded into actual newline characters
• Database values created through another interface
• Imported CSV or text files
• Message queues
• WebSocket messages
• gRPC string fields
• Unicode or platform-specific normalization
• Exceptions returned by downstream services
• Internal APIs with weaker validation
• Administrative interfaces
• Previously stored user content

The most reliable method is taint-style tracing:

External or tenant-controlled source
        |
        v
Parsing and decoding
        |
        v
Validation and normalization
        |
        v
Business object or request context
        |
        v
Message template or MDC assignment
        |
        v
Rfc5424Layout
        |
        v
Network appender
        |
        v
Collector and parser

Every transformation should be documented. A scanner that stops at “affected library found” does not answer this question.

Validate the Actual Wire Format in an Isolated Lab

Static analysis can identify risk conditions, but CVE-2026-34478 concerns runtime behavior. The strongest validation evidence is the serialized byte stream.

Use an isolated environment that reproduces:

• The exact application artifact
• The exact Log4j configuration
• The affected dependency version
• The same appender type
• A loopback or disposable receiver
• The relevant collector parsing mode
• A controlled message containing harmless CR, LF, and CRLF variants

Do not point the test at a production SIEM. A malformed test event may create false alerts, contaminate retention data, or trigger response automation.

Establish a control message

Generate a unique identifier:

TEST_ID="cve-2026-34478-$(date +%s)-$RANDOM"
printf '%s\n' "$TEST_ID"

Log one ordinary event containing that ID. Verify that:

• The application makes one log call.
• The sender emits one frame.
• The receiver stores one raw record.
• The parser creates one event.
• The unique ID appears once at each stage.

Send controlled newline variants

Use harmless laboratory values representing:

alpha\nbeta
alpha\rbeta
alpha\r\nbeta

After decoding, each should remain one logical event.

The acceptance condition is not merely that both words appear in the UI. The test should confirm:

• No additional record was created.
• No second RFC 5424 header was parsed.
• The raw byte stream uses the intended framing.
• CR and LF are neutralized according to policy.
• The event is not truncated.
• The receiver does not move part of the content into another index.
• Alert rules do not process the continuation as a separate event.

Inspect octet-counted framing

For RFC 5425-style output, a frame should begin with a decimal byte count followed by a space.

Conceptually:

156 <134>1 2026-04-10T12:00:00Z ...

A validation script can compare the prefix to the actual payload length:

#!/usr/bin/env python3

def validate_octet_counted_frame(frame: bytes) -> None:
    prefix, separator, payload = frame.partition(b" ")

    if separator != b" ":
        raise ValueError("Frame does not contain a length separator")

    if not prefix.isdigit():
        raise ValueError("Frame does not begin with a decimal length")

    declared = int(prefix)
    actual = len(payload)

    if declared != actual:
        raise ValueError(
            f"Length mismatch: declared={declared}, actual={actual}"
        )

    print(
        f"Valid frame: declared={declared}, actual={actual}"
    )


sample_payload = (
    b"<134>1 2026-04-10T12:00:00Z "
    b"lab-host app 4242 TEST - "
    b"controlled message"
)

sample_frame = str(len(sample_payload)).encode() + b" " + sample_payload

validate_octet_counted_frame(sample_frame)

For a continuous stream containing multiple frames, the parser must advance by the declared length rather than searching for the next newline.

Capture raw bytes

Approved tools may include:

tcpdump -i lo -s 0 -w log4j-rfc5424-lab.pcap \
  'tcp port 16514'

Use a nonprivileged test port such as 16514 and the loopback interface. Where TLS is enabled, packet capture alone will show transport behavior but not plaintext message contents. In that case, use:

• A laboratory collector that records bytes after TLS termination
• Application-side instrumentation
• A test trust store and disposable receiver
• Approved TLS key logging in a nonproduction environment
• A local proxy designed for test inspection

Do not disable production TLS or certificate verification merely to make a vulnerability test easier.

Compare pre-fix and post-fix behavior

A strong remediation record contains:

1. The affected dependency hash
2. The affected configuration
3. A controlled input
4. Raw output showing the unsafe behavior
5. The upgraded dependency hash
6. The corrected or confirmed configuration
7. The identical controlled input
8. Raw output showing one unambiguous frame
9. Collector evidence showing one parsed event
10. Test timestamps and environment boundaries

That evidence demonstrates that the security property was restored. A screenshot of a dependency scanner changing from red to green proves only that the scanner’s version rule changed.

Watch the Log4j Status Logger

The public issue associated with the regression reported an explicit invalid-attribute message for newLine. Similar configuration diagnostics are valuable canaries.

Search application startup output, container logs, and centralized platform logs for messages such as:

Rfc5424Layout contains an invalid element or attribute

A broad search may look like:

rg -n -i \
  'Rfc5424Layout.*invalid.*attribute|invalid element or attribute.*Rfc5424Layout' \
  /var/log \
  ./deployment-logs \
  ./support-bundles

In Kubernetes:

kubectl logs \
  --all-containers \
  --prefix \
  deployment/identity-api \
  | grep -Ei \
      'Rfc5424Layout.*invalid.*attribute|invalid element or attribute'

Historical CI output may also contain the warning:

rg -n -i \
  'Rfc5424Layout.*invalid.*attribute' \
  .github \
  build-logs \
  test-results

A matching warning is not, by itself, proof that CRLF injection occurred. It is evidence that the intended layout configuration may not have been applied.

Conversely, the absence of a warning does not prove safety. Status output may have been disabled, filtered, routed elsewhere, or discarded before collection. Configuration formats and plugin-building paths can also produce different diagnostics.

Treat Status Logger evidence as one layer in a larger validation process.

Detection Engineering for Possible Exploitation

Detection for log injection should combine producer-side truth, transport metadata, raw collector data, and parsed events.

A rule operating only on normalized SIEM records may be observing the attacker-influenced result rather than the original input.

Search for Syslog-like headers inside messages

A common suspicious pattern is a line break followed by text resembling an RFC 5424 header:

[\r\n]+<\d{1,3}>1\s

This pattern is only a starting point. A production detection should account for:

• Whether the platform preserves line breaks
• Whether the <PRI>VERSION sequence appears in a parsed message field
• Whether the collector has already split the event
• Expected applications that legitimately log embedded Syslog samples
• Escaped strings such as the literal characters \n
• Documentation, testing, and monitoring systems that store raw protocol text

A generic search concept is:

message contains newline
AND text after newline resembles "<PRI>1 timestamp hostname app-name"

This signal becomes stronger when the embedded header claims a different host, application, or process from the transport-authenticated source.

Compare producer counts with collector counts

Instrument the application or test harness with a unique event ID and count:

• Logging method invocations
• Frames emitted by the appender
• Raw records accepted by the collector
• Parsed events written to storage

A mismatch such as one invocation producing two parsed records is highly relevant.

In production telemetry, exact counts may be difficult because of retries, buffering, sampling, or loss. Correlation IDs can still reveal anomalies:

One request ID
One application operation
Multiple mutually inconsistent audit outcomes

Detect impossible event sequences

Useful integrity checks include:

• A failed and successful authentication for the same request ID
• A permission grant preceding the request that supposedly initiated it
• A logout without a corresponding session
• An administrative action from a process that never emits that event type
• A source hostname changing inside one authenticated collector connection
• An event timestamp outside the application instance’s lifetime
• A process identifier inconsistent with the sending service
• A message identifier not used by the declared application
• Multiple final transaction outcomes for one immutable transaction ID

These are not CVE-specific signatures. They are semantic controls that can detect several forms of telemetry tampering.

Track parser and ingestion failures

A failed forgery may still create telemetry loss. Monitor:

• Syslog parse errors
• Truncated event counts
• Invalid priority fields
• Invalid version fields
• Unexpected continuation lines
• Dead-letter queue volume
• Ingestion retry rates
• Collector connection resets
• Events routed to fallback indexes
• Schema rejection rates
• Sudden changes in multiline grouping
• Average events per connection write
• Differences between raw and normalized storage

Baseline these metrics by application and deployment version. A configuration regression introduced during a Log4j upgrade may appear as a structural change even before an attacker attempts to exploit it.

Retain transport-derived identity

Collectors should preserve metadata that the message cannot self-assert, such as:

• Source address
• Authenticated client certificate identity
• Collector listener
• Connection identifier
• TLS session metadata
• Ingestion timestamp
• Agent identity
• Original raw payload hash

Compare that metadata with RFC 5424 fields declared inside the message.

A message claiming to originate from payment-prod-01 is less trustworthy if it arrived over a connection authenticated to test-client-07.

Preserve raw evidence

Normalization improves searchability but can destroy the evidence needed to investigate delimiter attacks.

Where retention and privacy policies permit, preserve:

• Original bytes
• Original record boundaries
• Collector framing decisions
• Transformation history
• Parsed fields
• Parser version
• Pipeline configuration
• Hashes of raw and normalized records

A UI rendering that displays two clean events may conceal whether the source emitted two valid frames or one frame containing a newline.

Common Detection False Positives

Many legitimate events contain multiple lines. A rule that treats every newline as malicious will fail quickly.

Java stack traces

Exceptions commonly contain:

• A message line
• Multiple at lines
• Caused by sections
• Suppressed exceptions

A secure pipeline should preserve the stack trace as one event without allowing lines inside the trace to become independent Syslog records.

Multiline application messages

Developers may intentionally log:

• SQL formatting
• Validation summaries
• Configuration excerpts
• Email content
• Certificate details
• Diff output
• Template rendering failures
• Third-party response bodies

The presence of LF is not enough to prove injection. The important question is whether it crossed a trusted record boundary.

Literal escape sequences

The two bytes representing backslash and n are not an LF control character:

\n

A search engine or UI may render literal escapes and actual newlines similarly. Detection must inspect the underlying representation.

Collector multiline processing

Some collectors intentionally merge lines based on indentation, timestamps, or regular expressions. A second physical line may remain part of the first logical event.

That behavior can lower the chance of a successful forgery, but it may also hide evidence of unsafe sender behavior. The sender should still emit unambiguous frames.

Windows line endings

CRLF is normal in many text formats. The risk depends on whether the sequence is present inside an attacker-controlled field and how the receiver uses it.

Embedded protocol examples

Security tools, test frameworks, documentation systems, and network analyzers may legitimately log strings that begin with:

<134>1

Context is required. Signals such as mismatched transport identity, unexpected event type, attacker-controlled request values, and count discrepancies improve confidence.

修復

The preferred remediation is to upgrade Log4j Core to version 2.25.4 or a later maintained release.

Apache’s advisory specifically identifies 2.25.4 as the correcting release. Later releases may include additional security and reliability fixes, so teams should select an actively maintained version compatible with their Java runtime and application stack rather than treating 2.25.4 as a permanent ceiling. (NVD)

Upgrade the correct artifact

CVE-2026-34478 affects log4j-core.

Updating only:

org.apache.logging.log4j:log4j-api

while leaving an affected log4j-core at runtime does not remediate the vulnerable implementation.

Confirm dependency convergence:

mvn -q dependency:tree \
  -Dincludes=org.apache.logging.log4j

Or with Gradle:

./gradlew dependencyInsight \
  --dependency log4j-core \
  --configuration runtimeClasspath

Rebuild and redeploy the actual runtime artifact

A source-code dependency change does not prove that production changed.

検証する：

• Build cache invalidation
• Container image digest
• Application JAR contents
• Deployment rollout status
• JVM restart
• Shared library directories
• Sidecar and agent versions
• Rollback images
• Disaster-recovery artifacts
• Autoscaling templates
• Golden images
• Vendor patches

A restarted pod can still run the vulnerable JAR if the image tag was mutable or the package remained in an inherited layer.

Retest behavior after the upgrade

After deployment, repeat the controlled newline test and verify:

• The documented attributes are accepted.
• Internal CR and LF are neutralized according to policy.
• RFC 5425 framing is present where configured.
• The declared length matches the payload.
• One application event produces one receiver event.
• Status Logger no longer reports invalid layout attributes.
• The SIEM receives the expected fields.
• No new parser or schema failures appear.

Review neighboring Log4j issues

Log4j 2.25.4 corrected several security-relevant output and configuration problems. A team upgrading solely for CVE-2026-34478 should assess whether later versions are needed for additional fixes, including CVE-2026-49844, which addressed an incomplete JSON serialization fix in later Log4j branches. Apache’s current security page notes that the remaining MapMessage.asJson problem was fixed in 2.25.5 and 2.26.1. (Apache Logging Services)

This does not change the minimum fixed version for CVE-2026-34478. It does mean that version selection should consider the complete applicable vulnerability set.

Temporary Mitigations When an Immediate Upgrade Is Blocked

Temporary controls may reduce exposure, but they should not replace the upgrade.

Apache’s fix preserved the names introduced during the Builder migration as compatibility aliases. In affected versions, configurations may recognize aliases such as:

<Rfc5424Layout
    escapeNL="\n"
    useTLSMessageFormat="true"
    includeNL="false"/>

The fix tests identify aliases including escapeNL, useTLSMessageFormatそして includeNL, while restoring documented forms such as newLineEscape, useTlsMessageFormatそして newLine. (ギットハブ)

Using an alias can be a practical emergency measure only when all of the following are true:

• Upgrade timing is genuinely constrained.
• The exact affected release is known.
• The configuration is tested in the organization’s format.
• Raw output proves that escaping and framing work.
• The workaround is tracked as temporary debt.
• A removal date is tied to the upgrade.
• The post-upgrade configuration is retested.

Do not assume that changing a string in XML is sufficient. Configuration behavior can differ across XML, JSON, YAML, properties, programmatic builders, and generated templates.

Neutralize CR and LF before logging

Applications can encode or replace control characters before they reach the logging framework.

A Java helper may use a policy such as:

public final class LogNeutralizer {

    private LogNeutralizer() {
    }

    public static String oneLine(final String value) {
        if (value == null) {
            return null;
        }

        return value
                .replace("\r\n", "\\n")
                .replace("\r", "\\r")
                .replace("\n", "\\n");
    }
}

Usage:

logger.warn(
        "Authentication failed for user {}",
        LogNeutralizer.oneLine(suppliedUsername)
);

This is defense in depth, not a complete replacement for fixing the layout.

Consider the tradeoffs:

• Replacing control characters can reduce forensic fidelity.
• Applying the transformation inconsistently leaves gaps.
• Developers may forget to use the helper.
• MDC values and exception messages may follow different paths.
• Data may be logged by frameworks outside application code.
• A later renderer may decode escape sequences.
• Other format delimiters may also require encoding.

Centralized structured logging APIs are generally easier to enforce than scattered string replacements.

Avoid constructing pseudo-structured messages

This pattern is fragile:

logger.info(
    "event=login_failed user=" + username
    + " source=" + sourceAddress
);

Prefer typed fields where supported:

logger.atWarn()
    .withLocation()
    .log(
        "Authentication failed for user {} from {}",
        LogNeutralizer.oneLine(username),
        sourceAddress
    );

Or use an approved structured-message mechanism that keeps field names and values separate.

Structured fields still require safe serialization. The 2026 Log4j XML and JSON CVEs demonstrate that choosing XML or JSON does not eliminate output-encoding risk by itself.

Restrict untrusted values

Where business requirements allow:

• Reject CR and LF in usernames.
• Normalize device labels.
• Limit filename control characters.
• Cap message lengths.
• Avoid copying arbitrary upstream response bodies into security logs.
• Maintain an allowlist for identifiers.
• Store raw high-risk content separately from the primary audit message.

Validation should occur as close to the trust boundary as possible, but security logs should not depend solely on every upstream validator remaining correct.

Preserve an independent evidence source

During the temporary mitigation period, retain a second source that does not share the same vulnerable path.

例を挙げよう：

• Local append-only logs
• Cloud audit events
• Reverse proxy logs
• Identity provider logs
• Database audit records
• Distributed tracing
• Signed transaction records
• An independent agent using a different serialization path

This does not fix CVE-2026-34478. It reduces the chance that one compromised telemetry channel becomes the sole source of truth.

Secure Configuration After Upgrading

The exact configuration must match the organization’s Log4j version, receiver, certificate design, and operational standards. The following example illustrates the controls that deserve explicit validation after upgrading.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
    <Appenders>
        <Socket
            name="REMOTE_SECURITY_LOG"
            host="syslog.internal.example"
            port="6514"
            protocol="SSL"
            connectTimeoutMillis="5000"
            reconnectDelayMillis="5000">

            <Rfc5424Layout
                appName="identity-api"
                facility="AUTH"
                id="security"
                enterpriseNumber="32473"
                includeMdc="true"
                newLine="false"
                newLineEscape="\n"
                useTlsMessageFormat="true"/>

            <Ssl verifyHostName="true">
                <TrustStore
                    location="${env:SYSLOG_TRUSTSTORE}"
                    passwordEnvironmentVariable="SYSLOG_TRUSTSTORE_PASSWORD"/>
            </Ssl>
        </Socket>
    </Appenders>

    <Loggers>
        <Root level="info">
            <AppenderRef ref="REMOTE_SECURITY_LOG"/>
        </Root>
    </Loggers>
</Configuration>

The configuration expresses several independent intentions:

• protocol="SSL" selects a TLS-capable socket mode.
• verifyHostName="true" requires the remote certificate identity to match the expected host, assuming the fixed version and appropriate SSL configuration.
• newLineEscape="\n" represents internal newlines as visible text.
• useTlsMessageFormat="true" requests RFC 5425-style framing.
• newLine="false" avoids adding a delimiter that is unnecessary for length-framed records.
• The trust store is supplied outside source control.
• The receiver is identified by an internal hostname rather than an unverified arbitrary endpoint.

Each intention must be tested. A configuration file is a declaration, not evidence that the runtime honored it.

The Log4j network-appender documentation states that Socket Appender supports TCP, UDP, and optional TLS, and it provides examples combining a Socket Appender, Rfc5424Layout, and SSL configuration. It also warns that TCP and TLS writes do not provide application-level acknowledgment that the remote server durably accepted every event. (Apache Logging Services)

That reliability limitation is separate from CVE-2026-34478. Even a correctly framed and encrypted message can be lost after a socket write if the receiver closes the connection or fails before durable storage.

A secure design therefore considers:

• Framing
• Content neutralization
• Encryption
• Endpoint authentication
• Delivery acknowledgment
• Buffering
• Backpressure
• Retry behavior
• Duplicate handling
• Local fallback
• Raw retention
• Parser correctness

When SyslogAppender Is Used

Apache states that users of SyslogAppender are not affected by CVE-2026-34478 because its configuration attributes were not modified by the Builder migration responsible for the incompatibility. (NVD)

An example may look like:

<Syslog
    name="REMOTE_SYSLOG"
    host="syslog.internal.example"
    port="6514"
    protocol="SSL"
    format="RFC5424"
    appName="identity-api"
    facility="AUTH"
    includeMdc="true"
    newLine="false"
    newLineEscape="\n">
    <Ssl verifyHostName="true">
        <TrustStore
            location="${env:SYSLOG_TRUSTSTORE}"
            passwordEnvironmentVariable="SYSLOG_TRUSTSTORE_PASSWORD"/>
    </Ssl>
</Syslog>

The unaffected statement is specific to CVE-2026-34478. The deployment may still require an upgrade because CVE-2026-34477 affected hostname-verification configuration used with certain SMTP, Socket, and Syslog appender TLS setups before 2.25.4.

Do not close the ticket with “SyslogAppender found, no action” without assessing the applicable adjacent issues and the overall patch baseline.

Build Regression Tests Around Security Properties

CVE-2026-34478 is a strong example of a defect that ordinary unit and startup tests can miss.

The application starts. The logger produces output. The collector receives something. Only the intended security property—unambiguous record boundaries—has changed.

Regression tests should assert that property directly.

Test LF, CR, and CRLF separately

Use a matrix such as:

Input	Expected serialized behavior	Expected event count
alpha\nbeta	LF replaced or safely contained in a length frame	1
alpha\rbeta	CR replaced or safely contained	1
alpha\r\nbeta	CRLF treated as one controlled sequence	1
Literal alpha\\nbeta	Literal backslash and n preserved according to policy	1
Empty message	Valid frame with expected length	1
Non-ASCII text	Byte length calculated using encoded bytes	1
Long message	No truncation or unintended frame split	1

Non-ASCII input is particularly important for length framing. The frame prefix must reflect encoded octets, not Java character count.

例えば、こうだ：

"é"

may be one Unicode code point but more than one byte in UTF-8. A test that compares character count instead of byte count can approve an invalid frame.

Assert one call, one frame, one parsed event

The central invariant should be:

one intended audit event
equals
one serialized protocol frame
equals
one collector record
equals
one normalized event

Retries may complicate the equality in production, but a controlled integration test should make duplicates explicit rather than accepting unexplained count changes.

Capture Status Logger output

Fail the test when Log4j reports unknown or invalid configuration elements:

Rfc5424Layout contains an invalid element or attribute

This converts a warning that operators may overlook into a deployment-blocking signal.

Test every supported configuration format

If the product supports XML, JSON, YAML, and properties configurations, test each format used by customers or deployment environments. Plugin attribute mapping and case behavior should not be assumed identical without verification.

Test the real receiver

A sender-only unit test proves how Log4j serializes the event. It does not prove how the organization’s collector interprets it.

Include a disposable instance of the actual receiver or a protocol-compatible test double configured with the same framing mode.

Useful assertions include:

• The receiver accepts the frame.
• It creates one record.
• It preserves the unique test ID.
• It does not parse an embedded header as a new event.
• It records transport identity separately.
• It does not silently discard the message.
• It does not create a parser error.
• It does not normalize actual LF into a misleading display.

Run the test during dependency upgrades

Logging dependencies are often upgraded as routine maintenance. The regression that introduced CVE-2026-34478 demonstrates why configuration semantics should be tested during those changes.

A dependency-update pipeline can:

1. Build the application.
2. Start a disposable collector.
3. Send a test matrix.
4. Capture raw frames.
5. Validate octet counts.
6. Query parsed events.
7. Compare results with approved fixtures.
8. Fail on unknown configuration attributes.
9. Store artifacts with the build.

This turns logging security from a documentation assumption into a repeatable control.

Incident Response for Previously Exposed Deployments

Patching closes the future vulnerability path. It does not answer whether historical logs were affected.

A focused retrospective should begin with the first date an affected release and vulnerable configuration were deployed together.

Establish the exposure window

Collect:

• Deployment dates for Log4j 2.21.0 through 2.25.3
• Configuration change history
• Appender and receiver changes
• Collector parser upgrades
• Introduction dates for external input fields
• Dates when Status Logger warnings appeared
• Date and time of the fixed rollout
• Rollback events
• Disaster-recovery or canary environments that may have retained older versions

The exposure window may differ by service, region, tenant, or environment.

Preserve evidence before reprocessing

Before changing parsing rules or replaying logs, preserve:

• Raw collector files
• Original object-storage records
• SIEM exports
• Parser failure queues
• Local application logs
• Packet captures
• Configuration snapshots
• Container image digests
• Build artifacts
• Collector and parser versions

Reprocessing can improve searchability but may erase evidence of how the original pipeline split records.

Hunt for suspicious boundaries

Search for:

• RFC 5424-like headers beginning immediately after CR or LF
• Multiple events sharing one request ID but conflicting outcomes
• Hostnames inconsistent with transport metadata
• Unexpected APP-NAME or MSGID values
• Events with implausible source timestamps
• Orphaned lines beginning in message fragments
• Parser errors adjacent to high-risk requests
• Sudden event-count expansion for one application
• Security events lacking corresponding application actions
• Audit records that disagree with the system of record

No single pattern proves exploitation. Combine message evidence with the originating request or business operation.

Corroborate high-value events

Prioritize records that influenced:

• Privilege assignment
• Payment approval
• Identity verification
• Administrative changes
• Data export
• Secret access
• Account recovery
• Authentication decisions
• Incident containment
• Regulatory reporting

For each, compare independent sources.

A claimed privilege grant should correspond to an authorization database change. A claimed login should correspond to identity-provider and session records. A claimed transaction should correspond to the transaction ledger.

Mark evidence limitations precisely

Avoid broad statements such as:

All logs from January through March are invalid.

A more defensible statement is:

Remote RFC 5424 records produced by services A and B between the
deployment of Log4j Core 2.22.0 and the verified 2.25.4 rollout may
not independently establish record boundaries when message content
contains externally influenced CR or LF characters.

This identifies:

• The affected sources
• The time interval
• The technical condition
• The exact evidentiary limitation

Legal, audit, and compliance teams can then decide whether additional review is required.

Related Log4j Vulnerabilities

CVE-2026-34478 was disclosed alongside several vulnerabilities involving remote logging, output encoding, and downstream parser integrity.

CVE	Affected area	Core risk	Why it is relevant
CVE-2026-34477	SSL configuration for selected network appenders	Hostname verification configuration may be ignored under affected conditions	Remote log integrity also depends on authenticating the collector
CVE-2026-34478	Rfc5424Layout	CRLF injection and framing ambiguity	Record boundaries and detection evidence can be manipulated
CVE-2026-34479	Log4j1XmlLayout	XML 1.0 forbidden characters can produce invalid output	Malformed structured logs can be rejected or lost
CVE-2026-34480	XmlLayout	Insufficient handling of forbidden XML characters	Downstream XML parsers may reject events
CVE-2026-34481	JSON Template Layout	Non-finite numbers can create invalid JSON	Invalid structured output can create indexing gaps
CVE-2026-49844	MapMessage.asJson	Remaining non-finite number path after the earlier fix	Demonstrates why patch completeness and regression tests matter
CVE-2021-44228	JNDI message lookups	Remote code execution under affected conditions	A fundamentally different vulnerability class
CVE-2021-44832	JDBC Appender configuration	Code execution requiring high privilege to modify configuration	Shows that logging configuration can itself become an execution boundary

CVE-2026-34477 and remote endpoint trust

CVE-2026-34477 concerns a silent incompatibility affecting the verifyHostName SSL configuration attribute. Under the conditions in Apache’s advisory, selected network appenders could fail to apply the intended hostname verification, potentially allowing a certificate trusted by the configured trust store but issued for another hostname to be accepted.

Exploitation requires more than possession of an arbitrary self-signed certificate. The attacker would need a certificate accepted by the relevant trust configuration and the ability to intercept or redirect the connection. Apache fixed the issue in 2.25.4. (Apache Logging Services)

The issue is operationally related to CVE-2026-34478 because secure remote logging requires both:

• Confidence that the sender reached the intended collector
• Confidence that the collector received unambiguous records

A protected but incorrectly framed connection can carry forged boundaries. A correctly framed connection to the wrong endpoint can expose or alter the logs. Both layers must be tested.

For additional operational discussion of that neighboring issue, see Penligent’s analysis of CVE-2026-34477 and the Log4j remote logging trust boundary. The authoritative affected-version and remediation decisions should still be based on Apache’s security advisory.

CVE-2026-34479 and CVE-2026-34480

These vulnerabilities concern XML output rather than Syslog framing.

Apache describes cases in which Log4j layouts can emit XML containing characters forbidden by XML 1.0. A conforming downstream parser may reject the document, drop records, or cause the appender path to fail. The issue should not automatically be described as XML External Entity injection because the published flaw concerns output sanitization, not unsafe entity resolution. (Apache Logging Services)

The connection to CVE-2026-34478 is architectural: the logging framework sits between application data and a downstream parser. If it does not correctly encode data for the selected format, the downstream system may assign unintended structure or reject evidence.

CVE-2026-34481 and CVE-2026-49844

CVE-2026-34481 involved non-finite floating-point values such as NaN and infinity being emitted in a form that is not valid JSON under RFC 8259. Downstream conforming parsers can reject such output.

Apache later disclosed CVE-2026-49844 because the earlier fix did not cover every affected MapMessage JSON path. The remaining issue was fixed in 2.25.5 and 2.26.1. (Apache Logging Services)

The lesson is not that every formatting bug has the same severity. It is that security tests must validate the actual serialized result across all reachable code paths.

CVE-2021-44228

Log4Shell remains the comparison many readers will make when they see “Log4j CVE.”

The distinction is direct:

Property	CVE-2026-34478	CVE-2021-44228
Primary component behavior	RFC 5424 layout escaping and framing	JNDI lookup processing
Main published impact	Log injection and evidence-integrity risk	Remote code execution under affected conditions
Typical attacker goal	Manipulate or disrupt downstream interpretation	Cause the application to perform dangerous lookups and load attacker-influenced content
Main defensive validation	Configuration, serialized bytes, framing, collector parsing	Vulnerable lookup path, version, runtime controls, network behavior
Does fixing one fix the other	いいえ	いいえ

Calling CVE-2026-34478 “Log4Shell 2.0” would be technically misleading and would push teams toward the wrong tests.

Why Product-Level Advisories Matter

Open-source component advisories establish the upstream defect. Product advisories help identify where the component actually shipped.

For example, IBM published a June 11, 2026 bulletin stating that the Log4j 2 package included with IBM ApplinX was affected by a group of vulnerabilities including CVE-2026-34478 and had been updated. That bulletin does not prove every ApplinX deployment had a reachable CRLF injection path, but it demonstrates how the vulnerable component propagated into downstream products and why organizations must track vendor remediation as well as direct Maven dependencies. (IBM)

For third-party software:

• Check the vendor’s security bulletin.
• Identify the affected product releases.
• Follow the vendor-supported upgrade path.
• Do not replace bundled JARs manually unless the vendor supports it.
• Confirm whether the product actually enables the affected layout.
• Request configuration-specific exposure information when the bulletin is broad.
• Validate the patched product’s runtime version.
• Retain the vendor’s advisory and deployment evidence.

A product may contain the affected component but not use the vulnerable feature. Conversely, a vendor may use a generated configuration that is invisible to customers and therefore requires vendor confirmation.

Evidence-Driven Automated Validation

Automation is useful when it connects component inventory to configuration and runtime behavior.

A defensible workflow can:

1. Locate every deployed copy of log4j-core.
2. Determine the loaded version.
3. Search the effective configuration for Rfc5424Layout.
4. Identify affected documented attributes and compatibility aliases.
5. Trace attacker-controlled fields into messages and MDC.
6. Create an isolated test receiver.
7. submit controlled newline cases.
8. Capture raw pre-fix and post-fix frames.
9. compare application, frame, collector, and SIEM event counts.
10. attach commands, configurations, output, and remediation evidence to the finding.

The workflow should distinguish a version match from a verified vulnerability path. Otherwise, automation scales false certainty rather than security validation.

プラットフォーム 寡黙 can support authorized evidence collection and repeatable vulnerability validation when teams need to coordinate dependency inspection, configuration review, controlled testing, and report generation. For this CVE, the useful output is not merely “Log4j found.” It is a reproducible chain showing the version, active layout, controlled input, observed wire format, receiver behavior, and corrected result.

Human review remains necessary. A test system may normalize CRLF before the application receives it, a proxy may alter the request, or a collector may merge lines in a way that hides unsafe serialization. Automated conclusions should remain tied to observable evidence and explicit assumptions.

Remediation Checklist

優先順位	アクション	Evidence of completion
1	Identify runtime log4j-core versions	Runtime inventory, artifact hash, image digest
2	Find direct Rfc5424Layout use	Effective configuration and appender graph
3	Identify attacker-influenced message sources	Documented data-flow trace
4	Check Status Logger warnings	Startup logs and configuration diagnostics
5	Reproduce safely in an isolated environment	Raw frame and collector evidence
6	Upgrade to 2.25.4 or a later maintained release	Resolved dependency and deployed artifact
7	Verify escaping and RFC 5425 framing	Byte-level post-fix test
8	Confirm TLS and hostname verification separately	Certificate and connection validation
9	Review historical exposure	Time-bounded integrity assessment
10	Add CI regression tests	Automated one-call, one-frame, one-event assertions
11	Review adjacent Log4j CVEs	Complete applicable vulnerability matrix
12	Preserve remediation evidence	Ticket attachments, test artifacts, approval record

Frequently Asked Questions

Is CVE-2026-34478 another Log4Shell vulnerability?

• No. CVE-2026-34478 is a log-injection and message-framing issue in Rfc5424Layout.
• Apache’s advisory does not describe JNDI lookup exploitation or remote code execution for this CVE.
• Log4Shell, tracked as CVE-2021-44228, involved dangerous lookup behavior and a fundamentally different exploitation path.
• The main risk here is that attacker-influenced CRLF characters can alter how downstream systems divide and interpret log records.
• Defenders should validate serialization, framing, collector behavior, and evidence integrity rather than applying a Log4Shell-specific scanner and assuming the problem is resolved.

Is every application using Log4j 2.21.0 through 2.25.3 vulnerable?

• No. The affected version is only one prerequisite.
• The application must use the affected Log4j Core component and the relevant Rfc5424Layout configuration path.
• Practical injection also requires attacker-influenced content capable of carrying CR or LF into the serialized message.
• The consequence depends on the transport and receiver’s framing and parsing behavior.
• Apache states that users of Log4j’s SyslogAppender are not affected by this specific configuration incompatibility.
• A version-only scanner result should be classified as potential exposure until configuration and runtime behavior are verified.

How can I tell whether Rfc5424Layout is active?

• Search the effective runtime configuration for Rfc5424Layout, not only the source repository.
• Inspect XML, JSON, YAML, properties files, generated templates, Java builders, ConfigMaps, environment overlays, and shared application-server configuration.
• Search for related attributes such as newLineEscape, escapeNL, useTlsMessageFormatそして useTLSMessageFormat.
• Confirm which appender references the layout and whether that appender is enabled in the active environment.
• Review Log4j Status Logger output for invalid layout attributes.
• Run a controlled local event and inspect the raw output to confirm that the expected layout is actually producing the bytes.

Does ignored useTlsMessageFormat configuration disable TLS encryption?

• Not necessarily.
• The attribute controls the RFC 5425-oriented message framing format, including length-based record delimitation.
• TLS transport is configured separately through the socket protocol and SSL settings.
• A connection may remain encrypted while its application-level framing silently falls back to an unexpected format.
• Verify encryption, certificate trust, hostname validation, and message framing as separate controls.
• Do not describe the issue as an encryption downgrade unless a specific test proves that TLS itself was disabled.

Can a WAF or input filter fully mitigate CVE-2026-34478?

• A WAF may block some raw CRLF patterns in HTTP traffic, but it does not cover every input source.
• Newlines can enter through decoded JSON, message queues, stored database values, internal APIs, external error messages, filenames, device labels, or MDC fields.
• Proxies and frameworks may normalize input differently from the application.
• Input filtering also does not correct the underlying Log4j configuration behavior.
• Use validation and output neutralization as defense in depth, then upgrade the affected component and verify the serialized result.
• Do not rely on a generic CRLF rule as the sole remediation.

Is using escapeNL or useTLSMessageFormat enough instead of upgrading?

• The compatibility aliases may provide a temporary mitigation in affected releases when their behavior is verified locally.
• They do not remove the affected component or address other vulnerabilities fixed in later Log4j versions.
• The workaround can be lost during configuration generation, format conversion, or maintenance.
• A successful application startup does not prove that the alias produced safe wire output.
• Upgrade to 2.25.4 or a later maintained release as the durable correction.
• After upgrading, return to the documented names and retain regression tests that verify actual framing and escaping.

Should historical logs from an exposed system be considered untrustworthy?

• Do not assume that every historical event was forged.
• Identify the exact period in which an affected version and vulnerable configuration were active together.
• Determine which logged fields could contain attacker-controlled CR or LF.
• Preserve raw collector records before reprocessing or changing parsing rules.
• Hunt for embedded Syslog headers, inconsistent request IDs, impossible event sequences, and mismatches between message headers and transport metadata.
• Corroborate high-value events with identity, database, proxy, endpoint, cloud, or transaction records.
• Document the precise limitation: the affected stream may not independently prove record boundaries for attacker-influenced messages.

Closing Assessment

CVE-2026-34478 is a configuration regression with consequences beyond configuration hygiene. It weakens the boundary that tells a security system where one event ends and another begins.

The right response starts with accurate scoping. Confirm the runtime version, identify direct Rfc5424Layout use, trace untrusted data, inspect the framing mode, and reproduce the behavior in an isolated environment. Do not equate an affected JAR with a verified injection path, and do not dismiss the issue merely because it is not remote code execution.

Upgrade Log4j Core to 2.25.4 or a later maintained release, then prove that the fix restored the intended security properties. Internal CR and LF should be safely represented, RFC 5425 length framing should appear where configured, and one application event should remain one receiver event.

For systems that previously ran an exposed configuration, remediation should also include a bounded review of historical evidence. The goal is not simply to make a dependency scanner turn green. It is to reestablish a verifiable chain of trust from the application’s event, through serialization and transport, to the record that defenders use to make security decisions.