The very nature of the Log4J exploit ensures that every server is racing to patch holes.
A recent discovery in the Log4J logging extension of Java applications has some serious repurcussions. As the video above posits, by simply replacing an error print command with an LDAP handle, a devious indivdual can execute almost ANY command on your server with root priveleges. This very notion has given the attack the nickname Log4Shell.
Take a moment to read that paragraph again. In case it didn't quite settle in. You're not alone in disbelief. The very idea that such a simple misconfiguration in coding can cripple a server is a big risk. One that several have been racing to mitigate, or have done so already. Some servers rely on Java so much that nearly 70% of the applications running on their domains either use Log4J directly or make calls to the library in an indirect manner. That's a whole lot of risk!
Through passing commands directly through Log4J, with unrestricted access to the shell. a potential attacker can concievably change the root password, issue configuration changes, remove accounts and import their own websites and DNS changes, all in a matter of minutes.
So how are sites and web panels mitigating this risk?
A hotfix and patch have already been issued in an update to Java and subsequently Log4J as well. Log4J2 v2.17 does not have the exploit, but if a server is running Log4j2 versions 2.0-alpha1 through 2.16.0, they may still be succeptible to attacks.
At present, most popular web panels such as cPanel, Plesk, CentOS Web Panel and Froxlor have very few elements (if any) that currently use Log4J (cPanel uses Log4J in dovecot-slr, an extension for the e-mail handler, but this can be temporarily mitigated by using an alternative e-mail server until cPanel releases an update patching dovecot-slr). If you maintain a server of any type, it is still recommended to perform a full scan of your server for the vulnerability if you have not done so already. Update your panels as soon as possible or manually update the affected packages.
Beyond the obvious mitigation, anyone who is currently managing a server should invest in services such as CloudLinux, ImunifyAV, Imunify360 or KernelCare (KernelCare is included with Imunify360). At least with these packages installed, if you are forced to wait while having exposed installations, they will assist in blocking potential attacks, mitigating and offering fixes until such time as an update becomes available to you.