As we know by now that the only solution for Log4j is to get it updated to version 2.17.
The question is if VMware is going to update log4j to version 2.17?
Here is an official answer from VMware:
VMware regularly updates open-source components inside our products as new versions ship. As we’ve noted in previous updates here (which are starting to be archived below), this is a complicated situation. Unlike CVE-2021-44228 and CVE-2021-45046, there are specific configuration conditions to this new vulnerability that keep it from being applicable to all implementations. It is also a denial-of-service, which is serious, but not a critical remote code execution like the first two CVEs. As in all things, context matters, and VMware security engineers are working with our product teams right now to examine each implementation’s configuration, examine where each team is in their release cycle, and then determine the best way forward that protects customers fastest and most comprehensively.
Shortly after Apache’s statement VMware began investigating the potential impact of this vulnerability. At the time of this update, we have not found a valid attack vector to exploit CVE-2021-45105 in any VMware products, but investigations will continue. VMware will update log4j to 2.17 in future releases of our products.
Can I manually replace log4j JAR files on product appliances?
We urge folks to use the documented workarounds linked from the VMSA which are tested and supported. Testing and support are important, but the other big benefit is that if you use the workaround, the upcoming patch will know how to undo/fix the workaround so that you don’t have any additional work to do.
Please like and share to spread the knowledge in the community.
If you want to chat with me please use Twitter: @AngrySysOps
Visit my FB page: https://www.facebook.com/AngrySysOps
Read my blog: https://angrysysops.com
Subscribe to my channel : https://www.youtube.com/channel/UCRTcKGl0neismSRpDMK_M4A