I agree with panda and Carl Harris. The first discussion is how to use JNDI. from an attacker's point of view they will use the JNDI calls without any restrictions to cause RCE, but from a normal user's (programmer's) point of view the risks are not well perceived, they just use the normal functions of JNDI. So we need to make developers and users aware of this (so that if problems arise, responsibility can be identified).

The next discussion is whether this counts as a vulnerability. Like other privilege escalation vulnerabilities, the exploit conditions are only used when the attacker getshell, and with regards to this vulnerability, having write privileges is also a prerequisite, and with dynamic loading configuration and improper JNDI and JDBC connections, its attack surface can be greatly increased in certain scenarios, so it should be considered a vulnerability.

Finally, on how to fix it. The discussion by all the previous people has been very comprehensive(salute to all), and I agree with Carl Harris the most, with reference to log4j's fix: disable JNDI features by default (SMTPAppender and etc), restrict JNDI connection addresses to local by default, limit the ldap protocols to only accessing Java primitive objects.This minimises the risk and gives the choice to the user.