[Does not effect Virtualmin] Critical RCE Vulnerability: log4j - CVE-2021-4422

Is virtualmin affected?

Critical RCE Vulnerability: log4j - CVE-2021-4422

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.

Yup but is there a constillation this is in Virtualmin ( Apache part repo for OS) package somewhere?
Minecraft then yes… i guess.

I’ve been following all the referenced web sites.
I’m specifically asking if there is any investigation / confirm/deny that virtualmin is affected and that their software uses the package

Yea I’m aware… still doesn’t confirm/deny if virtualmim is affected

No answers ? Does anyone know anything regarding virtualmin and related software ?

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”.[8] It has been characterized as the “the single biggest, most critical vulnerability of the last decade”.[9]

Tools here

Virtualmin does not use log4j. There isn’t even any Java in Virtualmin.


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.


Yup Thanks for info

For those who aren’t sure or their own Applications use it, i did post above some tools LINKS and info how to find and test.

I kinda doubt anybody has accidentally installed a Java app. They’re usually a beast to get working. You generally know you’re running Java because it took a week to get everything up and running.

I can’t name a single easy-to-deploy Java web app. I’m sure they exist, but nothing springs to mind.


YES and NO could be bundled with some therefore better to be sure.

While this for example, yes i know one should know , but most of companny have more boxes and software active.

Maybe offtopic here but still important?

commented 43 minutes ago

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.

NCSC-NL will use the following status:

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.

Yes and no LIVE hacks are detected already at date 1-12-2021 so before known things where affected, ( Minecraft servers as example)

So you have to scan also for hacks on this not only do the updates while these are to late for most of them!

That is what National Dutch Cyber Security Centre say.

Edit: i don’t say Virtualmin is , but you have to know and check if using Apllications somewhere that does, you could be hacked before doing update , while hacks started before there where updates.

Ya I know :smiley:. Not because of this but I have never liked Java

I was doing some checking on one of my client’s systems and noted that Virtualmin-Config requires the Log4perl library which is a Log4j implementation for Perl - see: Virtualmin-Config/virtualmin-config.spec at master · virtualmin/Virtualmin-Config · GitHub and Log-Log4perl-1.54 - Log4j implementation for Perl - metacpan.org

I’ve not looked into this any further but can you confirm that this is not subject to the
CVE-2021-4422 vulnerability?

I’ve already explicitly said that Virtualmin is not affected by this CVE.

Log4perl shares no code with Log4j. They are only related in having similar APIs and naming conventions.

@Joe Great, thanks for the quick response - I am having to put together a report for my client who in turn is having to report to their client so just needed that explicit confirmation.

The variant in question is Java log4j version. Besides, we do not have control over liblog-log4perl-perl package anyway – vendor does!

Either way, Virtualmin installs are not affected by this CVE-2021-44228.

1 Like