Find, fix and prevent vulnerabilities in your code.

Overview

ch.qos.logback:logback-classic is a reliable, generic, fast and flexible logging library for Java.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data in HardenedObjectInputStream, whose resolveClass allowlist admitted any class whose name starts with java.lang or java.util rather than matching specific authorized classes. An attacker can instantiate dangerous classes such as java.lang.ProcessBuilder during deserialization, reaching remote code execution through a gadget chain, by delivering a malicious serialized object to a logback component that deserializes it, such as its socket receiver for serialized logging events (SocketNode). Exploitation requires the application to deserialize attacker-controlled serialized data through logback, in practice via its socket-based receiver, together with a usable gadget class on the classpath.

Workaround

This vulnerability can be avoided by not exposing logback's socket-based serialized receivers, such as SocketReceiver and ServerSocketReceiver, to untrusted networks, which removes the path by which attacker-controlled serialized objects reach the deserialization filter.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502) is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, thus allowing the attacker to control the state or the flow of the execution.

Remediation

Upgrade ch.qos.logback:logback-classic to version 1.5.33 or higher.

References

• Apache Jira Issues
• GitHub Commit
• Release Notes

Overview

ch.qos.logback:logback-core is a logback-core module.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data in the HardenedObjectInputStream module. An attacker can instantiate unauthorized Proxy objects by supplying crafted serialized data to the SimpleSocketServer or SimpleSSLSocketServer, thereby bypassing intended security restrictions.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502) is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, thus allowing the attacker to control the state or the flow of the execution.

Remediation

Upgrade ch.qos.logback:logback-core to version 1.5.34 or higher.

References

• GitHub Commit
• Logback Release Notes

Overview

ch.qos.logback:logback-core is a logback-core module.

Affected versions of this package are vulnerable to Deserialization of Untrusted Data in HardenedObjectInputStream, whose resolveClass allowlist admitted any class whose name starts with java.lang or java.util rather than matching specific authorized classes. An attacker can instantiate dangerous classes such as java.lang.ProcessBuilder during deserialization, reaching remote code execution through a gadget chain, by delivering a malicious serialized object to a logback component that deserializes it, such as its socket receiver for serialized logging events (SocketNode). Exploitation requires the application to deserialize attacker-controlled serialized data through logback, in practice via its socket-based receiver, together with a usable gadget class on the classpath.

Workaround

This vulnerability can be avoided by not exposing logback's socket-based serialized receivers, such as SocketReceiver and ServerSocketReceiver, to untrusted networks, which removes the path by which attacker-controlled serialized objects reach the deserialization filter.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502) is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, thus allowing the attacker to control the state or the flow of the execution.

Remediation

Upgrade ch.qos.logback:logback-core to version 1.5.33 or higher.

References

• Apache Jira Issues
• GitHub Commit
• Release Notes

Overview

ch.qos.logback:logback-classic is a reliable, generic, fast and flexible logging library for Java.

Affected versions of this package are vulnerable to Directory Traversal in MDCBasedDiscriminator, used by SiftingAppender, which takes an MDC value as the discriminating key without removing path separators, so the value reaches the nested FileAppender path unsanitized. An attacker can direct log output to a file outside the intended directory by supplying an MDC value containing / or \ path segments. This requires a configuration whose SiftingAppender discriminates on MDC and whose nested FileAppender interpolates the discriminating key into its file path, with that MDC value populated from attacker-influenced input.

Note: This is a bypass of the fix for the vulnerability described in CVE-2025-11226.

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

• Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

• Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

Remediation

Upgrade ch.qos.logback:logback-classic to version 1.6.3 or higher.

References

• GitHub Commit
• Release Notes

Dual license: EPL-1.0, LGPL-2.1

Dual license: EPL-1.0, LGPL-2.1