CVE-2022-23307

What it actually does

CVE-2022-23307 is an unsafe Java deserialization flaw in the Apache Chainsaw component bundled with Apache Log4j 1.2.x before Chainsaw 2.0. When Chainsaw or vulnerable Log4j 1.x network log-viewing functionality accepts serialized logging objects from an untrusted source, a crafted Java serialized object can trigger gadget-chain execution during deserialization. Successful exploitation can lead to arbitrary code execution in the context of the Java process running Chainsaw or the vulnerable logging component, with potential compromise of confidentiality, integrity, and availability.

Why it matters to the business

An exposed vulnerable Chainsaw or Log4j 1.x logging component can give an attacker a path from log ingestion or log viewing into full application or host compromise. Because Log4j 1.x is end-of-life and still appears in many legacy Java applications and downstream packages, exposure can be difficult to inventory and may persist through transitive dependencies. The EPSS value is elevated, indicating meaningful likelihood of exploitation in the wild even though this CVE is not currently listed in CISA KEV and is not marked as ransomware-associated.

How an attack unfolds

An attacker first identifies a system running Apache Chainsaw or Log4j 1.2.x functionality that accepts serialized logging data over the network or from another untrusted source. The attacker then crafts a malicious Java serialized payload that is compatible with classes available in the target Java classpath. When the vulnerable component reads the object stream, Java deserialization invokes attacker-controlled gadget behavior before the data is safely validated. If a usable gadget chain exists, the attacker can execute commands or load code with the privileges of the Java process. From there, the attacker may establish persistence, read sensitive files, pivot to adjacent systems, or disrupt logging and monitoring workflows. The provided threat-actor label appears to refer to Log4j deserialization activity rather than a confirmed named actor; defenders should still treat this as a high-priority legacy Java deserialization risk.

How to fix it

Remove Apache Log4j 1.x wherever possible because it is end-of-life. Upgrade to a supported Log4j 2.x release or another maintained logging framework, and remove the vulnerable Chainsaw 1.x component from deployments and analyst workstations. If Chainsaw is required, use Chainsaw 2.0 or later. For the supplied package data, ensure fixed versions or later are deployed: samba Debian packages fixed in 2:3.4.5~dfsg-2 where applicable, apache/logging-log4j2 Git fixed at commit 8d9204a4b4c6016fa6b36513a46502689d6a45c1, and qos-ch/reload4j Git fixed at commit 527f5374efd3c534b8aae7c133898019182e9f99. As interim mitigation, disable Chainsaw and any Log4j 1.x socket-based log receivers, block untrusted network access to logging receiver ports, restrict access to trusted administrative networks only, and remove vulnerable log4j-1.2.x JARs from application classpaths.

How to confirm the fix worked

Confirm remediation by inventorying Java artifacts and runtime classpaths for Log4j 1.x and Chainsaw classes. Search application packages, container images, build artifacts, and endpoint filesystems for log4j-1.2.x JARs and org/apache/log4j/chainsaw classes. Verify that no Java processes are running Chainsaw or Log4j 1.x socket receivers, and confirm that exposed services are not accepting Java serialized object streams from untrusted networks. Validate package upgrades against the listed fixed versions or later. Where source is available, review dependency manifests and software composition analysis results to confirm Log4j 1.x has been removed or replaced.

Typical attack path

1. Identify hosts, applications, or analyst workstations using Apache Log4j 1.2.x Chainsaw or related Log4j 1.x network log-viewing components.
2. Confirm that the vulnerable component accepts serialized Java logging events from a network socket, file, or other attacker-influenced source.
3. Build or adapt a Java deserialization payload using gadget classes present on the target classpath.
4. Send the crafted serialized object stream to the vulnerable Chainsaw or Log4j 1.x receiver.
5. Trigger deserialization and execute attacker-controlled code in the Java process context.
6. Use the gained execution to run shell commands, retrieve data, deploy tooling, or move laterally.

How to detect it

Investigate whether any vulnerable Chainsaw or Log4j 1.x receiver was exposed to untrusted sources. Review network telemetry for inbound connections to Java logging receiver services, especially traffic beginning with the Java serialization magic bytes AC ED 00 05. Examine process creation logs for Java processes spawning shells, scripting engines, download utilities, or system administration commands. Review application, endpoint, and EDR logs around Chainsaw or Log4j 1.x processes for deserialization errors, unexpected class loading, outbound network connections, or crashes. Search filesystems and memory/process command lines for Chainsaw usage and log4j-1.2.x artifacts. Because exploitation depends on gadget chains and may not leave a single deterministic log entry, prioritize behavioral evidence: anomalous Java child processes, unexpected outbound callbacks, recently written executables or scripts, and suspicious connections immediately after serialized-object input.

• log4j-1.2.
• log4j-1.2.x.jar
• org.apache.log4j.chainsaw
• org/apache/log4j/chainsaw
• org.apache.log4j.chainsaw.Main
• org.apache.log4j.net.SocketNode
• org.apache.log4j.net.SocketServer
• org.apache.log4j.net.SimpleSocketServer
• org.apache.log4j.net.SocketReceiver
• java.io.ObjectInputStream
• java.io.StreamCorruptedException
• java.io.InvalidClassException
• java.io.InvalidObjectException
• AC ED 00 05
• ysoserial
• java.lang.Runtime
• ProcessBuilder
• java -cp *log4j-1.2*
• java -jar *chainsaw*

What your security team should do

• Prioritize inventory of all Java applications, packaged products, containers, and administrative workstations for Log4j 1.x and Chainsaw usage.
• Remove Log4j 1.x and Chainsaw 1.x rather than relying only on network controls, because the affected software is end-of-life.
• Immediately disable or firewall Log4j 1.x socket receivers and Chainsaw listeners from untrusted networks.
• Upgrade or replace affected components using supported versions, including the supplied fixed package versions or commits where relevant.
• Hunt for historical inbound serialized Java traffic and suspicious child processes spawned by Java around logging systems or analyst workstations.
• Add software composition analysis checks to CI/CD and artifact repositories to prevent reintroduction of log4j-1.2.x dependencies.
• Treat confirmed exposure on internet-facing or broadly reachable internal systems as high severity due to the elevated EPSS and potential for remote code execution.