CVE-2020-24164: 
Java vulnerability analysis and mitigation

A deserialization flaw was discovered in Taoensso Nippy versions from v2.5.0-beta1 (October 2013) through versions before 2.14.2. The vulnerability allows attackers to create malicious payloads that, when deserialized, can execute arbitrary code. This vulnerability was introduced when Nippy added automatic use of Java's Serializable interface as a fallback for unsupported types (GitHub Issue, NVD).

The vulnerability exists due to the automatic use of Java's Serializable interface as a fallback mechanism for types that Nippy didn't support via its own Freezable protocol. The issue was introduced in commit 9448d2b on October 24, 2013. The vulnerability has been assigned a CVSS v3.1 base score of 7.8 (HIGH) with vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (NVD).

When exploited, this vulnerability allows attackers to execute arbitrary code within the same JVM process when thawing (deserializing) malicious payloads. The vulnerability is particularly concerning because Clojure versions <= v1.8 include vulnerable 'gadget' classes that can be combined into a 'gadget chain' for exploitation (GitHub Issue).

The vulnerability can be exploited when all of the following conditions are met: the application is thawing data from an untrusted source, using a vulnerable version of Nippy, and has vulnerable 'gadget' classes on the classpath that can be combined into a 'gadget chain'. An attacker needs to create a malicious payload using specific vulnerable classes and successfully get the system to freeze and then thaw this payload (GitHub Issue).

Users are advised to upgrade to Nippy >= v2.15.0 final, which is safe by default. In version 3, the system implements allowlists for both freezing and thawing operations. The default thaw allowlist contains common safe class names, and objects that don't meet the security criteria are safely quarantined. Organizations can customize the allowlists based on their risk profile and needs (GitHub Issue).