We have received another security vulnerability report caused by object stream deserialization.

When all of the following conditions are met, the attacker can trigger RCE (remote code execution).

1) the user enabled the built-in 2nd level cache [1] 2) the user did not setup JEP-290 filter 3) the attacker found a way to modify entries of the private Map field i.e. org.apache.ibatis.cache.impl.PerpetualCache.cache and a valid cache key

We thank clanceyzzz of JD Sprite Team for reporting the issue!

Once this PR gets merged, MyBatis outputs WARN level log message when deserializing object.

As you are using functionality that deserializes object streams, it is recommended to define the JEP-290 serial filter. Please refer to https://docs.oracle.com/pls/topic/lookup?ctx=javase15&id=GUID-8296D8E8-2B93-4B9A-856E-0A65AF9B8C66

Note that:

  • the message is not logged when the JEP-290 filter is already defined
  • the message is logged just once right before the first deserialization

If WARN message is not enough, we can throw an exception instead, but that may surprise users a little bit.

[1] Some of the custom cache implementations also perform deserialization (e.g. mybatis-redis-cache). I plan to look into it later, but the recommended solution is the same i.e. the JEP-290 filter.

Comment From: nothingzhl

if the LookAheadObjectInputStream has been removed , will it affect the functionality of earlier version？like the blacklist.

Comment From: harawata

Thank you for the feedback, @nothingzhl !

This change won't break anything if that is what you mean. You just need to setup the JEP-290 filter by yourself (using whitelist approach, preferably) to protect your application instead of relying on the built-in blacklist filter.