CVE-2026-9828

What it actually does

This vulnerability is a restricted Java deserialization bypass in QOS.CH logback-core through version 1.5.32. When an application exposes logback's SimpleSocketServer or SimpleSSLSocketServer and an attacker can influence the serialized data sent to it, HardenedObjectInputStream may allow instantiation of certain java.lang and java.util classes that were not explicitly blocked. The issue is object injection rather than a demonstrated remote code execution primitive: the vendor description notes that deserialization is heavily restricted and that no practical path to remote code execution or significant privilege escalation has been identified. The realistic technical impact is limited manipulation of deserialization behavior, possible unexpected object creation, and potential low-impact confidentiality or integrity effects depending on how the receiving application processes deserialized logging events.

Why it matters to the business

Organizations using affected logback versions may have an exposure if they run or expose logback socket-based logging receivers. The business risk is lower than typical Java deserialization vulnerabilities because exploitation requires access to a specific logging listener, high attack complexity, and there is currently no known practical remote code execution technique. However, logging infrastructure is often widely embedded in Java applications, so identifying usage can be operationally difficult. If exposed across trust boundaries, the flaw could allow attackers to tamper with logging input, trigger abnormal behavior, or create a future foothold if additional gadget techniques are discovered. The vulnerability is not listed in CISA KEV, is not reported as ransomware-used, and has a low EPSS score of 0.0037, so remediation should be prioritized based on whether SimpleSocketServer or SimpleSSLSocketServer is reachable from untrusted networks.

How an attack unfolds

An attacker first identifies a Java service that includes an affected logback-core version and is running logback's SimpleSocketServer or SimpleSSLSocketServer. The attacker then obtains network reachability to the socket logging listener, commonly by scanning for open logging receiver ports or finding application documentation/configuration that exposes the listener. Instead of sending a normal serialized logging event, the attacker sends crafted Java serialized data. HardenedObjectInputStream restricts deserialization, but in affected versions the restrictions can be bypassed for certain unblocked classes in java.lang and java.util. Successful exploitation results in unauthorized object instantiation during deserialization. Based on currently available information, this is not known to provide reliable remote code execution, but it violates the intended security model and may allow limited object injection, logging pipeline manipulation, or denial/error conditions in the receiving process.

How to fix it

Upgrade logback-core and related logback components to a vendor-fixed release newer than the affected range once available from QOS.CH. The provided advisory states that logback through 1.5.32 inclusive is affected, but no exact fixed version was supplied in the input; do not assume 1.5.32 or earlier is safe. If an immediate upgrade is not available, disable SimpleSocketServer and SimpleSSLSocketServer unless they are strictly required. Where socket-based logging is required, restrict listener exposure to trusted hosts only, enforce network ACLs or firewall rules, require TLS with mutual authentication where supported, and avoid accepting serialized logging data from untrusted producers. Review build manifests, dependency lockfiles, container images, and application bundles for embedded logback-core copies, including transitive dependencies. Because logback is commonly packaged inside Java applications, redeploy rebuilt artifacts after dependency remediation rather than only updating system-level packages.

How to confirm the fix worked

Confirm remediation by verifying that no deployed artifact contains logback-core version 1.5.32 or earlier. Check Maven/Gradle dependency output, SBOMs, shaded JARs, container layers, and application library directories for logback-core. Validate runtime exposure by confirming that SimpleSocketServer and SimpleSSLSocketServer are not enabled, or if required, that their listening ports are bound only to trusted interfaces and blocked from untrusted networks. Perform a network scan from an untrusted segment to confirm the logging listener is not reachable. Review application startup arguments, scripts, service definitions, and logging configuration for references to logback socket server classes. After upgrading or disabling the listener, restart affected Java processes and confirm the running process is using the remediated library rather than an older bundled JAR.

Typical attack path

1. Identify a target Java application or logging receiver using logback-core through 1.5.32.
2. Determine whether SimpleSocketServer or SimpleSSLSocketServer is enabled and reachable from the attacker's network path.
3. Connect to the exposed socket logging listener, such as a logback receiver port.
4. Send crafted Java serialized data rather than a normal trusted logging event.
5. Trigger HardenedObjectInputStream deserialization of attacker-controlled data.
6. Bypass the intended class restrictions for certain java.lang or java.util classes not explicitly blocked.
7. Cause restricted object injection or abnormal processing in the logging receiver.

How to detect it

To determine whether exploitation may already have occurred, focus on hosts running Java applications with affected logback versions and enabled SimpleSocketServer or SimpleSSLSocketServer. Review application logs, stdout/stderr, systemd journal output, container logs, and centralized log aggregation for deserialization exceptions, unauthorized class messages, malformed stream errors, or repeated connection failures around the logging receiver. Review network telemetry, firewall logs, load balancer logs, VPC flow logs, packet captures, and endpoint network events for inbound connections to logback socket listener ports from non-approved sources. Java serialization traffic commonly begins with the bytes AC ED 00 05; unexpected occurrences to a logback listener are suspicious. Also review process command lines, service definitions, and application startup logs for evidence that the socket server was active during the relevant period. Because no public exploitation campaign, KEV listing, ransomware use, or mature exploit is indicated, detection should emphasize exposure plus anomalous deserialization activity rather than relying on known actor-specific indicators.

• ch.qos.logback.classic.net.SimpleSocketServer
• ch.qos.logback.classic.net.SimpleSSLSocketServer
• ch.qos.logback.core.net.server.HardenedObjectInputStream
• logback-core-1.5.32.jar
• logback-core-1.5.31.jar
• logback-core-1.5.30.jar
• java.io.InvalidClassException
• Unauthorized deserialization attempt
• java.io.StreamCorruptedException
• invalid stream header
• AC ED 00 05

What your security team should do

• Inventory all Java applications and container images for logback-core versions through 1.5.32 inclusive.
• Prioritize systems that expose logback SimpleSocketServer or SimpleSSLSocketServer, especially across network trust boundaries.
• Disable socket-based logback receivers unless there is a documented operational requirement.
• Restrict any required logging listener to trusted producers using firewall rules, security groups, host ACLs, or private network binding.
• Monitor QOS.CH release notes and upgrade to the first fixed version newer than 1.5.32 when available.
• Search historical logs for deserialization errors, unauthorized class attempts, malformed Java serialization streams, or unexpected connections to logback receiver ports.
• Add detection for Java serialization traffic to logback listener ports from non-approved sources.
• Ensure dependency scanning covers shaded JARs, fat JARs, and transitive dependencies, not only direct package declarations.
• Treat this as lower urgency where the socket server is not used or not reachable, but remediate promptly where untrusted network input can reach the listener.