CVE-2023-6378

What it actually does

This vulnerability affects the Logback receiver component in Logback 1.4.11. A network-accessible receiver that accepts serialized logging events can be sent specially crafted serialized data that triggers unsafe or expensive deserialization behavior, causing the receiving Java process to hang, crash, exhaust memory/CPU, or otherwise become unavailable. The impact is availability-only under the published assessment: no confidentiality or integrity impact is indicated, and exploitation requires no authentication, user interaction, or high attack complexity if the receiver is reachable.

Why it matters to the business

Applications or logging infrastructure using the vulnerable Logback receiver can be disrupted remotely, potentially causing application outages, degraded observability, missed operational alerts, or cascading instability if critical services depend on the affected Java process. Although it is not listed in CISA KEV, has no known ransomware association, and has a low EPSS score, the flaw is remotely reachable when the receiver is exposed and has a high availability impact, so internet-facing or broadly accessible receiver deployments should be prioritized.

How an attack unfolds

An attacker first identifies a Java service or logging endpoint running Logback 1.4.11 with the receiver component enabled and reachable over the network. The attacker then opens a connection to the receiver port and sends malformed or intentionally hostile serialized data instead of a valid Logback logging event. The receiver attempts to deserialize or process the data, triggering the vulnerable behavior. Depending on process limits and deployment design, this can lead to excessive resource consumption, unhandled exceptions, thread exhaustion, JVM instability, or repeated service restarts. The attacker can repeat the connection attempts to keep the service unavailable or to amplify operational impact.

How to fix it

Upgrade Logback to a fixed release that includes the upstream fix for the receiver serialization issue. For source-based builds, ensure the code includes qos-ch/logback commit 0df4ec15d45301b5d0a6e2de6466a17944c3a871 or a later trusted release containing that change; where possible, move off Logback 1.4.11 to the latest supported 1.4.x or newer version. If immediate upgrade is not possible, disable the Logback receiver component, remove remote logging receiver configuration, bind receiver listeners only to localhost or a private management network, restrict access with firewall/security-group rules, and enforce strict network allowlists for any systems that must send logs. Do not expose Logback receiver ports directly to the internet.

How to confirm the fix worked

Confirm that no deployed artifact contains Logback 1.4.11 receiver code by inspecting dependency manifests, SBOMs, container images, application build files, and runtime classpaths for logback-classic/logback-core versions. Verify that the deployed Logback build includes commit 0df4ec15d45301b5d0a6e2de6466a17944c3a871 or a later fixed release. Review Logback configuration for receiver classes and confirm they are disabled or access-controlled where not required. From a network perspective, verify that receiver ports are not exposed externally and are reachable only from approved log producers. After patching or disabling the receiver, run service health checks and controlled negative testing with malformed serialized input in a non-production environment to confirm the process remains stable.

Typical attack path

1. Discover a network-accessible Logback receiver endpoint, commonly through service enumeration, application configuration leakage, or scanning for open listener ports used for remote logging.
2. Confirm that the target appears to accept serialized Java/logging traffic or behaves like a Logback receiver.
3. Send crafted serialized payloads or malformed Java serialization streams to the receiver.
4. Cause the receiver process to spend excessive resources, throw repeated deserialization exceptions, crash, or stop accepting legitimate logging events.
5. Repeat the traffic to sustain denial of service or to disrupt dependent applications and monitoring workflows.

How to detect it

To determine whether this was already exploited, review application logs, JVM logs, container orchestration events, process supervision logs, EDR telemetry, and network telemetry for affected Java services. Focus on periods with unexplained application restarts, high CPU or memory use, out-of-memory errors, thread exhaustion, or dropped logging/monitoring events. Look for repeated inbound connections to Logback receiver ports from unexpected sources, especially traffic beginning with Java serialization magic bytes or followed by deserialization exceptions. In application logs, search for Java serialization and Logback receiver errors such as StreamCorruptedException, InvalidClassException, OptionalDataException, EOFException, ClassCastException, ObjectInputStream failures, and receiver/server socket exceptions. In infrastructure logs, correlate suspicious inbound connection bursts with JVM crashes, Kubernetes CrashLoopBackOff events, systemd restarts, container OOMKilled events, or load balancer health-check failures. Absence of these artifacts does not prove non-exploitation, because a successful denial-of-service attempt may leave limited application-level evidence if the process terminates abruptly.

• logback-classic-1.4.11.jar
• logback-core-1.4.11.jar
• ch.qos.logback.classic.net.server.ServerSocketReceiver
• ch.qos.logback.classic.net.SocketReceiver
• ch.qos.logback.classic.net.server.RemoteAppenderStreamClient
• java.io.StreamCorruptedException
• java.io.InvalidClassException
• java.io.OptionalDataException
• java.io.EOFException
• java.io.ObjectInputStream
• OutOfMemoryError
• java.lang.OutOfMemoryError
• CrashLoopBackOff
• OOMKilled
• aced0005
• AC ED 00 05

What your security team should do

• Inventory Java applications, containers, and logging services for Logback 1.4.11, especially deployments using receiver or remote logging functionality.
• Prioritize remediation for internet-facing, DMZ, shared platform, or business-critical services where receiver ports are reachable by untrusted networks.
• Upgrade to a fixed Logback build containing commit 0df4ec15d45301b5d0a6e2de6466a17944c3a871 or a later supported release; rebuild and redeploy all dependent applications rather than only updating source repositories.
• Disable Logback receiver components where they are not explicitly required, and replace unauthenticated serialized-log receivers with safer logging transport patterns where feasible.
• Add network controls so receiver ports are reachable only from approved log producers; block public access and broad east-west access.
• Search historical logs for deserialization errors, JVM crashes, out-of-memory events, abnormal restart loops, and bursts of connections to receiver ports around service degradation windows.
• Add monitoring for repeated Java serialization traffic, malformed stream errors, and sudden CPU/memory/thread spikes in processes using Logback receivers.