investigating CVE-2021-44228, a critical vulnerability that’s affecting a Java logging package log4j which is used in a significant amount of software, including Apache, Apple iCloud, Steam, Minecraft and others.
your organization uses the log4j library, you should upgrade to log4j-2.1.50.rc2immediately. Be sure that your Java instance is up-to-date; however, it’s worth noting that this isn’t an across-the-board solution. You may need to wait until your vendors push security updates out for their affected products.
The log4j package may be bundled in with software you use provided by any given vendor. In this scenario, unfortunately, the vendors themselves will need to push the security updates downstream. As you assess your own risk and threat model, please consider the components of the software you use and especially what may be publicly accessible.
Don’t know for sure.
You can check look for Log4j
(I did lookup with tool mlocate there with locate Log4j maybe you have to install mlocate ( and then do updatedb before lookups)
I can’t find it on our BOX Alma 8.x Virtualmin.
But one can install so much , so you have to take care and be sure yourself.
And for this part we all have to follow i guess?
On December 9, 2021, a zero-day vulnerability in Log4j 2 was reported and given the descriptor “Log4Shell”. It has been characterized as the “the single biggest, most critical vulnerability of the last decade”.
Y’all, you’re only affected by this if you have Java applications running on your server that use log4j for logging. If you are using Java apps on your server, and those apps use log4j, you have to upgrade immediately.
We do not ship any Java code. Nothing in a default Virtualmin system is affected by this CVE.
Remediation by removing JndiLookup.class is safe for all log4j2 version from 2.0.1 and later. The original 2.0 release (and any betas/prereleases) will be broken if you remove JndiLookup.class
Because log4j2 is so ubiquitous, if is often bundled bundled into other jars rather than placed in its own jar which can be identified by filename. It is therefore a good idea to scan all jars for the presence of JndiLookup.class as suggested by @CyberRaiju above
But because it is frequently bundled, if is also frequently very outdated. I heard reports of people that broke installations of applications that bundled log4j2 2.0 by removing JndiLookup.class.
If your jar also contains JndiCloser.class, it is safe to remove JndiLookup.class. If not, this is version 2.0 and you will need some other method of remediation (environment, property or upgrade)
EDIT! this list below is continued and has updates!
So check important while most of us use ofcourse more software and devices , or are connected to the virtualmin boxes somehow.
See my edit the software list link from above is updated and will be updated , yes i know not Virtualmin , but for those whe are using those software or connect to in a way.
Dutch National Cyber Security Centre:
This page contains an overview of any related software regarding the Log4j vulnerability. On this page NCSC-NL will maintain a list of all known vulnerable and not vulnerable software. Futhermore any reference to the software will contain specific information regarding which version contains the security fixes, and which software still requires mitigation. Please note that this vulnerability may also occur in custom software developed within your oganisation. These occurrences are not registered in this overview.
At the end of the day its kind of your responsibility to ensure your own server is up to date. If you have installed Java app, you should know what/how/where. Vendors normally push out an update specific to own environment. As an example, I use OpenFire and its affected. Vendor pushed out an update the day after the vulnerability was announced. Bottom line - it is important to follow the community/support of the product/app that may have been installed on your server to ensure you are up to date.