VERTICA SECURITY BULLETIN - A potential vulnerability has been identified: Apache log4j library used

VertiguyVertiguy Administrator
edited December 2021 in General Discussion

Potential Security Impact: remote code execution


A potential vulnerability has been identified: Apache log4j library used by Vertica Server.

The vulnerability could be exploited to allow remote code execution.

CVE References: CVE-2021-44228
Please reference https://forum.vertica.com/discussion/242515/vertica-potential-security-vulnerability-apache-log4j-cve-2021-45046#latest for latest updates.

SUPPORTED SOFTWARE VERSIONS (ONLY impacted versions are listed):
Vertica Server – all versions

CVSS Version 3.1 Metrics:

Reference V3.1 Vector V3.1 Base Score
CVE-2021-44228 N/A N/A

Vertica Server
You can either apply the patch or perform the workaround.

Apply Patch
Two components in the Vertica product contain a vulnerable log4j library, Management Console (MC) and Kafka. Both are being modified to use a patched version of log4j (log4j.2.15.0). All Vertica versions currently under Committed Support (10.0, 10.1, and 11.0) will be patched and hotfixes will be available very shortly.
The workaround below will mitigate the problem while you wait for the patch.

This workaround can be applied to the Vertica Management Console and Vertica Kafka components independent of the Vertica version.

  1. On every server node, you need to update the Kafka scheduler.
    zip -q -d /opt/vertica/packages/kafka/lib/log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

  2. On MC node, you need to fix the Kafka scheduler it wants to use:
    zip -q -d /opt/vconsole/vendor/vertica/kafka/lib/log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

  3. And lastly, the MC itself uses log4j which is bundled into the webui.war file and unzipped by startup into /opt/vconsole/temp/*. So, you need to change the .jar inside the .war and also purge the temp space so it re-extracts.

mkdir /tmp/war
cd /tmp/war
cp /opt/vconsole/lib/webui.war .
unzip -o webui.war
zip -q -d WEB-INF/lib/log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
zip -r -u webui.war WEB-INF
sudo /etc/init.d/vertica-consoled stop
cp webui.war /opt/vconsole/lib/webui.war
rm -rf /opt/vconsole/temp/*
sudo /etc/init.d/vertica-consoled start

Vertica Accelerator (Vertica as a Service)
Vertica Accelerator is not impacted by this vulnerability.


  • Options
    CherrypCherryp Vertica Customer


    Do you have suggestion for Voltage Vertica ?
    I found Voltage for Vertica using Log4j also

    voltage-pp-0000 /]# find . -name "log4j-core-*"

  • Options
    moshegmosheg Vertica Employee Administrator
  • Options
    imesiasimesias Vertica Customer


    Our security scanner appears to pick this up on both MC as well as the cluster nodes. After a closer look, I can see the vertica packages themselves ship with the vulnerable version.

    [superuser@meeseeks opt]# find -name *log4*
    [superuser@meeseeks opt]# find -name *log4* | xargs rpm -qf 
    [superuser@meeseeks opt]#

    Vertica installs this Kafka package by default when you create a database, example output from a newly created db.

        Installing kafka package
            Success: package kafka installed
        Installing logsearch package
            Success: package logsearch installed

    Does this not leave the Database Server itself vulnerable? Or only for those actively using the Kafka integration?

    Kind Regards,

  • Options
    AMillerAMiller - Select Field - Employee
    edited December 2021

    Hi, It does NOT leave the Database Server vulnerable, these files are not used by the Veritca server directly. These files are available for the Kafka scheduler integration. The workaround will remove the vulnerable files from the scan detection.

    Corrected post.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file