Here (and I just as well 😉 ) you will find my notes on this issue as a reference and what we have done about it.
What is it?
This is best and most comprehensive description I have found so far: https://www.lunasec.io/docs/blog/log4j-zero-day/
You can find lots of information about the exploit itself, how to identify vulnerable servers, mitigation strategies, etc.
Detect vulnerable servers - scan for log4j libraries
In order to scan the filesystem and find all affected libraries (even if they include a log4j library inside of a jar/war/zip) I have used the following scanner.
Replace with log4j 2.16.0 (and above), not just 2.15.0
As of Tuesday, Dec 14, it's been found 2.15.0 is vulnerable to certain attacks as described in CVE-2021-45046. Thus, it is recommended to update to 2.16.0 or above.
Oracle Security Alert Advisory - CVE-2021-44228
Oracle support has published a security alert advisory.
Oracle ORDS is NOT affected
The good news is, that Oracle ORDS is not affected since they don't use log4j.
But your Tomcat might be affected.
For all of our clients we recommend to install the Tomcat from their software repository and don't downlad and install it manually. Thus, when there is a security fix in the repository, you only need to call
I am big fan of that. Often, you will find a security team in larger companies anyway ... and I don't want to be responsible for maintaining a manually installed Tomcat.
I have provided a fix for the JasperReportsIntegration toolkit, you can find the details here: JasperReportsIntegration 2.7.1 released.
I have not yet provided a fix for opal-tools.
Generally speaking, opal-tools should not be vulnerable, because they are not exposed through a J2EE server.
I will replace the libraries with 2.16.0 in a later release, but you can easily fix it yourself if required:
Download the latest log4j library: https://logging.apache.org/log4j/2.x/download.html, e.g. 2.16 or above.
Replace the following libraries:
log4j-api-2.14.1 => log4j-api-2.16.0.jar
log4j-core-2.14.1 => log4j-core-2.16.0.jar
It will already be fixed in the next release.
Test case to dig deeper
If you want to dig deeper, here you can find a testcase on how to simulate the situation: https://github.com/r00tkiiT/log4shell-vulnerable-app
Finally, here is a comprehensive list of resources on the internet: https://www.linkedin.com/pulse/log4j-vulnerability-cve-2021-44228-overview-resources-groeneveld/