Typically, Java objects are serialized when writing to cache and then deserialized by clients reading from cache.

Where all cache clients are trusted (a common deployment pattern), Java deserialization poses no security issue.

However, in cases where a client could be an attacker, deserialization could be used to inject malicious code into another client. Specially crafted objects can be included in the serialized stream of bytes that, when deserialized by the Java deserialization process, lead to arbitrary code execution.

For the cache this, by nature, is not a security issue per se as no deserialization happens. But on the client side, such attacks should be mitigated.

The security issue with deserialization is a known issue in the technical community. As a result there are various solutions (such as blacklists/whitelists for classes) to address this issue.

Examples are NotSoSerial (https://github.com/kantega/notsoserial/), ikkisoft SerialKiller (https://github.com/ikkisoft/SerialKiller/), or ValidatingObjectInputStream in Apache Commons IO.