Yes, see updated release notes:
This cumulative update contains 4 resolved issue (including 3 vulnerability resolutions) and all previously released updates for the 1.228 release.
JndiLookup.class is still part of the updated esshadow7-7.10.0-11.jar, after latest Managed update.
Is this still a concern? It triggers the deep scans of customer's hosting provider
/var/opt/dynatrace/managed/server/lib/esshadow7-7.10.0-11.jar | grep JndiLookup
3143 12-27-2021 17:30 org/apache/logging/log4j/core/lookup/JndiLookup.class
Elasticsearch itself removed the class from their updated code:
Introducing 7.16.2 and 6.8.22 releases of Elasticsearch and Logstash to upgrade Apache Log4j2 | Elas...
That's not the Elasticsearch server but our Dynatrace Server. Specifically this is Elasticsearch client library. The Log4j library used in the Elasticsearch client library (esshadow-7.10.0-x.jar) was not affected by any of the Log4j CVEs and was also updated to 2.17.1 in Dynatrace Managed version 126.96.36.19920113-162730 and greater.
Thanks, adding the similar response I received from support with details:
As for the esshadow jar did originally contain the JndiLookup.class file, but future releases will have this removed (Managed 1.234+ will have this removed). However, please note, esshadow does not call the vulnerable code at all. The log4j library bundled in esshadow is only used in exactly one spot to log an internal class name. No user input is ever logged by this log4j instance. However, if this is still present this can also be removed with the below zip command, followed by a restart of the cluster.
zip -q -d <jar-filename> org/apache/logging/log4j/core/lookup/JndiLookup.class