On December 9th 2021, a high severity vulnerability in Log4j 2 was published as CVE-2021-44228, AKA Log4Shell. Any JVM-based project using log4j-core with a version <= 2.14.1 is affected. See this Cloudflare blog post for a detailed explanation.
12/16 update
New releases of REST and asloader with log4j-core 2.16.0 have been posted. The announcement has been updated accordingly.
12/15 update
Alright! Apparently we’re not out of the storm yet. Apache Log4j released a new fix in log4j-core 2.16.0, as the 2.15.0 fix didn’t close the exploit. We will follow shortly with releases of the affected projects (REST gateway, asloader).
--- Original Post---
Obviously, Aerospike Database is written in C, and not vulnerable to a Log4Shell exploit. We have completed an assessment of the exposure our tools and connectors might have:
The Aerospike REST gateway is a Spring Boot application, and has been patched in
release 1.10.2. Users of this server should upgrade it immediately to the latest release. The Spring project has a December 23rd estimate for a full fix. We will pull the updated dependencies when those are available.
The Aerospike Loader is a command-line tool, which does not run as a daemon. It has minimal potential exposure. We will publish a new release in aerospike/aerospike-loader. Aerospike Loader was removed from tools 6.2.0.
The Java client’s logging is callback-based and does use a logging library directly.
Skyhook uses the Logback framework, which is not vulnerable.
Similarly, our streaming connectors for Kafka, Pulsar, JMS, Event Stream Processing (ESP), and the XDR Proxy use Logback, which is not vulnerable.
Our Trino (Presto) connector does not use log4j-core.
Our Spark connector doesn’t bundle its own logger. It uses the logging mechanism of Spark. Spark users should stay tuned to information from Apache Spark and Databricks.
The Spring Data project depends on log4j-api, but not the vulnerable log4j-core (the default logger for Spring Boot projects is not log4j 2). As soon as a fix is published, we will update the Spring dependencies of aerospike-community/spring-data-aerospike. Meanwhile, see the Spring Boot announcement mentioned above.
ACMS does not use log4j components and all customer environments managed by Aerospike are unaffected by this CVE.
PROJECT | AFFECTED? | NOTE |
REST gateway | Yes | Patched in a new release 1.10.2. Spring Boot based, and that project has an estimate of approx. Dec 23, 2021 for the full fix. |
asloader | Yes | A command line tool, not running as a daemon, so low probability of being exploited (TOOLS-1888). Tools 6.2.0 removed asloader. |
Java Client | No | Does not use any logging library. |
Trino connector | No | Does not use log4j-core. |
Spark connector | No* | The connector does not bundle log4j. Users of Spark will have to pay attention to updates from Databricks / Apache Spark. |
XDR Proxy | No | Uses logback. No dependency on log4j |
Kafka Inbound connector | No | No dependency. Kafka itself may use log4j. |
Kafka Outbound connector | No | Uses logback. No dependency on log4j |
Pulsar Inbound connector | No | No dependency. Pulsar itself may use log4j. |
Pulsar Outbound connector | No | Uses logback. No dependency on log4j |
JMS Inbound connector | No | No dependency. |
JMS Outbound connector | No | Uses logback. No dependency on log4j |
ESP Outbound connector | No | Uses logback. No dependency on log4j |
Skyhook | No | Uses logback |
Spring Data Aerospike | No* | The Spring Data project depends on log4j-api, but not log4j-core. The default logger for Spring projects isn’t log4j. No action is required on our side. We’ll bump the Spring dependencies, once they’re released. |
aerospike-helper | Yes | Archived project (read-only). Stale since 2018, not used by Aerospike projects. |
